Чи підходить btrfs як резервна файлова система?

Зараз у мене є досить традиційна структура файлової системи резервного копіювання поверх ext4. Кожен раз, коли робиться резервне копіювання, створюється нова папка backup-DATE, до якої файли rsync'ed (з жорсткими посиланнями, зробленими за допомогою --link-destпараметра rsync ).

Оскільки я читав про бітрот, я хотів би мати контрольну суму для всіх файлів, прозоро. Мабуть, ext4 не може цього зробити, але btrfs пропонує підтримку контрольних сум даних (і навіть вбудованого режиму RAID1). Для початку я хотів би використовувати btrfsяк "тупу" файлову систему, яка підтримує контрольні суми даних без використання її розширених функцій, таких як RAID, знімки в підтомних томах, надсилання / отримання тощо.

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

"Хоча багато людей надійно користуються ним, все ще виникають проблеми. Ви повинні зберігати та перевіряти резервні копії своїх даних та бути готовими до їх використання." - Початок роботи

"Чи стабільна btrfs? Довга відповідь: [..] Що б ви не робили, ми радимо зберігати хороші, перевірені, позасистемні (та поза сайтом) резервні копії." - FAQ .

Моє використання - мати резервну копію в режимі офлайн. З цієї причини диск буде мати дуже мало використання (як у години) і буде часто підключатися / відключатися від мережі (eSATA або USB 3.0). Наявність надійної файлової системи є обов'язковою. Він не повинен бути гіршим, ніж ext4 Wrt. відключення електроживлення, нечисті відключення тощо.

Насправді рекомендується використовувати btrfs як файлову систему для резервного копіювання? Чи є інші властивості btrfs, які можуть зробити її менш (або більше) придатною?

Я просто дам коротку відповідь, тому що я думаю, що це недооцінка.

Якщо ви прочитаєте головну вікі ядра про команди btrfs (sub-) , ви побачите, що є дві команди для:

1. створення "резервної копії" :btrfs-send
2. і відновити :btrfs-restore

Про всяк випадок це означає, що це не резервне копіювання, а файлова система знімків із ідеєю відкочування, якщо це потрібно, не як резервна копія, а як "гнучка".

Тому - ні, не використовуйте його як резервне копіювання - використовуйте його як версійну файлову систему, де ви можете перевірити речі та повернутися назад. Не покладайтеся на це.

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

Хороша річ: я не втратив дані. btrfs, здається, завжди відповідає принаймні для читання, але це показало мені, що це ще далеко від виробничої готовності.

У будь-якому разі, на сервері я все ще використовую його як резервну копію, тому що там мені потрібна функція копіювання корів для дедуплікації (саме ваш випадок використання). Дані мають занадто великий розмір для традиційної файлової системи.

Оновлення

У мене все ще є файлова система на моєму сервері (див. Вище), але вона зламалася відразу після публікації цього тут. Тепер у мене є великий обсяг резервного копіювання, який є лише для читання, 700G, який би розширився до ~ 7 ТБ на ext4, якщо я спробую скопіювати все, що використовується tar|tar. Через брак часу я ще не перевіряв, чи можуть впоратися новіші версії ядра. Актуальною проблемою є "переривання транзакції", яке займає ~ 2 секунди після монтажу запису і оновляє обсяг лише для читання. Первісна причина - це, мабуть, зламана версія btrfs-convert, яку я використовував років тому, коли я створив цей об'єм, і все ще обмежений набір функцій струму, btrfs checkякий, принаймні, повинен мати змогу знайти всі пошкодження на томі, який відтворюється, що може призвести до відмови транзакції або будь-які інші проблеми, а не просто сказати, що моя файлова система здорова.