DRaaS простими словами: як працює аварійне відновлення інфраструктури

DRaaS – це аварійне відновлення як послуга, за якого компанія використовує заздалегідь підготовлену резервну інфраструктуру та погоджений сценарій відновлення після серйозного збою. Замість самостійного створення другого майданчика бізнес може залучити провайдера та побудувати рішення на базі колокації, хмарних ресурсів або їх комбінації. Розбираємо, як працює DRaaS, чим він відрізняється від резервного копіювання, що означають RTO і RPO та від яких факторів залежить вартість аварійного відновлення.

Що таке DRaaS

Аварійне відновлення як послуга, або Disaster Recovery as a Service, – це модель, у межах якої для критичних ІТ-систем заздалегідь створюють резервну інфраструктуру та визначають порядок відновлення роботи у випадку серйозного інциденту. Залежно від архітектури це може бути окремий фізичний майданчик, ресурси у публічній або приватній хмарі, виділені сервери чи комбінація декількох підходів.

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

При цьому DRaaS не слід сприймати як одну стандартну технологію з однаковими параметрами у всіх провайдерів. Конкретний склад рішення, резервні ресурси, спосіб реплікації, рівень автоматизації, цільові RTO і RPO та відповідальність сторін мають визначатися технічною специфікацією і договором.

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

Поруч із DRaaS існує BaaS – резервне копіювання як послуга. Назви схожі, але задачі різні: backup передусім створює точки, з яких можна повернути дані, тоді як disaster recovery визначає, як відновити роботу критичних сервісів після відмови основного середовища.

Чим DRaaS відрізняється від бекапу

Бекап і аварійне відновлення вирішують пов’язані, але різні задачі. Резервна копія дозволяє відновити файли, базу даних, віртуальну машину або інший об’єкт до доступної точки відновлення. Disaster recovery охоплює ширший сценарій: де будуть працювати системи після аварії, у якому порядку вони запускаються, як відновлюються мережеві зв’язки, доступи та інтеграції і як користувачі потраплять до резервного середовища.

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

Критерій	Резервне копіювання	DRaaS
Основна задача	Створити точки для відновлення даних або систем	Підготувати відновлення роботи критичних сервісів після аварії
Об’єкт захисту	Файли, бази, застосунки, віртуальні машини та інші дані	Системи разом із необхідними ресурсами, мережею та процедурою перемикання
Час відновлення	Залежить від обсягу даних, платформи та доступних ресурсів для відновлення	Проєктується відповідно до цільового RTO конкретної системи
Резервні ресурси	Для зберігання копій потрібне резервне сховище	Передбачаються ресурси, необхідні для роботи захищених систем після failover
Захист від логічної помилки або видалення	Можливий за наявності придатної точки відновлення	Сам по собі не замінює незалежні точки відновлення

Тому одне рішення не замінює інше. Бекап потрібен для повернення до попереднього стану після випадкового видалення, пошкодження даних, некоректної зміни або інших інцидентів. Детальніше про принципи резервного копіювання ми писали в матеріалі «Що таке бекап».

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

RTO і RPO

RTO і RPO – дві основні метрики, через які бізнес формулює вимоги до аварійного відновлення.

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

RPO, Recovery Point Objective, – максимально прийнятний обсяг втрати даних, виражений через час. RPO у п’ятнадцять хвилин означає, що бізнес допускає втрату змін, які з’явилися протягом останніх п’ятнадцяти хвилин до інциденту. Чи можна фактично досягти такого показника, залежить від технології реплікації або резервного копіювання та конкретної архітектури.

Для RTO і RPO немає універсальних правильних значень для інтернет-магазину, ERP, корпоративної пошти чи іншої системи. Одна й та сама платформа може бути критичною для однієї компанії та другорядною для іншої. Тому показники визначають через бізнес-вплив простою і втрати даних.

Щоб не застосовувати однакові вимоги до всієї інфраструктури, системи доцільно попередньо розділити за критичністю:

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

Для кожної групи та, за потреби, кожного workload задають окремі RTO і RPO. При цьому потрібно враховувати залежності між системами. Якщо застосунок, база даних та інтегрований із ними сервіс відновляться до несумісних моментів часу, технічно запущені компоненти можуть не утворити працездатну систему.

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

Скільки коштує простій

Без оцінки наслідків простою складно обґрунтовано визначити RTO. Формулювання «потрібно відновитися якомога швидше» не дає технічній команді межі, заради якої доцільно збільшувати резервні ресурси, пропускну здатність каналів або рівень автоматизації.

Почати можна з прямих фінансових наслідків: втрачених продажів або операцій, простою працівників, витрат на позапланове відновлення, роботу інженерів і зовнішніх підрядників. Для компаній із договірними зобов’язаннями потрібно також врахувати можливі штрафи, компенсації та порушення власних SLA перед клієнтами.

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

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

Чужа статистика про «середню вартість години простою» також не замінює власного розрахунку. Вплив відмови залежить від бізнес-моделі, сезону, залежності операцій від конкретної системи та договірних зобов’язань компанії.

Як працює DRaaS

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

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

Реплікація даних

Реплікація – це передавання даних або змін між основним і резервним середовищами. Залежно від платформи вона може працювати на рівні storage, віртуальних машин, баз даних або застосунків, а також використовувати синхронний чи асинхронний механізм.

Спосіб реплікації безпосередньо впливає на потенційний RPO, але сам факт «безперервної реплікації» не є гарантією конкретної кількості хвилин втрати даних. Важливі технологічні обмеження платформи, швидкість зміни даних, продуктивність storage, затримка та пропускна здатність каналу, а також вимоги до application consistency.

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

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

