Чи вважаються знімки + RAID гарним рішенням резервного копіювання на місці?

Дві основні причини, про які я можу подумати для створення резервних копій, здається, слід потурбуватися, коли я використовую як знімки, так і RAID разом із btrfs. (Під RAID тут я маю на увазі RAID1 або 10)

• Випадкове видалення даних: знімки охоплюють цей випадок
• Збій накопичувача та бітової гнилі
  • Повна помилка: RAID охоплює цю справу
  • Привід повертає погані дані: функція виправлення помилок RAID + btrfs стосується цього випадку

Отож, як рішення для резервного копіювання на місці, це, здається, працює добре, і для нього навіть не потрібен окремий пристрій зберігання даних!

Однак я чув, що і RAID, і знімки не вважаються належними резервними копіями, тому мені цікаво, чи я щось пропустив.

Окрім того, що btrfs ще не є зрілою технологією, ви можете придумати що-небудь, що я пропустив? Або моє мислення правильне, і це дійсне рішення для резервного копіювання на місці?

Ні це не так.

Що відбувається, коли ваша файлова система або RAID-об'єм пошкоджується? Або ваш сервер підпалюється? Або хтось випадково форматує неправильний масив?

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

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

І регулярно перевіряйте, чи можна відновити "відправлений знімок".

Ось як я реалізував швидке резервне копіювання деяких моїх серверів: зберігати дані на ZFS, робити знімок ZFS, відправляти дельту на інший сервер, де вся файлова система відновлюється (за вирахуванням фактичної роботи служби).

Звичайно, найкраща резервна копія завжди поза сайтом. Таким чином, після "доставки" знімків до окремої системи регулярно робіть "знімання" знімків.

Отже, у моїй системі сервер, який отримує дельти знімків, регулярно скидає всі свої пули ZFS (включаючи попередні знімки) на стрічку.

І звичайно, протестуйте свої касети, щоб переконатися, що вони можуть бути відновлені.

Примітка. Ви хочете, щоб знімок відбувся під час роботи на дисковому режимі, і, бажано, у координації з базою даних (якщо така є) для забезпечення послідовності; в іншому випадку вилікування може бути гірше, ніж хвороба. Ось чому дуже корисна функція NetApp & EMC "Live Snapshot": вони відкладуть знімок LUN, поки база даних, що використовує LUN, не вкаже, що знімок безпечно виконувати.

Що сказав HopelessN00b. Ні.

Належне резервне копіювання є на окремому пристрої, ніж резервне копіювання пристрою. Що станеться, коли ви втратите два або більше накопичувачів? Що відбувається, коли ваша серверна кімната згоряє? Що відбувається, коли хтось випадково знищить ваш масив?

(Попередження про анекдот: Я одного разу чув про того, хто PXE встановив автоматичну установку останньої Fedora. Його ДБЖ не вдалося. Після відключення електроенергії його сервер перезавантажився і встановив завантаження PXE і ... встановив Fedora над його даними. My пункт? Відчуваючі речі трапляються. На щастя, у нього були належні резервні копії.)

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

Правильно реалізовані знімки ОБОВ'ЯЗКОВО підтримуються вашим сховищем, оскільки гідні резервні копії використовують їх як перший етап створення завдання резервного копіювання. Однак погана ідея використовувати знімки для первинного резервного копіювання. Причини:

1) Знімки та резервне зберігання МОЖУТИ не вдатися. Тому для реальних резервних копій потрібно використовувати окремий шпиндельний набір, або є великий шанс втратити як основний робочий набір, так і резервні дані @ одночасно.

2) Знімки «пережовують» корисний простір. Має сенс використовувати дороге і швидке зберігання для поточних гарячих даних, а також знімків та резервних копій без завантаження, що є крижаними даними, для більш дешевого та повільного зберігання. Це дуже добре працює з 1) BTW.

3) Знімки зазвичай сповільнюють весь процес. Більшість систем використовують Copy-on-Write і такий підхід створює фрагментацію. Перенаправлення на запис - швидше, але їжте багато місця. Дуже мало постачальників правильно реалізували знімки. NetApp з WAFL та Nimble Storage з CASL (я не прихильний до жодного з них). У майже всіх інших є проблеми. Наприклад, тригер Dell Equallogic - оновлення (та відходи) 15 Мб кожного зміненого байта. Це ВЕЛИЧЕЗНО.

Так. Це ідеальний спосіб зберігання резервних копій. Нічого іншого не потрібно, чорт забирай, навіть робити перевірки на доброчесність - це просто витрачений час.

Просто для підтвердження - перш ніж я дам більше порад ... ти працюєш на мого конкурента, правда? Ви дійсно так, звичайно? Ні? Ой.

