Backup і Disaster Recovery для компаній

Як запланувати backup, RPO/RTO, ретенцію, копії 3-2-1, тест відновлення, моніторинг і план Disaster Recovery для бізнесових послуг.

Практичний гід DataHouse.pl

Backup і Disaster Recovery для компаній

Backup - це не лише копія файлів. У компанії потрібно описати RPO, RTO, ретенцію, відповідальність за відновлення, тести відновлення, моніторинг і план Disaster Recovery для послуг WWW, пошти, баз даних, VPN і систем клієнтів.

RPO і RTO

RPO визначає, скільки даних компанія може втратити, а RTO - скільки часу може тривати відновлення послуги. Без цих двох значень backup є випадковою копією, а не частиною плану безперервності.

Модель копій 3-2-1

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

Тест відновлення

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

Disaster Recovery

План DR описує, що робимо після аварії: хто приймає рішення, де відновлюємо послугу, як перемикаємо DNS або routing, як комунікуємо стан і коли повертаємося до нормальної роботи.

Моделі backup і відновлення

Backup файлів

Документи, вкладення, конфігурації

Добра стартова точка, але без backup баз даних і конфігурації послуг цього не вистачить для повного відновлення системи.

Backup баз даних

ERP, CRM, магазини, пошта

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

Backup машин / VPS

Сервери застосунків і тестові середовища

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

Копія поза основним середовищем

Аварія обладнання, помилка оператора, ransomware

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

Disaster Recovery

Критичні послуги і високий SLA

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

Цілі відновлення

Матриця вибору RPO/RTO

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

Архіви та звітність

Приклади: Документи, експорти, історичні звіти

RPO: Від кількох годин до однієї доби

RTO: Від кількох годин до наступного робочого дня

Типовий проєкт: Планова off-site копія з ретенцією та задокументованим відновленням файлів

Стандартні бізнес-системи

Приклади: Файли, collaboration, внутрішні застосунки

RPO: Приклад цілі: 1-4 години

RTO: Приклад цілі: 4-8 годин

Типовий проєкт: Частий backup, окремий repository, off-site копія та періодичний тест відновлення

Транзакційні системи

Приклади: ERP, CRM, e-commerce, бази даних і пошта

RPO: Приклад цілі: 15-60 хвилин

RTO: Приклад цілі: 1-4 години

Типовий проєкт: Узгоджені із застосунком копії, окремі облікові дані та перевірена черговість запуску баз і застосунків

Критичні послуги

Приклади: Системи, відмова яких негайно зупиняє ключові операції

RPO: Хвилини або near-zero після перевірки вимог

RTO: Від хвилин до однієї години після перевірки вимог

Типовий проєкт: Реплікація або дуже часті копії, ресурси в другому майданчику, автоматичний моніторинг, runbook і регулярні навчання

П'ять шарів захисту та доменів відмови

1. Продукція

Основні системи та дані. Цей шар не є backup і визначає першу домену відмови.

2. Швидке локальне відновлення

Snapshot або близька копія скорочують типове відновлення, але можуть ділити з продукцією ризик живлення, storage чи адміністрування.

3. Окремий repository

Виділена ємність із власною ретенцією, моніторингом і контрольованим доступом до відновлення.

4. Off-site та immutable шар

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

5. Середовище відновлення

Холодні, теплі або активні ресурси в другій домені відмови добираються до перевіреного RTO і карти залежностей.

Runbook Disaster Recovery: від інциденту до повернення

1. Виявити та оголосити

Підтвердити вплив, відповідального за інцидент, канал комунікації та рішення про запуск відновлення.

2. Ізолювати причину

Обмежити скомпрометовані облікові записи, ransomware, відмову storage або мережі до підключення захищених копій.

3. Відновити інфраструктуру

Підготувати compute, storage, мережу, firewall, identity, DNS і залежності сертифікатів.

4. Відновити дані та застосунки

Відновлювати за порядком залежностей і записати часову точку відновленого набору даних.

5. Перемкнути та перевірити

Перемикати трафік лише після технічних тестів і бізнес-приймання критичних транзакцій.

