Например: Администратор баз данных.
0,0
рейтинг
5 августа 2012 в 14:06

Администрирование → Делаем свою Time Machine для Линукса

После интенсивного пользования time machine на маках и пару ситуаций когда она реально пригодилась (были варианты когда пришлось поставить систему из бэкапов и варант когда пришлось откатывать назад после проблем), возникла мысль а собственно почему такой удобной системы нет на линуксе. После исследования вопроса и опроса знакомых линуксоидов оказалось что:
1. сделать такую систему можно просто за пару минут на коленках
2. странно, но как-то никто собственно не в курсе что это можно поднять настолько быстро.
3. наша time machine для линукса будет с маджонгом и гейшами.


Как раз был ненужный appletv первого поколения из которого было решено сделать небольшой сервер на hardeded linux для сбора логов и всяких вспомогательных целей. После установки hardened gentoo как раз и возник вопрос как его бы бэкапить чтобы весь и сразу диск - чтобы можно было при полном отказе накатить бэкап на новый диск или на полностью новый appletv (хм, если потом такой найду конечно), или выборочно востанавливать удалённые или потерянные файлы просто ссылаясь на опеределенную дату.

Как работает time machine? Довольно просто, первый слепок системы просто копируется как файлы со всеми атрибутами в Backups.backupdb/hostname/YYYY-MM-dd-hhmmss, +делается симлинк Latest указывающий на последний слепок. А уже при втором слепке происходит следующее: сравниваются даты файлов и если файл не поменялся то вместо новой копии файла делается hardlink на файл из предыдущего слепка. Тогда если нет изменений файлов то весь новый слепок будет полностью ссылаться на предыдущий. Слепки будут отличатся только новыми/модифицированными/удалёнными файлами. В результате можно просто удалить любой слепок (каталог типа YYYY-MM-dd-hhmmss) и ничего не поломается. Самая ближайшая ассоциация - умный указатель в c++ например: когда пропадает последняя ссылка на файл (из всех слепков) он и удалится с дисков.

Очень удобная система с точки зрения просмотра предыдущих файлов, их востановления, удаления старых бэкапов итд. Вплоть до восстановления всей системы из слепка.

После исследования всех известных мне систем бэкапа под линукс, они были отброшены как немного не то что нужно. Зато нашлось простейшее решение с rsync в одну строчку.

rsync имеет чудесную опцию --link-dest которая как раз и делает всю выше описанную логику по сравнению с предыдущими слепками и создания hardlink-ов. Опция -x исключит все примонтированные файловые системы как /proc /sys /dev итд. --delete будет удалять файлы которые пропадут.

Вся time machine будет одним скриптом как:

#!/bin/sh
date=`date "+%Y-%m-%d-%H%M%S"`
SRC=/
DST=/mnt/backup-hdd/Backups.backupdb/atv

rsync -ax \
--delete \
--link-dest=../Latest \
$SRC $DST/Processing-$date \
&& cd $DST \
&& mv Processing-$date $date \
&& rm -f Latest \
&& ln -s $date Latest

Копируем скрипт в /etc/cron.hourly и вуаля у нас бэкапы как в time machine.
Если наша система слетела, мы можем загрузтся со флешки, отформатировать раздел, и запустить тот же rsync в обратную сторону, потом перегрузится или сделать chroot и система опять рабочая.

Еще положим в /etc/cron.daily простой скрипт который будет удалять hourly слепки предыдущий дней оставляя только 24 за последний день, потом удалять daily слепки за предыдущие месяцы итд — как в apple time machine, только выбирайте вашу последовательность.

Хотим заливать бэкапы по сети на backup сервер? Тоже пожалуста. Делаем авто авторизацию с ssh ключиками и немого меняем скрипт:

#!/bin/sh
date=`date "+%Y-%m-%d-%H%M%S"`
SRC=/
DST=/mnt/backup-server-hdd/Backups.backupdb/atv

