Як зробити зайву настільну систему з щоденними знімками? (Чи готові btrfs до використання?)


12

Я хочу налаштувати настільну систему, в якій домашня файлова система була б надлишковою (наприклад, RAID-1) і мала б робити щотижневі знімки. Я вже робив це з ZFS, система знімків прекрасна, і за допомогою send / recv ви можете легко створювати резервні копії на зовнішніх носіях. На жаль, в цей момент я хочу GNU + Linux, а не FreeBSD або Solaris, тому я шукаю пропозиції щодо хороших альтернатив.

Я вважаю, що моїми альтернативами є:

  1. btrfs - це, здається, саме те, що мені потрібно, у ньому є знімки та команди, які дозволяють легко копіювати zfs send. Але вся документація зазначає, що вона все ще експериментальна. Я, здається, не можу знайти жодних фактичних звітів щодо питань його надійності та зручності використання. Чи можете ви вказати мені якусь інформацію з цього питання, яка могла б уточнити, чи це був би можливий вибір? Я маю перевагу перед цим варіантом, здебільшого тому, що я не хочу переформатувати накопичувачі, коли btrfs стане готовим, але у мене немає інформації про те, чи він взагалі корисний, чи дурна думка його використовувати тощо. Питання що я не можу отримати відповідь на те, що означає "експериментальний" .
  2. Знімки lvm та ext4 - бажано, ні, оскільки це може зайняти жахливу кількість місця при створенні нових файлів. Для створення файлів 200 ГБ потрібно 200 ГБ вільного місця та додатково 200 Гб для знімків. Я також виявив це ненадійним - невдале перезапис метаданих призводить до нечитабельного PV. Мені цікаво, як тут би порівнювали btrfs.
  3. Єдина файлова система (ext4) в масиві RAID-1 зі спеціальними знімками COW із жорсткими посиланнями (як cp -al). Це моє сьогоднішнє уподобання, якщо я не можу використовувати btrfs.

То як експериментальні btrfs, що я повинен вибрати, і чи є у мене інші варіанти? Що робити, якщо я не зберігаю додаткові резервні копії, це вплине на мій вибір?


1
Повторне 3: Посилання на жорстких посиланнях насправді не створюють гарної резервної копії ... якщо ви модифікуєте або пошкоджуєте оригінал, те саме відбувається з усіма "копіями".
grawity

Влучне зауваження. Я не вважав цього. Дякую.
TestUser16418

@grawity, ви не повинні безпосередньо змінювати знімки. У цьому суть їх. Вони повинні бути картиною вашої системи «лише для читання» колись раніше.
g19fanatic

@ g19fanatic: Точно моя думка. Якщо ваші «знімки» робляться шляхом жорсткого посилання, то зміна живої копії файлу також призведе до зміни «знімків» (оскільки жорсткі посилання не копіюють дані).
grawity

1
@grawity: я не думаю, що він має на увазі жорстке посилання таким же чином, як ви думаєте. Подумайте про програмне забезпечення Apple TimeRestore. вона робить початкову копію всього, як перший знімок. Потім кожен знімок після цього використовує жорстке посилання на файли на знімку до нього для файлів, які не змінилися. Якщо файл змінився, замість цього робиться або диференціальна, або безпосередньо копія, а не жорстке посилання на попередній знімок. використовуючи цей метод, коли ви модифікуєте файл в реальному часі, ви не будете змінювати резервні копії, оскільки вони працюють з моментних знімків, а не живих даних.
g19fanatic

Відповіді:


0

Ця відповідь зберігається з історичних причин і може не стосуватися поточних версій btrfs.


btrfs експериментальний у тому сенсі, що він все ще може бути змінений. В результаті btrfs може бути не повністю стабільним. Крім того, оскільки в даний час не існує fsck для btrfs, можливо пошкодити файлову систему та зробити її непридатною у разі відключення живлення, оскільки немає коштів для відновлення шкоди. Додаткову інформацію про цю файлову систему див . У wiki brtfs . Поки утиліта перевірки файлової системи не буде готова, я б не рекомендував btrfs, і, мабуть, найкраще буде вибрати варіант 3.


За конструкцією, BTRFS насправді не потребує fsck . BTRFS має контрольні суми, тому скраб надійно виявить помилки (і виправить їх, якщо можливо, залежно від надмірності). Інші файлові системи, такі як ext4, можуть очищатись після аварії, але вони точно не знають, чи щось було пошкоджено. Крім того, більшість основних функцій BTRFS вже не слід вважати експериментальними.
основні6

7

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

Деякі причини, які, як правило, наведені для того, щоб не використовувати його у виробництві: формат на диску може бути нестабільним, немає btrfsck, немає підтримки. Тож давайте вивчимо:

Останнє - це те, що насправді це говорить для мене. Якщо Oracle - компанія, яка обслуговує програмне забезпечення - тепер готова надати вам комерційну підтримку для цього, то, ймовірно, вона готова. Звичайно, вони сильно зацікавлені ніколи не говорити, що версія з відкритим кодом (яка, наскільки я знаю, одне і те ж програмне забезпечення, просто немає контракту на підтримку) насправді готова до використання, оскільки вони хочуть, щоб ви придбали підтримку та Звичайно, вони не хочуть, щоб їх звинувачували, якщо ви самі підете і зробите щось непідтримуване і підірвете свої диски, але я сумніваюся, що вони будуть готові підтримати це взагалі, якби вони дійсно думали, що це втратить дані.


0

Хоча це не відповідає на питання btrfs, ви написали "Я вже це робив із ZFS, система знімків чудова, і за допомогою send / recv ви можете легко створювати резервні копії на зовнішніх носіях. На жаль, в цей момент я хочу GNU + Linux ", а станом на 2013 рік є http://zfsonlinux.org/ - насолоджуйтесь!


ZFSonLinux справді працює дуже добре. Але його потрібно встановити вручну (хоча є деякі сховища).
основні6

0

Snapper - це інструмент, який автоматизує цей процес для вас. Ви можете мати погодинні знімки, якщо хочете, різні інтервали знімків на підгрупу, легкий відкат, автоматично видаляйте старі знімки afaik, у нього навіть є gui.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.