Практичні рекомендації щодо політики резервного копіювання
Приклад:
- Повна резервна копія створюється щоп'ятниці, в інші дні створюються інкрементальні копії
- У середу було здійснено оновлення сервера бази даних до нової версії, яке супроводжувалося оновленням деяких загальних системних файлів, що належать до операційної системи
- У ніч на четвер було, як завжди, отримано інкрементальну резервну копію
- У четвер вранці стався критичний збій, який вимагав відновлення системи
- Вивчивши характер збою, адміністратор розуміє, що пошкоджені лише системні файли і відновлення функціонування системи досить було б відновити лише безліч системних фалів (system state), використовуючи останню повну резервну копію. Однак, якщо зробити тільки це, то оновлена версія сервера бази даних перестане працювати, оскільки їй потрібні новіші версії системних файлів (наприклад, остання версія .NET Framework), які були встановлені разом з ним. Це призводить до необхідності продовжувати відновлення, переглядаючи необхідні інкрементальні копії, які містять зміни в system state. Це веде, зрештою, до збільшення трудомісткості процесу відновлення та збільшення часу RTO, аж до порушення SLA.
По суті це різновид попереднього пункту. Відновлення системи після збою - трудомісткий процес, який часто потребує значного часу (за рахунок необхідності застосування інкрементальних резервних копій, різних патчів, що не увійшли до резервних копій тощо). У ряді випадків користувачі відразуприступають до роботи в системі, як тільки її базова функціональність відновлена, і тим самим починають змінювати її стан. Крім того, не можна виключати повторний збій через короткий проміжок часу після першого. Тому розумно відразу після відновлення зафіксувати у повній резервній копії новий актуальний стан системи.
«Не женіться за двома зайцями» або «Модернізація – зло»
Не варто поєднувати процес відновлення системи після збоїв та процес її модернізації. Незважаючи на те, що це може здатися очевидним, дефіцит часу на технологічні процедури під час безперервного виробничого функціонування системи, а також небажання вносити (навіть необхідні) зміни в те, що і так нормально працює, може викликати бажання використати момент вимушеного простою системи. під час збою для того, щоб виконати модернізацію, так би мовити, «за одне».
Розглянемо кілька прикладів, що з цього може вийти:
- Система вдало відновлена після збою, але адміністратор приймає рішення відразу встановити останні оновлення на систему, щоб потім не переривати роботу користувачів для цих цілей. Однак один із патчів некоректно встановлюється, і система руйнується. Внаслідок цього систему знову доводиться відновлювати з нуля.
- Відбувся критичний збій сервера версії X.1. Система була порушена збоєм. Адміністратор вирішив у процесі відновлення встановити нову версію X.2 з інсталяційного диска та відновити з резервної копії дані програми та додаткові програмні модулі, що реалізують специфічну бізнес-логіку. Однак після відновлення даних та модулів з'ясувалося, що вони не сумісні з новою версією X.2 через невеликі зміни в логіці роботи деяких програмнихфункцій та специфікаціях деяких програмних інтерфейсів. В результаті сервер додатків довелося відновлювати сервер додатків версії X.1.
- Відбувся критичний збій операційної системи версії X. Користувач не знайшов інсталяційний диск версії X (оскільки цю версію було встановлено 3 роки тому) і встановив версію X+1. У адміністратора виникла проблема з урахуванням ліцензій, крім того, один додаток, що використовується для роботи, виявився не сумісним з новою версією операційної системи. Систему довелося встановлювати заново.
Про все потроху
У процедурі резервного копіювання та відновлення додатків можуть бути різні нюанси, які необхідно врахувати та які не завжди очевидні. Ці нюанси зазвичай можна дізнатися тільки з документації програми, проте, як це часто буває, документація не прочитується вчасно (або не прочитується зовсім).
Приклад «нюансів» такого роду:
- У процесі резервного копіювання не зберігаються різні паролі та інформація про ліцензію. А це означає, що при відновленні не вдасться отримати працездатну програму або операційну систему, а план відновлення після збоїв у частині декларованого RTO виявиться зірваним.
- Системна конфігураціядодатки повинні зберігатися за спеціальною процедурою, окремою від процедури бекапу самих даних
- Процедура бекапу відкритих на запис файлів спеціальним чином обумовлена в документації (потрібно заздалегідь включити певні налаштування в конфігурації програми).
Процес відновлення повинен проводитися адміністраторами
Тестування відновлення має проводитись регулярно
Враховуйте залежність від інфраструктурних компонентів мережі
Припустимо, що збій стався на сервері DNS. Після запуску процедури відновлення виявилося, що продукт резервного копіювання використовує DNS в рамках роботи з власною інфраструктурою (наприклад, з'єднується з репозиторієм резервних копій, використовуючи ім'я сервера FQDN). У результаті виходить «циркулярна залежність», яка дозволяє автоматично виконати відновлення після збою. Аналогічна ситуація може спостерігатися з контролером домену (але тут рятує те, що контролерів домену зазвичай у компанії кілька).
Таких циркулярних залежностей слід намагатися уникати. Виявляти їх дозволяє тестування відновлення резервних копій в ізольовану від продуктивної мережі пісочницю, наприклад, за допомогою технології Veeam SureBackup.
Документування процедур стадії відновлення
Обережно документуйте процедуру відновлення після збоїв
Що тестувати під час перевірки процедури відновлення після збоїв?
Для того, щоб інструкції, які застосовуються у процесі відновлення після збоїв, були максимально коректними, потрібно проводити «навчальні відновлення». У процесі проведення тестування процесу відновлення слід звернути увагу принаймні такі питання як:
- В разіповного руйнування сайту, чи резервні копії будуть містити всю інформацію, необхідну для його відновлення?
- Як буде проходити процес відновлення, якщо головний системний адміністратор буде недоступний (скажімо, перебуватиме у закордонній відпустці)?
- Що станеться, якщо виявиться пошкодженим носій інформації (стрічка/диск), на якому розміщена резервна копія, яка найбільше підходить для використання в процесі відновлення?
- Що буде у разі т.зв. "вторинного збою"? Тобто, якщо після успішного завершення процесу відновлення, виявиться, що відновлена система не працює?
- Чи укладається час, витрачений на процес відновлення, в обумовлений SLA? Чи знають залучені до процесу люди про існування SLA та його параметри, і чи беруть його до уваги у своїй роботі?
- Як позначиться процес відновлення відмова інфраструктурних компонентів продуктивної мережі (поштовий сервер, сервер миттєвих повідомлень, DNS, контролер домену і т.д.)
- Якість документації: чи зможе нетренований адміністратор відновити продуктивну систему, дотримуючись письмових інструкцій?
- Швидкість реакції компанії, якщо причиною руйнування інформації став вірус (будь-якого типу). Специфічність цієї загрози в тому, що вірус може спотворити дані та додатки, не порушивши при цьому їх доступність, - внаслідок чого системи забезпечення відмовостійкості не зафіксують збій, крім того, налаштовані механізми реплікації змін даних автоматично рознесуть ці спотворення щодо інших реплікаційних партнерів (або вузлів кластера/геокластера).
- Чи залежить процес відновлення від специфічної апаратури (яка може вийти з ладу на момент відновлення)?
- Чи можна провести процес відновленняповністю віддалено?
- Що буде, якщо буде порушено роботу каналу, що пов'язує бекап-сайти компанії?
Загальний висновок
Планування та тестування резервного копіювання та відновлення є найважливішим фактором, що дозволяє мінімізувати RTO та виконати умови SLA. Наявність у продукті резервного копіювання функціоналу щодо автоматизації тестування відновлення з резервних копій є вкрай важливою.