rsync -axz \
--delete \
--link-dest=../Latest \
$SRC backup-user@company.com:$DST/Processing-$date \
&& ssh backup-user@company.com \
«cd $DST \
&& mv Processing-$date $date \
&& rm -f Latest»
&& ln -s $date Latest"

Тестируем, 3ГБ система на appletv сравнилась с последним слепком на сервером за минут пять — сервер удалённый — не в локальной сети, соединение было около 1.5MB/s. Мы добавили "-z" для компресии. Неплохо, но если будет расти можно делать не hourly а с большим диапазоном. Надо указать что rsync по сети похоже не передаст «owner:group» файлов — так как будет пользовать пользователя backup-user@… – можно просто сделать дамп всех атрибутов файлов в текст файл и положить в бэкап.

Теперь чего нет у Мак пользователей
1. Гибкая конфигурация с cron.
2. Опция --exclude=PATTERN/--exclude-from=FILE позволяет указать куда более гибкие правила на исключение чем просто указать папки. Например я очень недоволен что time machine бэкапит у меня на маке все *.о файлы — компиляция проекта легко раскидывается на пару гигабайт obj файлов, а сами папки проектов я исключать совсем из бэкапа не хочу.
3. Легко добавить доп логику чтобы делать локи баз данных если нужно
4. Легко сделать также в дополнению к слепку еще соотв слепок только тех файлов что изменились — легко мониторить потом какие файлы были изменены. Так как hardlink-и то места это много не займёт.
5. Добавьте теперь что сами хотите, у вас всё-таки линукс в руках ;)