Failover і failback

Failover – це переведення роботи на резервне середовище. Він може запускатися вручну після рішення відповідальних осіб або автоматично за заздалегідь визначеними критеріями. Рівень автоматизації потрібно погоджувати під конкретну систему, оскільки помилкове перемикання також може створити збій.

Failover часто включає більше, ніж запуск резервних серверів. Залежно від архітектури потрібно забезпечити маршрутизацію трафіку, балансування, DNS, VPN, firewall, доступ користувачів, зовнішні інтеграції та правильний порядок запуску залежних сервісів. Саме ці компоненти потрібно включати до recovery plan і тестування.

Failback – повернення роботи на основне середовище після усунення причини аварії. Після failover нові дані вже можуть створюватися на резервній стороні, тому перед поверненням потрібно визначити спосіб їх синхронізації, послідовність перемикання та перевірку цілісності.

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

Варіанти реалізації DRaaS

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

Колокація

Колокація може використовуватися як основа резервного майданчика для компаній, які хочуть розміщувати власне фізичне обладнання у дата-центрі. Для DR-сценарію така конфігурація може додатково передбачати канали зв’язку між основною та резервною інфраструктурою.

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

Хмарне рішення

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

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

Гібридне рішення

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

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

Що перевірити у провайдера

Пропозиції DRaaS потрібно порівнювати не лише за назвою сервісу або вартістю. Основні параметри повинні бути описані в технічній специфікації, SLA або інших договірних документах.

RTO і RPO. Чи є вони цільовими або гарантованими, для яких саме систем діють, як вимірюються і які події виключені з розрахунку.
Архітектура резервного середовища. Де фізично або логічно знаходяться резервні ресурси, який рівень ізоляції використовується і яка юрисдикція застосовується до даних.
Реплікація. Яка технологія використовується, як контролюється її стан і що відбувається при перевищенні допустимого lag.
Failover. Хто оголошує аварію, хто запускає перемикання, які компоненти процесу автоматизовані і які дії залишаються на стороні клієнта.
Резервні ресурси. Чи відповідає їхня продуктивність основному середовищу або під час аварії передбачена робота в скороченій конфігурації.
Тестування. Який формат перевірок передбачений, як часто вони виконуються, що саме тестується та чи включена їхня вартість у сервіс.
Failback. Як відбувається повернення на основний майданчик, як синхронізуються дані і чи потребує цей етап окремих робіт або оплати.
Сумісність. Чи підтримуються поточна платформа віртуалізації, операційні системи, мережеві компоненти, застосунки та ліцензійна модель клієнта.
Розподіл відповідальності. За які компоненти відповідає провайдер, а які залишаються на стороні внутрішньої ІТ-команди.

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

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

Тестування плану відновлення

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

Перевірка може мати різну глибину. На базовому рівні команда проходить recovery plan і перевіряє ролі, контакти, критерії оголошення аварії та порядок дій. Глибший тест може включати запуск копій систем в ізольованому середовищі, перевірку застосунків і залежностей. Для критичних workload за потреби проводять контрольований failover відповідно до погодженого сценарію.

Універсального правила на кшталт «тестувати раз на півроку» немає. Періодичність визначають критичністю систем, внутрішніми політиками, нормативними вимогами, договором і швидкістю змін інфраструктури. Після суттєвої зміни мережі, застосунків, storage, платформи віртуалізації або залежностей recovery plan потрібно переглянути незалежно від календарного графіка.

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

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

Обмеження DRaaS

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

Помилки можуть реплікуватися. Некоректні зміни, пошкодження або наслідки шифрування можуть потрапити на резервну сторону, якщо архітектура не передбачає окремих точок відновлення.
RPO залежить від технології та мережі. Пропускна здатність, latency, change rate і можливості платформи впливають на фактичне відставання резервного середовища.
Малий RTO потребує відповідної архітектури. Чим швидше система має повернутися до роботи, тим вищими можуть бути вимоги до резервних ресурсів, автоматизації та мережі.
Резервна конфігурація може відрізнятися від основної. Якщо для DR передбачено менше ресурсів, після перемикання потрібно заздалегідь розуміти допустимий рівень продуктивності.
Recovery plan застаріває. Нові сервіси, інтеграції, IP-адреси, правила доступу та зміни архітектури потрібно своєчасно додавати до сценарію.
Організаційні процедури залишаються важливими. Навіть технічно готове резервне середовище потребує зрозумілих критеріїв оголошення аварії, відповідальних осіб і процедури ескалації.

Саме тому DRaaS доцільно використовувати разом із незалежним резервним копіюванням. Для бізнесу також доступний окремий сервіс BaaS, призначений саме для організації резервних копій. Backup і disaster recovery виконують різні функції та доповнюють одне одного.

Висновок

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

Планування починається з бізнес-вимог: потрібно визначити, скільки часу кожна система може залишатися недоступною і який обсяг втрати останніх даних є прийнятним. Ці вимоги формалізуються через RTO та RPO, після чого під них підбирають технологію реплікації, резервні ресурси, мережу та порядок failover і failback.

Захищати всю інфраструктуру однаково не завжди економічно виправдано. Критичні системи можуть отримати коротший RTO та менший RPO, тоді як для другорядних workload може бути достатньо резервного копіювання і довшого часу відновлення.

Готовність до аварії підтверджує не сама наявність DRaaS у договорі, а регулярно перевірений recovery plan, у якому зрозумілі залежності систем, ролі сторін, процедура перемикання і фактичні результати тестів.