Дуже важливим аспектом, про який я не бачив обговорюваних в інших відповідях, є особливості стабільності макетів файлової системи на диску (наприклад, розгляньте консультацію з документацією можливих кандидатів 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
Незважаючи на те, що питання вимагає зосередження уваги на рішеннях файлової системи, я хотів би звернути увагу на те, що більшість із того, що надає файлова система (кешування, журнали, повернення виділеного простору, виділення блоків тощо), не є обов'язковою користю для резервних даних. набагато, коли його лише пишуть і читають гуртом і rarley. Для цього я хотів би розглянути питання про використання parchiveдоповнення tarрезервного копіювання в якості більш оптимального рішення для резервного копіювання, так як кодові , використовуваних в процесі ес знижується, і , отже, менше помилок , якщо є менше «особливість».