Кращі практики для перевірки резервного копіювання?

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

Запускайте вогневі дрилі ... кожні пару місяців, це гарна ідея сказати, що система XYZ не працює ... потім насправді пройдіться рухами щодо повернення її до Інтернету до нового ВМ тощо та ін. помилки.

режим мильниці: УВІМКНЕНО

Я б сказав, що так просто, що резервні копії, які не перевіряються регулярно, не мають нічого.

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

Це було також завданням самого молодшого адміністратора, щоб документація була актуальною. Молодший визначається тим, яку роботу він / вона провів над конкретною системою, колись (досить часто насправді) це робив "менеджер групи"

У нас було спеціальне обладнання, присвячене цьому (одна Intel та одна коробка IBM / AIX), яка мала низькі показники для всього, крім дискового простору, оскільки нам не потрібно було запускати нічого реального на відновленому хості.

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

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

Створюючи домашнє резервне рішення, я б зробив щось подібне:

• Створіть сценарій для резервного копіювання даних.
• Виконайте тестове відновлення, щоб переконатися, що сценарій працює правильно.
• У скрипті або за допомогою інших засобів реалізуйте спосіб відстеження стану резервних копій (успіх, провал, запущений, не запущений).
• Контролюйте цей статус відстеження (електронна пошта, база даних, щось)

Як тільки все це буде зроблено, ви повинні бути добре. Ще одне, що потрібно зробити, - це регулярні реставрації тестів. Якщо у вас є додаткове обладнання, щоб пожертвувати на справу, яка є.

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

Чесно кажучи, якщо ваші дані для вас дуже важливі, вам було б цікаво інвестувати в якесь програмне забезпечення для управління вашими резервними копіями. Є сотні продуктів для цього - від дешевого і простого, до корпоративного класу.

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

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

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

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

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

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

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

Сюди входить ваше програмне забезпечення для резервного копіювання та сервер. Так, вам також потрібно відновити їх.

Не маєте бюджету на придбання спеціальної апаратури для відновлення?

• Зверніть увагу, що вам абсолютно потрібен бюджет. Щоразу нагадуйте особам, які приймають рішення, що дійсного тесту на відновлення ще не відбулося. (І так, зберіть докази, щоб прикрити свою дупу. Жорсткий світ.)
• У більшості організацій періодично виникає необхідність перенесення бізнесу на якусь систему до іншого обладнання, тому використовуйте можливість. Завжди вибирайте для міграції метод «відновити з резервного копіювання», роблячи вигляд, що ви тільки що втратили оригінальне обладнання. Так, це означає більше простоїв, вибачте за це. Принаймні, ви будете впевнені, що ваша резервна копія корисна.
• Ніякої міграції? Можливо, ви можете позичити деяку техніку на два тижні і виконати два тести відновлення (відновіть до запозиченого обладнання, почекайте більше тижня, відновіть із запозиченого до оригіналу, живіть з ним). Зазвичай, якщо є нове обладнання, придбане для якоїсь нової системи, і ви правильно розставляєте речі, ви можете їх легко позичити - запропонувавши вичерпно перевірити його протягом двох тижнів. Якщо нове обладнання не на 100% ідентичне старому, це зробить ваш тест ще кращим. Як дізнатись, якщо ви отримаєте однакове обладнання в разі справжньої катастрофи?
• Якась нова система впроваджується вами на даний момент? Чи можете ви протестувати відновлення прямо зараз? Не використовуйте додаткове обладнання, просто перезапишіть нову систему, оскільки у вас є нові знання, як швидко реалізувати її. Це спрацьовує, якщо поки що не має значних даних. Знову ж таки, перейдіть до виробництва на відновленій версії, а не на щойно перевстановленій версії.

1. Вогневі дрилі.
2. Політика щодо тестування всіх резервних копій кожні 6 місяців - дуже гарна ідея
3. Що стосується тестування, вам потрібно переглянути кожну програму чи систему резервного копіювання. В ідеалі, що являє собою "успішну" чи "відновлювану" резервну копію, слід вказати в Описі служби або SOP (експлуатаційна документація) для вашої резервної копії разом з іншими деталями, такими як час утримання, bladibla.

Ви, ймовірно, виявите, що деякі типи резервного копіювання можуть бути легко відреставровані за допомогою скриптів (наприклад, баз даних), а інші потребують певного введення вручну (відновлення Active Directory). Автоматизуйте скільки завгодно цього, переконайтеся, що є якась звітність, і переконайтесь, що "хтось" також виконує ручні тести через регулярні проміжки часу. Ізольоване середовище (зменшена копія продукту) полегшить тестування відновлення.

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

Спасибі, Патріку

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