Есть ли готовые решения или best practice для организации backup'ов с контролем версии?

Question

[Даниил Literate]

Хотелось бы получить информацию о том как можно организовать backup с контролем версий старых архивов.

Есть ли готовые инструменты или подробные инструкции как такое организовать и чем?
Гугление даёт rsync для стягивания файлов, но что тогда применить для контроля версий?

Суть задачи:
При возникновении новых файлов на рабочей машине сразу стягивать их на backup машину (тут rsync скорее).
Раз в день, например, делать снапшот резерва, и как то это экономично держать, т.е. только новые файлы или измененные, чтобы была история изменений на протяжении месяца (мб btrfs как то прикрутить).

В общем, есть ли идеи как это лучше реализовать, делать ли свой велосипед или есть что-то готовое?

Answer 1

[MrSotariz]

Почитайте о bacula

Answer 2

[Назар Мокринский]

У меня свой инструмент уже больше года успешно делает снимки BTRFS с контролем количества снимков в зависимости от давности и возможностью резервного копирования на внешний BTRFS диск: https://github.com/nazar-pc/just-backup-btrfs

Comments

[Даниил Literate]

Интересное решение.

Расскажите почему PHP решили использовать?

И про вопрос, как лучше стягивать файлы с рабочей машины на backup'ную?

[Назар Мокринский]

Fuckoff95: Потому что я PHP знаю лучше всего)
Если есть локальная сеть - можно модифицировать скрипт для копирования бинарных диффов снимков по сети (и прислать PR:)), либо написать ещё один небольшой, на том же Bash.
Так же ознакомьтесь с другими проектами, некоторые умеют пересылать данные по SSH из коробки: https://btrfs.wiki.kernel.org/index.php/Incrementa...

[Назар Мокринский]

Fuckoff95: Либо как ниже написали по сети просто rsync, а снимки уже на целевой машине с файловой системой btrfs.

Answer 3

[Дмитрий Шицков]

Расскажу как я бы делал своими велосипедами.
По rsync данные с вашей машины отправляются на бекап-сервер. Допустим, на бекап-сервере ZFS и со снапшотами всё просто. По крону на бекап-машине клепаем сколько и когда нам хочется ZFS-снапшоты. По крону же, контролируем кол-во созданных снапшотов и удаляем лишние. Если не ZFS, то LVM-снапшоты...

Comments

[Даниил Literate]

На самом деле примерно такая стратегия и была.

Тогда если можно, то детали уточнить:
1. "По rsync данные с вашей машины", оправлять лучше также по крону или лучше настроить событие добавление или изменения файлов? Вроде натыкался на статью, что в ядре есть демон на это.

2. И холиврный вопрос ZFS или BTRFS?

[Дмитрий Шицков]

Даниил Literate:
1. На этот вопрос лучше ещё поспрашивать. rsync перестраивает дерево файлов-каталогов, что занимает время. Поэтому, возможно, он не лучший вариант для частых обновлений данных.
2. С BTRFS не работал, как и с ZFS на Linux.

Но, думаю ещё оба пункта можно убить одним зайцем. ZFS может реплицировать изменения ФС по сети практически в реальном времени :)

Answer 4

[Anton_Shevtsov]

Duplicity же.. Все есть, сам пользую.

Comments

[hrum]

использовал тоже до определенного времени. с аплоадом по ssh/scp. все вроде ровно и красиво, только когда понадобилось восстановление пары файлов из бэкапа, дуплисисити потянул всю эту радость обратно, и на одном попавшемся битом пакете заткнулся намертво. Дальше только танцы с бубном и восстановление руками с поиском по каждому из инкремент-пакетфайлов.
В общем, не рекомендую - одного такого случая дизастер рекавери мне хватило навсегда.

[mxx]

hrum: А у вас full-backup был настроен раз в какой-то промежуток или всегда только incremental делали? По идее при восстановлении тянуться должны только архивы с прошлого full-бэкапа. Также рекомендую использовать какую-нибудь обёртку, а не просто duplicity, например duply. Гораздо проще конфигурировать, бэкапить и восстанавливать.

[hrum]

mxx: насколько я помню, раз в месяц у меня был настроен фулл бэкап, а потом инкрементные. По несчастливому стечению обстоятельств искомые файлы были изменены где-то во второй половине месяца, поэтому с сервера тянулись кроме фулл и почти все инкременты. Обертка тоже была графическая, но я пользовался командной строкой после того как заметил что происходит сбой контрольной суммы одного из инкр.пакетов.
Кроме того, не понравилось в дуплисити что кэш контрольных сумм файлов и бэкап-пакетов занимает много места на клиенте. При большом количестве сохраняемых файлов оказалась весьма ошутима потеря свободного места, а без кэша (например после его удаления) - бэкап очень медленный... и управление восстановлением с клиента, а не с сержера, накладывает свой отпечаток: если нет сервера, а только NAS где-то, то и так сойдет, в противном случае просто неудобно и очень медленно.
По опыту, ему далеко до энтерпрайза. Теперь критичные данные я бы ему не доверил.

Answer 5

[hrum]

Если локальная сеть, то BackupPC
Работает как часы, на бэкап и восстановление, сам наблюдает за клиентами (например бэкап ноутбуков, которые нерегулярно подключаются к сети) и делает бэкап по необходимости. Веб-морда в наличии, в настройки правда надо вчитаться поначалу. Бесплатен, клиентского софта не требует.

Или bacula, но не бесплатно, зато мощно. На клиенты надо ставить софт.

Мы используем оба пакета, для разных секторов сети, и бакула последней свободной версии, когда она еще была опен сорс, но в ней нет web-frontend, и все из командной строки.

Answer 6

[Kev]

Если нужна оперативная синхронизация - то лучше воспользоваться https://syncthing.net/ или аналогами.

Для резервных копий посоветую rsnapshot rsnapshot.org . Позволяет хранить несколько копий, одинаковые файлы не будут дублироваться за счет жестких ссылок.

Answer 7

[Everything_is_not_so_bad]

Попробуйте ZBackup + rsync ( + s3fs для Amazon S3).

tar -c /home | zbackup backup /my/backup/repo/backups/home-`date '+%Y-%m-%d'`.tar
zbackup restore /my/backup/repo/backups/home-`date '+%Y-%m-%d'`.tar | tar -xf -

Some filesystems (most notably ZFS and Btrfs) provide deduplication features. They do so only at block level though, without a sliding window, so they can not accomodate to arbitrary byte insertion/deletion in the middle of data.

Answer 8

[Николай Мишин]

Посмотрите вот это:
it.werther-web.de/2011/10/23/migrate-rsnapshot-bas...

Answer 9

[SkyCat]

Мы сейчас используем obnam. Есть около 10 репозиториев общим объемом около 300 гигабайт. История есть с самого начала использования, т. е., с декабря 2014 года. Уже несколько раз пришлось воспользоваться восстановлением, все работает отлично и довольно быстро.

Чтобы восстановить данные, нужно смонтировать репозиторий в какую-нибудь директорию и будет доступ ко всем версиям (см. скрин).

Answer 10

[foboss]

Под описанную задачу очень подходит bontmia (bash-обертка над rsync). Работает очень похоже на бекапы от Apple, создавая структуру каталогов с хардлинками на неизменные данные.

Если копать сильнее, то на рабочей машине (если там Linux) можно поставить ZFS и передавать на backup-сервер только снепшоты (zfs так умеет). Ну или заморочиться и архивировать в tar и подключенным xdiff3 вместо обычного архиватора.