Втрата даних для бізнесу може статися раптово, і, на жаль, таке трапляється регулярно, коли, наприклад, накопичувач виходить з ладу, співробітник помилково видаляє потрібні файли або база даних пошкоджується після збою чи невдалого оновлення.
Наслідки безпосередньо залежать від того, які саме дані було втрачено. Це можуть бути замовлення клієнтів, документи, вміст бази даних або результати роботи співробітників. Та все, що завгодно — якщо це впливало на роботу компанії, значить, це було важливим.
Резервне копіювання дозволяє заздалегідь підготуватися до таких ситуацій і відновити робочий стан системи після збою. Але для цього недостатньо просто періодично створювати архіви, складаючи туди «все, що є». Необхідно чітко розуміти, що копіювати, де зберігати копії та як швидко їх можна відновити.
Надійний сервер не гарантує збереження даних
Здавалося б, що заголовок досить суперечливий. Як це надійний сервер нічого не гарантує? Але справа в тому, що надійність обладнання та резервне копіювання вирішують дві абсолютно різні задачі. Ваш сервер може роками працювати без збоїв, мати якісні накопичувачі та резервування окремих компонентів, але це не створює історії даних.
Трохи зрозуміліше має бути на прикладі RAID-масиву. Так, він дозволяє системі продовжувати роботу в разі виходу з ладу одного з дисків. Але при цьому дані на накопичувачах синхронізуються, тому повернутися за його допомогою до стану, скажімо, тижневої давності, на жаль, неможливо.
А ось у резервної копії інше завдання. Вона зберігає стан інформації на певний момент часу і дозволяє згодом до нього повернутися. Для невеликого проєкту простою відправною точкою може стати, наприклад, VPS із безкоштовним щоденним бекапом, якщо однієї точки відновлення на добу достатньо для його завдань.
Тому надійне обладнання знижує ймовірність деяких аварій, а резервування даних зменшує їхні можливі наслідки. Одне не замінює іншого.
Що саме потрібно зберігати
Копіювати весь вміст інфраструктури з однаковою частотою зазвичай не має сенсу. Наприклад, частину інформації легко можна отримати заново, інша існує лише всередині компанії, а третя взагалі є сміттям, яке давно слід було видалити.
Умовний дистрибутив операційної системи можна знову завантажити та встановити. Набагато складніше, у разі збою, буде відновити базу замовлень інтернет-магазину, документи співробітників або файли, завантажені клієнтами.
Тому перед налаштуванням резервування корисно розділити дані за їхньою цінністю для бізнесу.
| Категорія | Приклади | Пріоритет резервування |
|---|---|---|
| Критичні дані | Бази замовлень, фінансові дані, робочі документи | Дуже високий |
| Дані користувачів | Завантажені файли, проєкти, матеріали клієнтів | Високий |
| Конфігурація | Налаштування додатків і сервісів | Середній |
| Дані, що підлягають відновленню | Системні пакети, тимчасові файли, кеш | Низький |
Такий підхід допомагає раціональніше використовувати сховище, адже кілька гігабайтів бази, що постійно змінюється, можуть бути ціннішими за сотні гігабайтів файлів, які легко отримати повторно.
Як часто створювати резервні копії
Частота залежить від того, скільки нових даних бізнес готовий втратити.
Уявімо інтернет-магазин, який отримує замовлення протягом усього дня. Якщо резервну копію створюють лише вночі, то відновлення після серйозного збою може повернути базу до стану попереднього вечора. Усі зміни після цього моменту доведеться відновлювати іншим способом, якщо це взагалі можливо.
І навпаки, для корпоративного сайту, що рідко оновлюється, добовий інтервал може бути цілком прийнятним.
Цю межу описує показник RPO — Recovery Point Objective. Він показує, за який максимальний період компанія допускає втрату останніх змін.
Якщо допустимий RPO становить чотири години, то резервні копії повинні створюватися щонайменше з відповідною частотою. Для систем, де дані змінюються постійно, інтервал може вимірюватися вже хвилинами.
Тут проявляється пряма залежність: чим дорожчою для бізнесу є втрата свіжих даних, тим частіше потрібно створювати точки відновлення.
Де зберігати резервні копії
Копія, розташована поруч із робочими даними, захищає лише від частини проблем, якщо взагалі захищає. Ну уявіть собі, що на вашому сервері резервна копія зберігається на тому самому диску, на якому й основні дані. Що станеться у разі виходу з ладу диска? — Правильно, дані та їхня резервна копія зникнуть разом. Тому місце зберігання варто продумувати окремо.
Резервні копії можна надсилати на інший сервер або до спеціалізованого віддаленого сховища. Для невеликої системи достатньо буде однієї додаткової платформи, а для більш критичної інфраструктури використовують одразу кілька рівнів зберігання.
Давно з цієї логіки викристалізувалося правило 3-2-1. Воно передбачає наявність трьох копій даних на двох типах носіїв, причому одна копія зберігається окремо від основної інфраструктури.
Звісно, дотримуватися цієї формули буквально потрібно не завжди, а варто лише дотримуватися того принципу, що резервна копія має залишатися доступною після серйозного збою основної системи.
Навіщо зберігати кілька версій
Остання резервна копія далеко не завжди виявляється тією, яка потрібна для відновлення.
Деякі проблеми у вашій системі виявляються через кілька днів, а то й тижнів, і за цей час система встигає створити нові копії, в яких вже міститься небажаний стан даних. І якщо попередні версії резервних копій автоматично видаляються, то відповідної точки відновлення може просто не залишитися.
Тому резервне сховище обов’язково має містити хоча б мінімальну історію.
Наприклад, свіжі копії можна зберігати щодня протягом тижня, а старіші — залишати з більшим інтервалом ще на кілька тижнів або місяців. Конкретна схема завжди залежить від обсягу даних і доступного місця.
Резервну копію потрібно перевіряти
Звучить суперечливо, але сам факт появи нового файлу в резервному сховищі ще не означає, що систему вдасться відновити.
Тому роботу резервування потрібно контролювати. Зазвичай перевіряють успішність створення копій, їхній розмір, доступність сховища та відповідність встановленому графіку.
Але головна перевірка — це пробне відновлення.
Копію періодично розгортають окремо і перевіряють, чи можна отримати з неї робочі дані. Для критичних систем такі тести проводять регулярно, а для невеликих проєктів — рідше.
Це дозволяє виявити проблему заздалегідь, оскільки під час реальної аварії з’ясовувати, чи придатні накопичені за останній рік копії, буде вже запізно.
Скільки часу займає відновлення
Оскільки частота копіювання відповідає лише на питання про можливу втрату останніх змін, то у бізнесу є ще одна величина — допустимий час простою.
Для неї використовують показник RTO — Recovery Time Objective.
Припустимо, компанія створює резервну копію щогодини, і з точки зору збереження актуальних даних така схема виглядає дуже добре. Але якщо повне відновлення системи займає добу, то бізнес весь цей час залишається без робочого сервісу.
Тому RTO також потрібно оцінювати заздалегідь, адже для невеликого сайту кілька годин відновлення можуть бути цілком прийнятними, а ось система, від якої залежить робота всієї компанії, вимагатиме іншого підходу: заздалегідь підготовленої інфраструктури та чіткої процедури повернення сервісу до роботи.
RPO та RTO пов’язані між собою, але відповідають на різні питання. Перший визначає допустиму втрату останніх даних, другий — тривалість відновлення.
Резервування має працювати автоматично
Якщо створення копій залежить від того, чи згадав співробітник виконати необхідну процедуру, то рано чи пізно графік буде порушено, що може драматично позначитися на роботі компанії.
Тому резервування зазвичай автоматизують. Система має самостійно створювати копії із заданою періодичністю, стежити за термінами зберігання старих версій і повідомляти про можливі проблеми.
Контроль при цьому, звісно, залишається за людиною, оскільки потрібно стежити за станом сховища, перевіряти виконання завдань і періодично проводити тестове відновлення.
Для бізнесу це зручніше ще й з організаційної точки зору, адже цей важливий процес перестає залежати від конкретного співробітника і продовжує працювати під час відпустки, вихідних або зміни адміністратора.
Підбиваючи підсумки, можна сказати, що резервне копіювання має сенс лише тоді, коли компанія заздалегідь знає, як скористається збереженими даними.
Кількість архівів сама по собі нічого не гарантує. Набагато корисніше розуміти, наскільки свіжою буде доступна копія, де вона зберігається і скільки часу знадобиться на відновлення.
Добре налагоджене резервне копіювання рідко нагадує про себе. Воно працює за розкладом, періодично перевіряється і чекає моменту, коли дійсно знадобиться.
Саме тому бекап варто сприймати як процес, як частину звичайної ІТ-інфраструктури бізнесу, а не як разовий захід на випадок гіпотетичної катастрофи.
