Подходит ли btrfs в качестве резервной файловой системы?

Прямо сейчас у меня есть довольно традиционная структура файловой системы резервного копирования поверх ext4. Каждый раз, когда выполняется резервное копирование, создается новая папка, backup-DATEв которую rsync загружаются файлы (с жесткими ссылками, созданными с помощью параметра rsync --link-dest).

Поскольку я читал о bitrot, я хотел бы иметь контрольную сумму для всех файлов, прозрачно. Очевидно, что ext4 не может этого сделать, но btrfs предлагает поддержку контрольных сумм данных (и даже встроенный режим RAID1). Для начала я хотел бы использовать btrfsв качестве «тупой» файловой системы, которая поддерживает контрольные суммы данных без использования ее расширенных функций, таких как RAID, объемные снимки, отправка / получение и т. Д.

Однако их вики не вселяют уверенности в файловой системе для целей резервного копирования:

«Хотя многие люди используют его надежно, все еще возникают проблемы. Вам следует сохранять и тестировать резервные копии своих данных и быть готовыми к их использованию». - Начало работы

«Является ли btrfs стабильным? Длинный ответ: [..] Что бы вы ни делали, мы рекомендуем хранить хорошие, проверенные резервные копии вне системы (и вне сайта)». - FAQ .

Мой вариант использования - иметь автономную резервную копию. По этой причине диск будет очень мало использоваться (как в часах) и будет часто подключаться / отключаться (eSATA или USB 3.0). Наличие надежной файловой системы является обязательным. Это не должно быть хуже, чем ext4 по отношению к. сбои питания, нечистые отключения и т. д.

На самом деле рекомендуется использовать btrfs в качестве файловой системы для резервного копирования? Существуют ли другие свойства btrfs, которые могут сделать его менее (или более) подходящим?

Я просто дам краткий ответ, потому что я думаю, что это обдумывается.

Если вы прочитаете основную вики- версию ядра о командах btrfs (sub-) , вы обнаружите, что есть две команды для:

1. сделать «резервную копию» :btrfs-send
2. и восстановить :btrfs-restore

На всякий случай это означает, что это не (задумано, чтобы быть) резервное копирование, а быть файловой системой моментального снимка, с идеей отката при необходимости, не как резервная копия, а как «гибкая».

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

Недавно у меня были проблемы с файловой системой btrfs в современном ядре 4.10.0. Файловая система была разрушена в виртуальной машине VM, потому что TRIM, кажется, где-то неправильно реализован, и AFAIK она имела какое-то отношение к индексным номерам вложенных томов. После переключения на VMware файловая система все еще была повреждена и, к удивлению, btrfs checkне смогла найти и исправить ошибку. Наконец я переключился обратно на ext4.

Хорошая вещь: я не потерял данные. Кажется, что btrfs всегда последовательны, по крайней мере, для чтения, но это показало мне, что это все еще далеко от готовности к производству.

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

Обновить

У меня все еще есть файловая система на моем сервере (см. Выше), но она сломалась сразу после того, как я разместил это здесь. Теперь у меня есть большой резервный том только для чтения 700 ГБ, который расширится до ~ 7 ТБ на ext4, если я попытаюсь скопировать все, используя tar|tar. Из-за нехватки времени я еще не проверял, могут ли новые версии ядра справиться с этим. Фактическая проблема - «прерывание транзакции», которое происходит через ~ 2 секунды после монтирования для записи и перемонтирует том только для чтения. Первоначальной причиной, вероятно, является неверная версия btrfs-convert, которую я использовал несколько лет назад, когда создавал этот том, и все еще ограниченный набор функций текущего, btrfs checkкоторый по крайней мере должен быть в состоянии найти все повреждения тома, которые воспроизводимо приводят к прерыванию транзакции. или любые другие проблемы, вместо того, чтобы просто сказать, что моя файловая система здорова.