Update: Пожалуй добавлю список требований к системе резервного копирования который у меня был в голове когда я смотрел на доступные пакеты/системы:
1. Простота использования (rsync: всего одна команда)
2. Доступность (rsync найдёте пожалуй на любом livecd)
3. Зависимости (если у вас слетел диск, вы загрузились с livecd, то теперь надо ставить куда-то пакеты с их зависимостями?)
4. Отсутствие конфиг файлов или их минимум (или теперь сначала искать конфиг руками в бэкапе?)
@yshurik
карма
83,5
рейтинг 0,0
Например: Администратор баз данных.
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (80)

  • +7
    И где маджонг?
    • +1
      В конце, пункт 4, чем не маджонг? ;)
      • НЛО прилетело и опубликовало эту надпись здесь
      • +4
        Так как в заголовке упомянут Time Machine ожидал как минимум написанного GUI.

        P.S. сам использую rsnapshot
        • +1
          rsnapshot — рулит. Таже тайм машин. Недавно глюкнул на домашнем сервере винт взялся за голову, думал что не смогу уже настроить машинку которая была сделана три года назад. Но rsnapshot все мне отдал, все файлы, конфиги и прочее. Потому запуск нового сервачка со всеми спасенными проектами занял пару часов.

      • 0
        Ладно, спрошу прямо — Где ГЕЙШИ?
        • 0
          Ну хорошо, поймал ;)
          Статью можно будет продолжить и расширить. Сделаю часть 2 позже. В комментариях было много полезного материала, надо будет просмотреть и обдумать.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Изюмительно!
  • 0
    Сохранить «owner:group» файлов можно если создать на сервере такие-же owner,group.
    И ssh довольно медленный… Так что если не нужна безопасность при передаче, можно поднять nfs на сервере и писать напрямую в примонтированный диск.
    • 0
      в смысле примонтированную по nfs папку
      • 0
        nfs не очень. Под нагрузкой работает очень плохо и может привести к коме всей системы, как сервера, так и клиента.
    • 0
      Передавало файлы довольно быстро, со всеми 1.5МБ/с которые были доступно, так что подозреваю что ssh был только для авторизации. Я этот вопрос не исследовал еще.
    • 0
      Если речь идет о использовании rsync то можно поднять серверную часть rsync с другой стороны.
    • 0
      > Сохранить «owner:group» файлов можно если создать на сервере такие-же owner,group.
      --numeric-ids, нне?

      > И ssh довольно медленный…
      Rsyncd?
    • 0
      а может просто добавить команду --numeric-ids?
      • 0
        оу, не видел коммента inkvizitor68sl. сорри :)
  • +4
    А чем не устроил rsnapshot? Можно настроить количество бекапов, тоже делает хардлинки :)
    • 0
      Чего-то там не хватало, но можно посмотреть его ещё раз, если там всё отлично работает.
      • 0
        Ну у меня пока проблем не было (тьфу, тьфу, тьфу ^_^), использую для серверных бекапов. где-нибудь пяток daily backups и несколько weekly. Хардлинки проставиляются нормально, места больше чем надо не жрет.
        • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      У меня на серваке как раз rsnapshot — больше года без единого разрыва.
      Дополнительной идеей дарю снятие копии не с живого тома, а со снапшота lvm. Это позволит не париться по поводу изменения файлов в процессе копирования (и, как следствие, рассинхронизации).

      В итоге, алгоритм такой:
      1. Останавливаем БД.
      2. Делаем lvm snapshot.
      3. Запускаем БД. (Время простоя — минимальное, в основном накладные расходы на service stop|service start.)
      4. Монтируем получившиеся снапшоты куда надо.
      5. РСнапшотим уже примонтированные снимки, сервер в это время спокойно работает.
      • +1
        (Забыл пункт.)
        6. Отмонтируем и удаляем снапшоты.

        Да, предвосхищая сомнения — снапшоты в lvm используют copy-on-write, поэтому Они создаются мгновенно, места просят совсем немного, и так же мгновенно удаляются.
        • 0
          Тут есть один недостаток: пока существует lvm-снапшот, производительность дисковой системы ухудшается раз эдак в 10 навскидку.
          • 0
            Если вы про эту статью: johnleach.co.uk/words/613/lvm-snapshot-performance, то там отдельно говорится что рассматривается производительность на последовательной синхронной записи.
            В реальной жизни существует буферизация файловой системы, которая достаточно сглаживает эти проблемы. Настолько, что в официальной документации по lvm-snapshots (http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html) проблема упомянута в формулировке
            When the backup has finished you can now unmount the volume and remove it from the system. You should remove snapshot volume when you have finished with them because they take a copy of all data written to the original volume and this can hurt performance.


            Ну и да. Если у вас есть сервер, заметную (10% и более) нагрузку на который составляет запись в БД, не стоит его бекапить при помощи rsnapshot и lvm-snapshot. Если вдруг что — я предупреждал.
            • 0
              Довольно хреново сглаживает. Я не про статью, а про печальный опыт. Смотрю — как-то медленно винт работает. Начал разбираться — оказалось снэпшоты тупят.
            • 0
              Мне кажется в случае БД разумно все-таки делать бэкапы с отдельной slave-машины.

              rsync/rsnapshot все-таки больше подходят для несколько других целей.
              • 0
                Ну и я о том же.
                Другое дело — конкретная моя ситуация. Есть достаточно толстая коробочка с Дебианом, на ней настроена куча всего — gitolite, TeamCity и вся обвязка для «безголового» приёмочного тестирования.
                Тут же — веб-сервер, куда деплоится стейдж при успешном прохождении сборки. И его БД, понятно. Этот стейдж доступен клиентам в ознакомительных целях.

                Моя единственная забота, когда я настраивал бэкапы, состояла в том, чтобы в случае сбоев можно было бы в кратчайшие сроки завести всё в уже настроенном виде.
                Причём понятно, что если источник сбоев — софт, то можно откатиться на недельку назад и ничего сташного не произойдёт.
      • 0
        А зачем останавливать БД? И почему не нужно останавливать всё остальное?
        • +1
          Ну это уж у кого чего работает с диском постоянно. У меня на сервере только БД пишет что-то в файлы непрерывно и критично к состоянию, в котором её застал снэпшот.
          Большинство БД скорее всего не заведутся с полпинка, если им подсунуть неконсистентные файлы хранилища. Надо будет запускать долгий и муторный процесс починки базы. Что гораздо неприятнее, особенно в условиях «суббота, поздняя ночь, сервер жахнул».
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              В МонгоДБ есть специальная функция журналирования, которая позволяет в таких ситуациях не заморачиваться с финализацией файлов БД, бэкапиться по-горячему и запускаться потом без repair.
              Естественно, mongodb — eventually consistent база данных, и это повышает вероятность потерять последние транзакции перед бэкапом.

              Похожая функция (причесать файлы БД на диске для снятия снэпшота без прекращения нормальной работы) есть, оказывается, и в постгресе. Там есть тонкости, судя по гуглежу. Но тем не менее спасибо за наводку, пойду потестирую скрипты с ней. Как раз ночь, клиенты спят, автоматика уже скоро бэкап будет делать…
  • +3
    Пусть ссылочка тут полежит, может кому понадобится
    habrahabr.ru/post/133330/
    • 0
      Хороший пост, но в чём была особенность что пришлось пользовать cp+rsync а не просто rsync --lisk-dest который сделает тоже но с меньшими усилиями и одним заходом?
  • 0
    > А уже при втором слепке происходит следующее: сравниваются даты файлов и если файл не поменялся то вместо новой копии файла делается hardlink на файл из предыдущего слепка

    И еще даже немного больше: на HFS томах будут хардлинки целых неизмененных директорий.
  • 0
    А как бы в эту схему еще сжатие прикрутить? Из-за механизма хардлинков в архивы складывать не получится. Может быть складывать на диск со сжатием? Насколько такое может быть эффективно и быстродейтсвенно, никто не пробовал?
    • 0
      Думаю более правильно это диск со сжатием чем прикручивание сжатия к самому бакапу
    • 0
      Хардлинки как правило выгоднее архивов. А вообще что-то вроде через фусю было для монтирования сжатых разделов. Вполне можно использовать.
  • 0
    кстати, мне crashplan понравился для бекапов. Очень удобно сделан.
  • +5
    Ничем не отличается от «Back in Time» и прочих утилит, являющихся зачастую интерфейсом к тому же rsync. Разница в том, что в таком случае не нужно изобретать велосипед, программа всё делает за тебя установлением нескольких галочек по-вкусу.
    • 0
      тоже хотел написать про Back in Time, очень удобная вещь и простая и понятная в использовании.
    • 0
      я правильно понял, что «Back in Time» бэкапит только пользовательские файлы, но не сможет восстановить систему подобно YaST System Backup?
      • 0
        Думаю, это ошибочное мнение. Что мешает «Back in Time» делать бэкап всей системы?
        (YaST System Backup я не использовал)
  • 0
    Можете теперь отключить у себя на маке time machine и положить в крон эти скрипты :)
  • +1
    Очень похоже на rdiff-backup
    • 0
      rdiff-backup лучше, тк жрет меньше места
  • +1
    Очень рекомендую посмотреть на pdumpfs — делает ежедневные бекапы с хардлинками на старые файлы одной строчкой. В результате — дерево дат и на любую дату полный бекап без дубликатов.

    Старая утилита и есть в пакатах почти везде, это порт старой идеи с plan9, можно еще нагуглить скрипт pdumpfs-clean. У меня только из-за нее по сути и стоит ruby, но должен сказать что за последние 4 года пригодилась неоднократоно.
  • 0
    Я пользуюсь утилитой dump/restore.
  • +7
    эта штука не дает визуального отображения версий и сравнения side-by-side. А это помоему одно из самых приятных возможностей, которые отличают машину времени от других систем резервного копирования.
    image
    • –5
      Apple же на г***о изойдётся, если сделают копию с Time Machine…
    • 0
      Думаю можно вполне реализовать летящие звёзды и крутящуюся «что-то-там» через ascii графику ;)
      Будет и красиво и наглядно.
      • +1
        но нужны же еще состояния каждого документа в приложении side-by-side, я даже не знаю как это в консоле сделать :-)
        image
        • –1
          А смысл?
        • 0
          Действительно, за всё время такое ни разу не пригодилось.
          Может вам нужна таки система контроля версий для таких файлов/случаев?
          • 0
            для кода я использую консольный git и diff, а эта штука нереально удобная для разного рода картинок, документов и презентаций.
            • 0
              Скорее всего и там бесполезна. Это больше красивость, чем функциональность.
              • 0
                Ну странно за других делать выводы. Мне полезно, потому-что наглядно и как следствие экономит время. Так как технология жива и развивается — значит полезно и удобно не только мне. Плюс для средних пользователей разбирательство с гитом — это не просто, поэтому машина времени остается единственным вариантом для них.

                • –2
                  >Ну странно за других делать выводы.

                  Ну не стоит выдавать желаемое за действительное. Я не говорил за всех, а сделал предположение что для картинок она так же будет бесполезна на том основании, что изменения в картинке при таком preview сложно увидеть.

                  >Мне полезно, потому-что наглядно и как следствие экономит время.

                  А можно некий workflow по этой фиче? Просто хочется понять видение пользователя об удобстве данного функционала (я не издеваюсь, просто хочется для себя понять ваш сценарий).

                  > Плюс для средних пользователей разбирательство с гитом — это не просто,

                  Эмм… ну это все равно, что предлагать пользователям работать с сайтами путем чтения HTML. GIT — это специализированное решение о чем вы сами и написали.
                  • +2
                    Ну не стоит выдавать желаемое за действительное. Я не говорил за всех, а сделал предположение что для картинок она так же будет бесполезна на том основании, что изменения в картинке при таком preview сложно увидеть. 
                    


                    Очень даже полезно, вот несклько сценариев: идет согласоание договора. Возникает спорный момент или конфликт условий. В этом случае я спокойно листаю документ «в прошлое» и смотрю динамику изменения связаных пунктов, чтоб понять на каком этапе начал зарождаться кофликт и почему. Решается за пару минут. Как альтернатива — смотреть и сравнивать все версии руками, что у меня раньше занимало в десятки раз больше времени.
                    По факту любое согласование документов имеет некую цепь развития, и после того как давно с ним не работал и позабыл уже всё, эту цепь легко воссоздать и легко вернуться к некой «контрольной точке».
                    Второй сценарий — обсуждаем «мокап» проекта с дизайнером: хранить кучу версий одного экрана нумеруя их с новой циферкой быстро переводит этот процесс в свалку. особенно если таких экранов штук 50. А так можно в одном экране читать переписку с датами (в бейзкампе например), а во втором смотреть динамику изменения: как учтены замечания и в какой момент возникло недопонимание. Конечно можно экраны закидывать прям в переписку — но там обычно уже и так перегружено все текстовой информацией и картинками с аннотациями (поверх графики рисуются разные указания, стрелочки, предположения и тд.).
                    Либо же просмотреть истоию измненеия картинки, чтоб сказать какого именно числа была создана правильная/неправильная версия.
                    Еще один сценарий — документ/картинка пережил несколько вариаций изменений и в какой-то момент оказалось что часть информации «пропала» (не хватает пункта в документе или элемента в дизайне) — легко пройтись по истории и глянуть в какой момент забыли про эту штуку.

                    Ну и так далее.

                    Эмм… ну это все равно, что предлагать пользователям работать с сайтами путем чтения HTML. GIT — это специализированное решение о чем вы сами и написали.
                    

                    А какая альтернатива системы контроля версий сущестует для «рядового пользователя» с возможностю отката до нужно версии, кроме машины времени? По факту этот side-by-side — это как раз и есть виузальный diff для простых пользователей. Как и diff он служит для сравнения версий.
                    • 0
                      > В этом случае я спокойно листаю документ «в прошлое» и смотрю динамику изменения связаных пунктов

                      Ок, звучит интересно. Т.е. я правильно понял, что можно в самом документе листать, а не разглядывать preview?

                      >Как альтернатива — смотреть и сравнивать все версии руками

                      Тут не совсем понял, обычно в таких вещах используется режим правки или речь идёт не про doc/docx/odt/и т.п. формат?

                      >По факту любое согласование документов имеет некую цепь развития

                      Я и не отрицаю сего факта.

                      >Второй сценарий — обсуждаем «мокап»

                      Гут, спасибо за интересный сценарий. У меня есть несколько моментов, но думаю, что неправильно их озвучивать, т.к. в таком контексте я не работал.

                      >Еще один сценарий — документ/картинка пережил несколько вариаций изменений

                      В плане картинки разницу можно будет увидеть на больших объектах. В плане документа — все же нужны встроенные средства, аля режим правки документа. Это удобнее, т.к. видится полный сценарий, опять же (в виду того, что я не работал с Time Machine), а если в документе за период синхронизации у вас изменения более чем в одном листе документа, то какое поведение/сценарий?

                      >А какая альтернатива системы контроля версий сущестует для «рядового пользователя» с возможностю отката до нужно версии, кроме машины времени?

                      Здесь нужен всего лишь GUI над VCS. Идеально было бы увидеть такое.

                      Ещё раз, я не говорю, что Time Machine нужна/не нужна, я говорю, что моё мнение в том, что текущий подход — это больше красивость, чем функциональность (не персонализируйте данный термин) в целом, да вы нашли удобные для вас сценарии, но тут как в анекдоте «за неимением горничной подойдёт и дворник».
                      • 0
                        Попробовав машину времени был приятно удивлен. Хранить версии файлов это хорошо, когда знаешь, что надо откатить на такое-то число, а вот когда необходимо найти что-то, начинается сущий ад. Именно тем и хороша тайммашина

                        >Ок, звучит интересно. Т.е. я правильно понял, что можно в самом документе листать, а не разглядывать preview?
                        Приложения использующие API тайммашины позволяют просматривать сам документ, и (лично для меня).

                        >это больше красивость, чем функциональность
                        Так же считал, пока не решился посмотреть что и как
                      • 0
                        Сорри, ссылка не добавилась.
                        Вот что хотелось бы увидеть:
                        hpcforge.org/scm/viewvc.php/trunk/src/frontend/simple.cpp?root=kernelgen&r1=987&r2=986&pathrev=987
                  • 0
                    В условиях разбора полётов, приходится выяснять: а был ли мальчик. И то, что может предложить консольное нечто разложенное по каталогам, я ругулярно кручу в time machine просто поглядывая через review, даже не открывая файлы полностью файлы.

                    Хотя звёздочки я бы остановил и кнопку по низу сделал в нормальной плоскости. Немного оно не вписывается в общий интерфейс системы.
        • 0
          А в чём трудность?
          У вас есть все файлы в том состоянии, в каком их застал бэкап, разложенные по папочкам с датами снятия снимков. Осталось примонтировать эти папочки куда-нибудь себе (для простоты — прямо через ssh+ftp), и сравнивать в своё удовольствие.

          Можно и гуй написать. Но разве что в качестве упражнения — там возни где-то на неделю, а такая фича ну дай бог раз в году пригождается.
          • +2
            Обратите внимание справа на шкалу — это раз. Конечно это не космос — все можно сделать, особенно это.
            Самая главная штука — это то, что слева и справа документы живые и смена состяния просиходит мгновенно (например при прокручивании истории для поиска момента, когда изменился требуемый фрагмент). Вот это уже не просто. Открывать 100500 приложений для каждого состояния — это очень ресурсозатратно. В макОС это реализуется тесной интеграцией самих прилжоений с машиной времени через соответсвующий фреймворк+ встроенная версионность в самой файловой системе и такой красивый UI для самого процесса.
            Это удобно и не так просто сделать, иначе было были бы уже реализации и под виндовз.

  • 0
    Есть ещё duplicity со схожей функциональностью
  • 0
    А зачем используется cron? В ядре есть специальная подсистема inotify при помощи которой можно определять изменения файлов, директорий и т.п. Даже есть сервис incron.
    • 0
      Почти всегда достаточно ежедневных бекапов, а во многих случаях вообще не подходит бекапить каждое изменение файлов, в случае активной работы с диском, бекапы будут заполняться крайне быстро.
      • 0
        Это в случае, если у вас оборудование работает 24х7. А если в этот момент оно будет выключено?
        Задача inotfy уведомлять об изменениях, т.е. проще говоря вы сами регулируете что делать, когда проходит изменение. incron похож на cron только вместо времени там задаются условия, например изменения в файлах, создание файлов и т.п. Т.е. у этом случае у вас будет гарантия правильности миграции.
  • +1
    А так?
    0 содержит самую актуальную версию файлов в /home, 5 – самую древнюю.

    mv /ext/4 /ext/5
    mv /ext/3 /ext/4
    mv /ext/2 /ext/3
    mv /ext/1 /ext/2
    cp -al /ext/0 /ext/1
    rsync -ae --delete /home /ext/0
    
  • +1
    rsync по сети похоже не передаст «owner:group» файлов
    --numeric-ids

    как для «time machine на коленках» вариант с rsync подойдет, но надо понимать и его ограничения:
    — сканирует весь src (для нескольких десятков миллионов файлов это может быть напряжно)
    — хардлинки никак не помогают сэкономить место для логов, даже если размер лога изменился на один байт (или mtime на одну секунду)
    — rsync не умеет хардлинковать файлы в переименнованных директориях (т.е. содержимое папки backup/0/, переименнованную в backup/1/ будет скопировано полностью заново)

    P.S. идеальный вариант для локальной time machine, imho, это поддержка множественных copy-on-write снепшотов файловой системой, данные с которой нужно бекапить (например UFS2). Соотв для нелокальной — это поддержка файловой системой дедупликации (например ZFS).
    • +1
      Попробуйте obnam, это практически time machine без графического междумордия.
  • +1
    • 0
      Obnam это отлично. Я его смотрел. Но меня озаботили зависимости которые он тянет. Данная time-machine на коленкаx тем хороша что rsync есть на любом live-cd и её можно сделать очень легко на любом линукс дистрибутиве при самой минимальной инсталляции, и в случае полного креша, восстановится можно будет используя практически любой live-cd.
      Конечно данная time-machine на коленках обладает многими ограничениями которые нужно понимать — тут много комментариев хорошо их описывают.
      • 0
        Да вроде немного совсем зависимостей у obnam.
  • 0
    А хардлинки на папки кто-нить уже умеет делать кроме HFS+?
  • 0
    Когда мне в Линуксе потребовался «Time Machine» я смигрировал на BTRFS и его снапшоты. Помнится, обновление системы делал до нового релиза, как раз перед этим сделал снапшот. Потом как посмотрел, какой новый релиз глюкавый — перекрестился и откатился назад. Думаю, подожду, пока багфиксов не навыпускают. Пользоваться, кстати, очень просто.
    • 0
      zfsonlinux.org/ ZFS на линукс очень прилично работает. Кроме того, существует патч для nutilus вот такой (сейчас ссылки битые, но пару лет наза я пользовался)
  • 0
    Не обязательно делать снапшоты на уровне ФС. Классический LuckyBackup справится с задачей на отлично.
    luckybackup.sourceforge.net/
  • 0
    Тема, конечно старая, но всё же.
    Есть одна, я считаю — существенная проблема, это реализации бэкапа при помощи rsync и многих других. На примере:
    Есть файл outlook.pst, где хранится вся почта, контакты, календарь и т.д. на 100 Мбайт. Делаем его первичный бэкап. Передаётся — 100 Мбайт, занимает на бэкап-сервере — 100 Мбайт. Затем получаем одно электронное письмо в 1 Кбайт. Делаем вторичный бэкап. Передаётся — 1 Кбайт, занимает на бекап-сервере — 100 Мбайт (первый архив) + 100 Мбайт (второй архив) + 1 Кбайт изменения. В итоге за 24 архива (за сутки) места будет заниматься — 2,4 Гбайт + «чуток».
    Дело в том, что да, rsync передаёт лишь изменившиеся части, но воссоздаёт на получателе всегда полные файлы. Насколько я понимаю rdiff-backup сохраняет лишь разницу (называется Block-Level Backups, но восстановить «в лоб» (простым копированием из архива) — не получится.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.