Какую файловую систему следует использовать для форматирования внешнего резервного жесткого диска? Btrfs?

По словам главного разработчика BTRFS, у BTRFS все еще есть некоторые проблемы, поскольку файловые системы становятся полными. Функция отправки / получения для отправки / получения различий моментальных снимков для автономного резервного копирования также еще не полностью функциональна, и дедупликация в режиме онлайн (полезная для резервного копирования образов виртуальных машин) произойдет , может быть для ядра 3.11 (не еще не выпущен). Поддержка raidz была новой для 3.10, и у меня еще не было возможности протестировать ее, я могу сделать это сегодня вечером. В целом, BTRFS все еще находится на стадии активной активной разработки, и я предпочитаю подождать, пока она не будет завершена (или, по крайней мере, не получать существенных улучшений функциональности с каждым выпуском ядра!), Прежде чем фактически использовать ее в работе.

Преимущество использования BTRFS или ZFS на внешнем корпусе, используемом для резервного копирования на основе rsync, состоит в том, что вы можете делать моментальные снимки, например, с помощью. ежедневное задание cron, а затем совершите путешествие во времени, чтобы извлечь старые данные, если это необходимо (если, скажем, файлы исчезли с вашего жесткого диска по неизвестным причинам, и вам необходимо вернуть их из прошлых резервных копий). Я использую корпус USB3 с ZFSonLinux для этой цели, потому что мне нужна поддержка дедупликации для виртуальных машин (поскольку большой файл .img всегда отличается от перспективы rsync, дедупликация означает, что только фактические измененные блоки в .img изменение файла в резервной копии, а не в нескольких копиях огромных файлов размером 30 ГБ). Надеемся, что когда выйдет ядро ​​3.12, поддержка дедупликации BTRFS станет достаточно зрелой, чтобы я мог перейти с ZFS для этого приложения - ZFS - это круто и все, но тот факт, что он не интегрирован с ядром Linux, вызывает проблемы (например, Я использую виртуальную машину Centos 6.4 для создания резервных копий, потому что ZFS не будет компилироваться с ядром 3.10).

Для резервного копирования файловых систем Linux создайте снимок на BTRFS (или LVM), смонтируйте снимок (если LVM) и создайте его резервную копию с помощью rsync. Это гарантирует, что у вас будет согласованная резервная копия на момент создания снимка. Затем, когда закончите со снимком, удалите его. (Более важно с LVM, так как снимки имеют существенное влияние на производительность). Мой сценарий cron, который запускает задание резервного копирования, также выполняет ротацию моментальных снимков (ежедневно, еженедельно, ежемесячно) в моей файловой системе резервного копирования ZFS до того, как она действительно начинает резервное копирование, чтобы я мог путешествовать во времени, если это необходимо.

Что касается надежности, седой старый ext4, вероятно, является самой надежной файловой системой из-за того, что он статически распределяет структуры на диске, а это означает, что вы всегда можете найти их и, по крайней мере, получить большую часть своих данных в случае неудачного сбоя. Недостатком является низкая производительность в пограничных случаях очень больших файлов (где работа цепочек блоков inode делает произвольный доступ к этим файлам очень медленным), проблемы с большими файловыми системами (которые очень медленны при создании и fsck) или пограничный случай большое количество маленьких файлов (которые исчерпывают таблицу inode). Лично я продолжаю запускать ext4 поверх LVM поверх RAID для моих корневых файловых систем и использую другие файловые системы либо по соображениям производительности, либо по соображениям функциональности по мере необходимости.