btrfs: отображение тома во внешний файл

Question

Недавно я построил систему с корневым разделом btrfs . Наиболее убедительной причиной для принятия btrfs по сравнению с ext4 , в моем случае, были живые снимки копирования при записи с почти нулевой задержкой. По сравнению с ext4 , когда полное резервное копирование системы влечет за собой удаление системы, монтирование из оперативного дистрибутива и создание образа partclone на съемном носителе, обещание моментальных снимков состоит в том, что моментальный снимок может быть записан на резервный носитель, пока система работает ,

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

В документации предлагается отразить дерево каталогов с помощью такого инструмента, как rsync, или с помощью btrfs-send/btrfs-receive чтобы зафиксировать дополнительные изменения в другой системе. В первом случае я всегда находил практически невозможным воссоздание всех метаданных в дереве файлов точно путем зеркального отображения дерева файлов, а не создания образа файловой системы, и у меня был небольшой оптимизм в отношении того, что восстановление будет очень гладким. Я всегда нахожу, что некоторые метаданные, будь то разрешения, временные метки, скрытые файлы и т.д., Не фиксируются должным образом. Проблема усугубляется, когда передача происходит через файловые системы разных типов. В другом предложении предполагается, что доступна другая файловая система btrfs , что не всегда так.

Доступны ли какие-либо предложения для сохранения или восстановления изображения уровня громкости, аналогичного файлу partclone, но представляющего только выбранный подобъем?

Answer 1

btrfs send и btrfs receive - это именно те инструменты, которые вам нужны.

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

Вы пробовали инструменты? У меня не было таких проблем с btrfs . btrfs send и btrfs receive не работают с файлами, они работают со всеми подобъемами, изначально имея доступ ко всем метаданным Btrfs.

Проблема усугубляется, когда передача происходит через файловые системы разных типов. Другое предложение предполагает, что доступна другая файловая система Btrfs, что не всегда так.

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

Однако с полным дампом вы получаете отдельный поток, который представляет собой образ (но не резервную копию с возможностью просмотра, если вы не восстановите ее с помощью btrfs restore ). Работайте с ним, как с любым другим потоком:

btrfs send /source/subvolume >/another/filesystem/subvolume-image   # just a file
# (or you can gzip it and/or send with nc on the fly, whatever)
# then later
</another/filesystem/subvolume-image btrfs receive /some/btrfs/directory

Где /some/btrfs/directory может принадлежать той же файловой системе Btrfs, что и /source .