Рок-стабильная файловая система для больших файлов (резервных копий) для Linux

Какая файловая система будет лучше для резервных копий? Меня интересует, прежде всего, стабильность (особенно некоррупционность файлов во время принудительной перезагрузки и т. Д.), Но также важно то, насколько эффективно он обрабатывает большие (> 5 ГБ) файлы.

Кроме того, какие параметры монтирования я должен использовать?

Ядро Linux> = 2.6.34.

РЕДАКТИРОВАТЬ: я не хочу методы резервного копирования. Мне нужна файловая система для их хранения.

Вы можете использовать ext4, но я бы порекомендовал монтировать с journal_dataрежимом, который отключит Deloc (отложенное размещение), что вызвало некоторые более ранние проблемы. Отключение dealloc сделает запись новых данных медленнее, но запись в случае сбоя питания с меньшей вероятностью приведет к потере. Я должен также упомянуть, что вы можете отключить dealloc без использования, journal_dataчто имеет некоторые другие преимущества (или, по крайней мере, это было в ext3), такие как немного улучшенное чтение, и я считаю, что лучшее восстановление.

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

ext4 также fsckбыстрее чем ext3.

Последнее замечание: в ext4 были исправления до версии 2.6.31? Я бы в основном удостоверился, что вы не используете ядро ​​до 2.6.32, которое является ядром LTS.

XFS очень прочная и была в ядре целую вечность. Изучите инструменты, такие как xfs_freeze, и посмотрите, ищите ли вы это. Я знаю, что это очень субъективно, но я использовал XFS для хранения данных в течение многих лет без инцидентов.

Просто используйте инструмент резервного копирования, который поддерживает контрольные суммы. Например, Дар делает, и он поддерживает инкрементные резервные копии. Затем вы можете выполнить резервное копирование в надежную файловую систему, например ext3.

Для резервных копий вы хотите что-то твердое / очень стабильное. И btrfs или ZFS просто не готовы сегодня.

btrfs имеет прозрачную контрольную сумму данных, записанных на диск, и режим быстрой упорядоченной записи, который всегда включен (и многие другие удобные функции резервного копирования), что делает его привлекательным для резервного копирования. См. Https://btrfs.wiki.kernel.org/index.php/Main_Page для получения дополнительной информации.

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

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

Что касается того ext4, что, как говорят, имеет хорошие характеристики, что касается давно проверенной базы кода ( https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0. pdf показывает, что на поиск ошибок в ней уходит больше времени, чем, например, в более современных и более сложных btrfs), я изучил устойчивость ext4 в состоянии покоя и обнаружил некоторые недостатки в файловой системе.

Я считал бы разумным (если выбран в ext4качестве « Несокрушимая фс резервного копирования ») , чтобы улучшить восстанавливаемость (хотя „закалка его“), используя e2imageприспособление разработчиков ext4обеспечить

Программа e2image сохранит критические метаданные файловой системы ext2, ext3 или ext4, расположенные на устройстве, в файл, указанный в image-file. Файл изображения может быть проверен dumpe2fs и debugfs, используя опцию -i для этих программ. Это может помочь эксперту в восстановлении катастрофически поврежденных файловых систем. В будущем e2fsck будет улучшен, чтобы иметь возможность использовать файл образа для восстановления сильно поврежденной файловой системы.

и рекомендую .

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

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

Чтобы нейтрализовать этот «недостаток» ext4и сделать его более rock-solidважным с точки зрения структуры диска, было бы разумно дополнить эту избыточность и восстановление содержимого файла с помощью par2/ parchive.

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