Яка файлова система для резервного копіювання найкраща? [зачинено]

Закрито . Це питання ґрунтується на думці . Наразі відповіді не приймаються.

Хочете вдосконалити це питання? Оновіть питання, щоб на нього можна було відповісти фактами та цитатами, відредагувавши цю публікацію .

Закрито 6 років тому .

Я щойно купив диск, щоб створити резервну копію всіх моїх документів і зберігати їх окремо, і я не знаю, яка файлова система під Linux була кращою надійністю. Можливо, я буду робити резервну копію один раз на місяць, і вона не буде підключена весь час, але я хочу бути впевненим, що мої дані залишаться.

Може бути, ext4?

filesystems backup ext4

— xabim
джерело

Жодна конкретна файлова система не змусить ваші дані зникати під час відключення диска, тому це не є вимогою. (Самі ЗМІ можуть по- , як і раніше зазнають невдачі, але файлова система не допоможе вам багато.) Це питання може бути підзвітні , якщо ви заявляєте ваші вимоги, такі як резервний розмір диска, максимальний розмір файлу , який необхідно зробити резервну копію, кількість файлів і будь-які необхідні особливості файлової системи (жорсткі посилання, ACL, розширені атрибути, ...). Крім того, як зазначалося, може бути дуже вартим, щоб розглянути файлову систему, відмінну від тієї на основному диску.

— CVn

Відповіді:

Питання суб’єктивне.

EXT4 вважається стабільним і підтримує ведення журналів (як EXT3, але не EXT2), що допомагає при корупції.

BTRFS досі експериментальний, але пропонує набагато більше можливостей.

У Reiser4 , TUX3 , XFS , різних реалізаціях ZFS тощо існує багато варіантів .

Особисто я використовую EXT4 на всіх своїх накопичувачах і не мав проблем із FS.

Мені невідомі якісь показники стабільності (хоча можуть бути і деякі "білі газети"), але Phoronix має показники ефективності

Нарешті, це питання може бути дублікатом стійкої до Rock файлової системи для великих файлів (резервного копіювання) для Linux

— простонаростаючий
джерело

відзначити сучасні (після 2012 року) ext4робить контрольну суму на більшість , але не всі метадані, і до жаль , не фактичним на даних вмісту файлів (які BTRFS або ZFS робить). Також деякі частини стабільної (як і більше не змінюється, і база коду добре перевірена) на макеті диска ext4є зайвим, оскільки я відображав unix.stackexchange.com/a/499668/24394 , але більшість даних це не так. Якщо ext4використовується як резервна копія, подумайте про підвищення її "відновлення" за допомогою e2imageінструменту!

— humanityANDpeace

Оскільки пропозиція відповідей ext4не забезпечує ні контрольної суми, ні посилених заходів захисту надмірності для файлів, які вона зберігає, було б доцільно вкласти кошти для обчислення - принаймні дуже важливих файлів у резервній копії fs - par2/ parchiveфайлів, які забезпечували б перевірку та доповідність (до певною мірою) та захищати від виникнення нечитабельних секторів, додаючи до цих файлів змінну (за замовчуванням 5%) додаткових даних про надмірність Reed-Solomon. Це захистило б від "мовчазної корупції" та "помітної" бітової гнилі .

— humanityANDpeace

Я завжди беру інший FS для диска резервного копіювання, ніж для основного диска, тільки тому, що якщо я потрапив у дивну помилку FS, я також не потрапляю на її резервний носій.

— хашир
джерело

Не могли б ви пояснити, про яку дивну помилку FS ви думали? (Ідеально з історичним прикладом, який теж міг вплинути на резервний диск)

— Мартін Тома

Ну, зазвичай ви копіюєте не файлову систему, а файли. Це означає, що ви просто передаєте дані, і файли фактично створюються знову в цільовій файловій системі. Таким чином, "помилки FS" не грають жодної ролі. Тільки якщо ви зробите резервну копію файлової системи в цілому (наприклад, демппіруйте її dd), ви фактично скопіюєте ваші "помилки FS". Але тоді ви, як правило, не турбуєтесь про цільову файлову систему і безпосередньо скидаєте копію на розділ жорсткого диска.

— R Кисельов

@RKiselev так і ні. У вас все-таки є деякі переваги / недоліки в різних файлових системах, наприклад, HFS + виходить з корупції, де немає та інших файлових систем, які підтримують контрольні суми файлів (інших лише метаданих), тож не погана ідея мати різні fs

— hashier

@RKiselev Або APFS просто втрачає файли youtube.com/watch?v=k60NvrJnNOY при копіюванні . Який саме ваш названий випадок. Ще кілька днів / тижнів тому була ще одна помилка, що файлова система виконувала файли, якщо вони мали конкретне ім’я. Інший FS цього не зробив би, тому помилки FS, безумовно, можуть вас укусити, навіть думав, що я визнаю, це дуже малоймовірно, але оскільки вартість майже нуля два, є два накопичувачі з різним FS, я не бачу причин не робити цього. (Далі різні FS мають різні функції, дуже мала підтримка FS, наприклад, перевірка підбиття файлів)

— hashier

Насправді це було корисно; це допомогло мені оцінити ситуацію - я вважаю це корисним на Stackexchange. Відео є релевантним, воно мене трохи більше хвилює з приводу того, що мої мережеві резервні копії Time Machine знаходяться в розріджених групах, навіть якщо вони HFS +.

— Андреас