6. Комунікувати та моніторити

Відстежувати стан послуг, черги, інтеграції, продуктивність і звернення користувачів протягом процесу.

7. Повернутися та вдосконалити план

Затвердити повернення на основну платформу, зберегти докази й оновити runbook за результатами.

Матриця відповідальності

Бізнес-пріоритети та прийнятна втрата

Відповідальний: Бізнес-власник клієнта

Необхідний результат: Затверджені класи послуг, RPO/RTO і порядок відновлення

Узгодженість застосунків і залежності

Відповідальний: Власник застосунку клієнта разом із DataHouse

Необхідний результат: Метод backup, quiescing, облікові дані та черговість запуску застосунків

Repository, ретенція та моніторинг

Відповідальний: DataHouse в узгодженому обсязі послуги

Необхідний результат: Ємність, завдання копій, алерти, розділення доступу та політика ретенції

Виконання відновлення

Відповідальний: Визначені технічні команди в runbook

Необхідний результат: Кроки відновлення, контакти ескалації, доступ і журнал доказів

Приймання та failback

Відповідальний: Бізнес-власник клієнта разом із DataHouse

Необхідний результат: Результат приймання, відкриті помилки, рішення щодо трафіку та план повернення

Докази з тесту відновлення

  • дата тесту, перевірене навантаження та відповідальні особи;
  • обрана точка відновлення та фактична часова точка відновлених даних;
  • час початку та завершення відновлення інфраструктури, даних і застосунків;
  • технічні перевірки баз, файлів, пошти, DNS, сертифікатів, інтеграцій і доступу користувачів;
  • бізнес-приймання, відхилення від цілі та відкриті ризики;
  • коригувальні дії, відповідальний і строк до наступного навчання.
Сплануйте Backup і DR з DataHouse

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

Запросити план Backup і DR

Технічний власник: команда DataHouse / eTop. Перевірено: 28 липня 2026. Приклади діапазонів RPO/RTO мають освітній характер; точна ємність, ретенція, цілі відновлення, тести, відповідальність, ціни та SLA підтверджуються в пропозиції й договорі.

Чек-лист плану Backup/DR

  1. Описати критичні послуги: WWW, пошту, бази даних, файли, DNS, VPN, інтеграції, технічні облікові записи і сертифікати.
  2. Визначити RPO, RTO, ретенцію, шифрування, місце зберігання копій і відповідальність за тест відновлення.
  3. Відділити швидкий backup від архівного та копію поза основним адміністративним середовищем.
  4. Протестувати відновлення в окремому середовищі і перевірити застосунки, DNS, SSL, пошту та доступ користувачів.
  5. Описати план Disaster Recovery: порядок послуг, комунікацію, перемикання трафіку, моніторинг і повернення після аварії.

Найчастіші питання

Чим backup відрізняється від Disaster Recovery?

Backup - це копія даних, а Disaster Recovery - план відновлення послуги після аварії: де запустити систему, як перемкнути трафік, хто приймає рішення і як перевірити, що послуга працює.

Що означають RPO і RTO?

RPO визначає максимально прийнятну втрату даних, а RTO - максимальний час відновлення послуги. Ці значення визначають частоту копій і архітектуру відновлення.

Як часто тестувати відновлення backup?

Для критичних послуг тест відновлення треба виконувати циклічно та після більших змін застосунку, бази даних, системи, DNS або адміністративних процедур.

Чи backup має бути поза основним середовищем?

Так. Одна копія має бути відділена від основної платформи і адміністративних облікових записів, щоб аварія, помилка або ransomware не знищили всі копії.

Чи DataHouse.pl може допомогти з планом Backup/DR?

Так. План можна поєднати з backup і storage, Cloud Pro, VPS, виділеними серверами, колокацією, адмініструванням, моніторингом і тестами інструментами.

Чи однакові RPO і RTO підходять для всіх систем?

Зазвичай ні. Бази даних, ERP, пошта, файли та архіви мають різну допустиму втрату даних, залежності й черговість відновлення, тому їх треба класифікувати окремо.