Безпечна інтеграція в майбутнє


Безпечна інтеграція в майбутнє

Як мережа впливає на час відновлення сервісів і що варто перевірити заздалегідь

Майстер-клас: секрети випікання найсмачніших млинців!

26.10.2026

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

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

Тому на RTO впливає не лише система резервного копіювання, а й архітектура мережі та залежності між компонентами інфраструктури.

Розглянемо, де саме мережа може стати вузьким місцем (bottleneck) відновлення, чому номінальної пропускної здатності замало для оцінки RTO та що варто перевірити до збою або аварії. 

Щоб повернути сервіс до роботи, недостатньо відновити дані

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

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

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

Чому мережа залишається поза планом аварійного відновлення?

Прогалини в перевірці відновлення найчастіше виникають через такі причини:
● За резервне копіювання і мережу відповідають різні команди. План аварійного відновлення зазвичай детально описує порядок повернення серверів і баз даних до роботи, але не завжди охоплює необхідні сегменти, маршрути та правила міжмережевих екранів.
● Тестують окрему копію, а не весь сервіс. Відновлена віртуальна машина може успішно завантажитися в ізольованому середовищі, але при цьому не перевіряються її залежності.
● Мережу сприймають як ресурс, який залишиться доступним. Це часто справедливо для локальних збоїв, але не для втрати майданчика, масштабного інциденту або кібератаки.
● Швидкість резервного копіювання плутають зі швидкістю відновлення. На неї також впливають репозиторій, мережевий шлях, цільове сховище та кількість одночасних операцій.

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

Коли пропускна здатність мережі стає обмеженням для відновлення?

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

Наприклад, якщо потрібно відновити 10 ТБ даних через канал 1 Гбіт/с, то навіть за ідеальних умов лише передавання триватиме орієнтовно 22 години. Якщо фактична корисна швидкість становить приблизно 60% від номінальної, цей процес займе близько 37 годин.

За швидкості 10 Гбіт/с теоретичний час передавання скорочується приблизно до 2,2 години. Якщо фактична пропускна здатність становить 60% від номінальної, передавання триватиме близько 3,7 години. І це без урахування часу на запуск систем, перевірку цілісності даних і відновлення залежностей.

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

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

Від чого залежить реальна швидкість передавання даних?

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

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

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

Паралельне відновлення не завжди прискорює роботу

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

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

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

Відновлення сервісу не закінчується запуском серверів

Коли команда успішно запускає сервери та повертає дані, бізнес-сервіс може залишатися недоступним. Це пов’язано з тим, що корпоративні застосунки залежать не лише від власних серверів, а й від інших інфраструктурних компонентів.

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

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

Від чого залежить працездатність сервісу після відновлення?

Для кожного сервісу перелік необхідних компонентів відрізняється, але найчастіше до нього входять: 
● DNS — щоб системи могли знаходити одна одну за іменами; ● служби каталогу та автентифікації — для входу користувачів і взаємодії сервісних облікових записів; ● маршрутизація — щоб трафік міг проходити між потрібними сегментами; ● правила міжмережевих екранів — для дозволу необхідних з’єднань; ● бази даних та інші внутрішні сервіси — від яких залежить робота застосунку; ● зовнішні API й партнерські системи — якщо без них неможливо виконувати окремі бізнес-операції. 
Крім переліку компонентів важливо розуміти зв’язки між ними. Деякі з них залишаються неочевидними до моменту аварії. Наприклад, застосунок звертається до іншого сервісу за конкретною адресою або використовує ресурс, розміщений в основному дата-центрі. Такі зв’язки варто заздалегідь описувати та перевіряти в сценарії відновлення. 
З цієї причини порядок відновлення не може бути універсальним. До прикладу, якщо контролери домену працюють як віртуальні машини, для їхнього запуску спочатку потрібні доступні мережа, сховище та мінімально працездатна платформа віртуалізації. 

Мережеві залежності резервного майданчика

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

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

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

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

Компрометація мережі змінює сам сценарій відновлення

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

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

Для чого потрібне ізольоване середовище відновлення?

