btrfs-поддерживающее решение для резервного копирования

I've done some extensive searching in the last week for something similar. I have found no solutions to do all 4 steps. There are numerous blogs from home users who try the 'rsync to btrfs'-type of backups, and all of the major Btrfs wikis cover how to perform Btrfs snapshots.

There are also quite a few people who are attempting different ways of rotating Btrfs snapshots. However, you are the first person I've seen who wants to rotate snapshots based on disk space. I am playing with btrfs-snap myself which creates a set of hourly, weekly and monthly snapshots, and it's nice and simple.

The Dirvish project seems to meet many of your requirements. Some developers are attempting to integrate Dirvish with Btrfs. However, the Dirvish project seems a bit stalled.

At this point in time, you are ahead of the curve.

According to Avi Miller (his talk during LinuxConf.AU) a btrfs send/receive is being worked on. It'll be faster than rsync since it doesn't need to traverse through directories to find changes in files.. I don't know if there's an expected release date yet though.

There is, however, a utility built into btrfs-progs that lists every file that has changed between snapshots/etc.. btrfs subvolume find-new

Я работаю над системой резервного копирования ОС, аналогичной BackupPC. Я думал об этом. Что мешает мне реализовать это, так это то, что вы не можете установить жесткую связь между подобъемами. Вы также можете создавать моментальные снимки только субтомов -> Один подобтом для каждого клиента резервного копирования. Таким образом, функция дедупликации на уровне файлов не может сосуществовать с этим подходом. И эта дедупликация на уровне файлов обычно экономит много места. Вы хотите создать резервную копию только одного сервера?

Если бы в btrfs была дедупликация на уровне блоков, этой проблемы, вероятно, можно было бы избежать, но это также обычно невыносимо медленно ...

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

Я спрашиваю, потому что думаю о добавлении такой функции коровы, но не знаю, следует ли мне это из-за недостатков, перечисленных выше.

Изменить: UrBackup поддерживает резервное копирование, как описано в вопросе, теперь с ядрами Linux> = 3.6 (с поддержкой перекрестных ссылок на том). См. , как его настроить.

На вики-странице btrfs « Примеры использования » перечислены некоторые инструменты: SnapBtr , Snapper, btrfs-time-machine, UrBackup.

Там предложение по встроенному инструменту под названием autosnap :

Используя функцию autosnap, вы можете настроить btrfs для создания регулярных снимков или снимков на основе событий и дальнейшего автоматического управления снимками.

Автопривязка - это не просто о создании снимка, но также об управлении созданными снимками, на данный момент вы можете настроить автоматическую привязку для удаления снимков на основе используемого пространства файловой системы.

Однако по состоянию на октябрь 2013 года в wiki указано, что " Функция автоматической привязки в настоящее время не включена в исходную версию btrfs. "

У меня было похожее разочарование, так что в итоге я создал несколько сценариев, которые я называю snazzer. Вместе они предлагают снэпшот, обрезку, измерение и транспортировку по ssh (но на сегодняшний день могут отправлять/получать и в/из локальных файловых систем). Измерения - это только отчеты о подписях sha512sum и PGP траекторий снимков. Он не совсем готов к релизу, но я был бы рад услышать отзывы, если у кого-нибудь есть время, чтобы просмотреть его на этой ранней стадии.

CLI только на данный момент, но я потратил некоторое время, чтобы сделать его простым в использовании на системах с большим количеством подтомов btrfs - обычно у меня есть отдельные подтомов для /var/cache, /home и так далее. которые, возможно, придется исключить из снэпшотов или иметь более/менее агрессивные графики распечатки.

Боюсь, что алгоритм распечатки чисто принимает решения о наличии набора снэпшотов и их дат, нечего продолжать распечатку до тех пор, пока не будет достигнуто ограничение на использование диска - что вы удаляете в первую очередь? Сократить сначала количество почасовых, или дневных? Может быть, сократить самое старое, Эг. ежегодники? Различные развертывания будут иметь разные приоритеты; и я не могу знать, является ли это единственным уровнем резервного копирования (в этом случае вы не должны бросать старые резервные копии в случае юридических/страховых обязательств), или просто промежуточный (в этом случае вы, вероятно, эти годовые архивируются в безопасном месте в другом месте).

В какой-то момент я добавлю поддержку ZFS и/или интероперабельность; она написана в основном в оболочке posix-ish и на perl из-за сильного желания "нулевых" зависимостей в данный момент, я надеюсь, что в какой-то момент будет поддерживаться более чистая альтернативная реализация на питоне.