Вибачте, NUTS. Ні, зовсім ні. Вибач, чувак.

Проблема полягає в тому, що ви повністю відкриті до будь-яких помилок, які трапляються в (a) системі та (b) на рівні операційної системи. Ви в основному захищаєте лише від того, щоб хтось видалив якісь дані. Приємно. Це часто виникає помилка.

Від чого ви не захищаєте:

• Шип потужності витирає машину. Був там, бачив це.
• Якийсь несправний контролер рейду чи пам'ять, що записує sh ** на диск, - йде щось.

І довгий перелік інших речей.

Це - природно, якщо ви не працюєте на мого конкурента - ви завжди робіть резервну копію:

• На іншому комп’ютері
• Що ви ізолюєте щонайменше від шипів потужності (навіть якщо у вас є USV).

Ось чому стрічки гойдаються - вони не з'єднані між собою, і нічого короткого вогню чи повені їм не зашкодить. Спік потужності - йде зчитувач магнітол і, можливо, робот, але на касети, які не в читальнику, це не вплине.

НАЙКРАЩЕ було б резервне копіювання за межами місця (чи я вже згадував такі речі, як пожежа та затоплення?) (Знову, коли ви працюєте для конкурента - немає такої речі, як пожежа на будівництві, вона абсолютно не потрібна, як пожежна страховка, будь ласка, заощадити ці гроші).

Тепер ви можете подумати "о, затоплення ніколи не буває". Переконайтесь, що ви впевнені. Дивіться, ось відео 09.09.09 затоплення центру обробки даних водофона. Я впевнений, що ви зрозумієте, в чому проблема для insite / в резервному копії комп'ютера:

http://www.youtube.com/watch?v=ttcQy3bCiiU

Урок, засвоєний двома накопичувачами RAID-1, які вийшли з ладу протягом півгодини один від одного: RAID - це не резервний механізм, ні в якому разі, формі чи формі.

RAID - це механізм доступності, який скорочує час простою в разі відмови обладнання, але він взагалі не допоможе вам у разі, наприклад, вірусів, видалення / модифікації даних або простої катастрофічної несправності обладнання.

Багато досвідчених адміністраторів працюють із тим, що відомо як правило резервного копіювання 3-2-1:

• У вас має бути принаймні три копії даних, включаючи першоджерело. Тобто одне резервне копіювання НЕ досить і копій в межах однієї і тієї ж фізичної системі не враховуються.

• Ви повинні використовувати щонайменше два різні методи резервного копіювання.

• У вас повинна бути хоча б одна копія даних, що не входять у сайт.

Знімки порушують усі три частини:

• Ви використовуєте лише одну фізичну машину. Все, що впливає на всю машину, наприклад, несправність блоку живлення, може взяти з собою всі ваші дані.

• Ви використовуєте лише один метод для створення резервних копій. Якщо з цим щось не так, ви дізнаєтесь лише при відновленні резервного копіювання в кризовій ситуації.

• У вас немає резервних копій поза сайтом. Повені та пожежі трапляються лише для інших, поки вони не трапляться з вами ...

Тому:

• Потрібно мати принаймні одну резервну копію на окремому апараті вашої локальної мережі.

• Потрібно мати принаймні одну резервну копію, яка не генерується за допомогою знімків. Можливо, добрий-старий поступовий tarархів може бути в порядку? Або на rsyncоснові копії?

• Потрібно мати принаймні одну віддалену резервну копію, якомога далі від поточного місця розташування та точно не в одній будівлі.

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

Знімки на рівні файлової системи повинні бути кращими, але вони все одно не гарантують узгодженість ваших файлів. Для багатьох додатків (сервери баз даних приходять на думку) копіювання файлів живого екземпляра може бути абсолютно марним, оскільки вони можуть перебувати в непослідовному стані. Вам потрібно буде використовувати власний механізм резервного копіювання на рівні додатків, щоб забезпечити існування чистої копії - для якої також застосовуватиметься правило 3-2-1.

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

Сам по собі це зовсім не резервне рішення . Це дозволить зменшити або усунути простої в деяких випадках відмови , але не захищає взагалі від багатьох інших

Звичайно, це може бути дуже цінною частиною більш закругленого рішення про доступність та резервне копіювання:

• RAID плюс знімки того ж обладнання
• Копіювання на місці іншого обладнання (пам’ятайте: існують режими відмов, які витягуватимуть всю коробку, контролер, накопичувачі та все за один раз)
• Напіввідключені віддалені копії
• і звичайно належні офлайн + виїзні копії для справжніх лих

Також: переконайтеся, що ви регулярно перевіряєте свої резервні копії. Найгірший час для виявлення ваших резервних копій не працює - це коли вам потрібно щось із них отримати ...