Для цього використовують clean room — окремий контур, у якому відновлені системи можна запускати й перевіряти без прямого доступу до продуктивної інфраструктури.

Його архітектуру варто визначити ще до інциденту: передбачити адресацію, маршрутизацію, DNS, мережеві політики, доступ до репозиторіїв та засобів перевірки безпеки. При цьому clean room не обов’язково має повністю копіювати продуктивне середовище — достатньо відтворити критичні залежності конкретного сценарію відновлення.

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

Адміністрування не має залежати від скомпрометованого домену

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

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

У цьому сценарії мережа виконує одразу 2 функції: передає дані для відновлення і створює контрольований контур, у якому системи можна безпечно перевірити та поетапно повернути до роботи. 

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

Наявність основного й резервного дата-центрів створює основу для аварійного відновлення, але не гарантує готовності інфраструктури до повної втрати одного з майданчиків. 
Уявімо компанію, яка регулярно передає резервні копії до другого дата-центру, синхронізує частину даних і має там необхідні обчислювальні ресурси. Тестове відновлення окремих віртуальних машин проходить успішно, тож на перший погляд резервний майданчик готовий до роботи. 
Проблема проявляється під час повного перемикання. Вихід до інтернету, міжмережеві екрани або VPN-з’єднання з партнерами залишаються прив’язаними до основного дата-центру. Сервери й дані на резервному майданчику доступні, але користувачі та зовнішні системи повноцінно з ними працювати не можуть. 
У такій ситуації команді доводиться вже під час інциденту змінювати маршрутизацію, оновлювати DNS-записи, відновлювати VPN-з’єднання та переналаштовувати політики доступу. Резервний дата-центр фактично працює як місце зберігання ресурсів, а не як автономне середовище для критичних сервісів. 
Спільні точки відмови між основним і резервним дата-центрами
Два майданчики можуть мати спільні компоненти або залежності, через які відмова основного дата-центру порушить роботу резервного, наприклад: 
● єдиний вихід до інтернету через основний дата-центр; ● одна система управління мережевою інфраструктурою; ● залежність від одного оператора або мережевого маршруту; ● VPN-з’єднання, прив’язані до адрес основного майданчика; ● спільні адміністративні облікові записи; ● схема маршрутизації, яка не передбачає автономну роботу резервного дата-центру. 
Такі компоненти та залежності утворюють єдині точки відмови: їхня втрата порушує роботу всієї системи, навіть якщо інші її частини продубльовані. 
Готовність резервного майданчика варто оцінювати за його здатністю самостійно підтримувати критичні бізнес-сервіси. Для цього під час тестування аварійного відновлення потрібно моделювати недоступність основного дата-центру та перевіряти не лише запуск серверів, а й маршрути, зовнішні з’єднання, DNS, VPN і доступ користувачів. 

Як перевірити, що архітектура справді готова до відновлення?

Тест однієї віртуальної машини підтверджує працездатність резервної копії, але не готовність усієї інфраструктури. Для повноцінного тестування варто перевірити:
● фактичний час передавання та відновлення даних; ● роботу кількох паралельних завдань і навантаження на інфраструктуру; ● доступність DNS, автентифікації, маршрутизації, VPN і правил міжмережевих екранів; ● зовнішні та партнерські інтеграції; ● доступ до засобів адміністрування, документації та резервних конфігурацій; ● можливість користувачів виконати реальну бізнес-операцію після відновлення.

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

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

Комплексний підхід до аварійного відновлення з IT Specialist

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

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

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

Illustration


Зателефонувати

Офіс+38 (044) 390 81 90

Департамент продажів+38 (096) 390 81 90

Написати

moc.tsilaicepsti-ym%40olleh

Приїхати на каву

Бізнес-центр Sigma,бульвар Вацлава Гавела, 6, корпус 3, Україна, Київ, 03124

Illustration


Зателефонувати

Офіс+38 (044) 390 81 90

Департамент продажів+38 (096) 390 81 90

Написати

moc.tsilaicepsti-ym%40olleh

Приїхати на каву

Бізнес-центр Sigma,бульвар Вацлава Гавела, 6, корпус 3, Україна, Київ, 03124