Наприкінці вересня 2026 року українська ІТ-інфраструктура зіткнулася з новою реальністю: дата-центри, хостингові майданчики та великі телекомунікаційні вузли опинилися серед об’єктів російських атак.
Протягом лише кількох днів інформація про атаки стосувалася цілої низки українських дата-центрів, операторів зв’язку та інтернет-провайдерів.
Це ще раз показує: в умовах війни фізичне розташування серверів та резервних копій має не менше значення, ніж RAID, кластеризація, резервне живлення чи захист мережі.
Дата-центри та оператори, яких торкнулися атаки
| Дата | Дата-центр / оператор | Інформація |
|---|---|---|
| ~18.09.2026 | De Novo | Повідомлялося про атаку на київський дата-центр |
| 23.09.2026 | UTELS | Атака на майданчик, де розміщувалася інфраструктура оператора |
| 23.09.2026 | «Павутина» | Атака на інфраструктуру провайдера |
| 23–24.09.2026 | MiroHost | Атака на дата-центр, де розміщувалася інфраструктура компанії |
| 23–24.09.2026 | Cityhost | Атака на інфраструктуру, пов’язану з роботою провайдера |
| 23–24.09.2026 | Etherlink | Атака на телекомунікаційну інфраструктуру |
| 23–24.09.2026 | Crazy Network | Атака на телекомунікаційну інфраструктуру оператора |
| 23–24.09.2026 | KIEVNET | Атака на інфраструктуру оператора |
| 23–24.09.2026 | Domonet | Атака на інфраструктуру оператора |
| 23–24.09.2026 | FAUST | Атака на інфраструктуру оператора |
| 23–24.09.2026 | КВЦ «Парковий» | Атака на дата-центр |
| 25.09.2026 | Datagroup / DVL | Атака на київський дата-центр |
| 25.09.2026 | DC|COSMONOVA | Атака на дата-центр |
| 26.09.2026 | DC|COSMONOVA | Повторна атака на майданчик |
| 26.09.2026 | «Коло.ТБ» | Атака на інфраструктуру |
| 27.09.2026 | Дата-центр у Києві | Повідомлялося про дві атаки на дата-центр |
| 27.09.2026 | Vodafone Ukraine | Повідомлялося про атаку на дата-центр оператора |
| 27.09.2026 | Kyivstar | Атака на об’єкт компанії в Києві |
Масштаб проблеми добре ілюструє те, що після атак 23 вересня проблеми з інтернетом виникли приблизно у 100 тисяч домогосподарств Києва та області.
І це вже не тільки питання роботи конкретного дата-центру.
Через цифрову інфраструктуру сьогодні працюють банки, магазини, ERP-системи, бухгалтерія, державні сервіси, логістика, виробництво, медицина, системи оповіщення та зв’язку.
Економічні збитки можуть значно перевищувати вартість обладнання
Вартість серверів, мережевого обладнання та самого дата-центру — лише найбільш очевидна частина збитків.
Набагато більшими можуть бути непрямі втрати:
- простій підприємств;
- неможливість оформлювати та відвантажувати замовлення;
- зупинка інтернет-магазинів;
- недоступність ERP та CRM;
- простій співробітників;
- порушення логістики;
- втрата транзакцій;
- порушення SLA;
- витрати на аварійне відновлення;
- втрата клієнтів;
- репутаційні втрати.
Тому вартість аварії дата-центру може в рази перевищувати вартість фізично втраченого обладнання.
Міжнародна статистика Uptime Institute добре демонструє масштаб проблеми: 57% респондентів, які пережили великий збій ІТ-інфраструктури, оцінювали вартість свого останнього такого інциденту більш ніж у $100 000. Приблизно кожен п’ятий випадок коштував понад $1 млн.
Для великого дата-центру, який одночасно забезпечує роботу десятків або сотень компаній, економічний ефект поширюється значно далі самого оператора ЦОД.
Фактично виникає мультиплікативний ефект: одна фізична точка інфраструктури може забезпечувати роботу сотень інформаційних систем, а через них — тисяч підприємств та користувачів.
Тому реальний економічний збиток від атак на цифрову інфраструктуру потрібно рахувати не тільки в серверах і квадратних метрах дата-центру, а й у годинах простою всієї економічної екосистеми, яка від нього залежить.
Один дата-центр — це одна точка ризику
Український бізнес багато років будував захист переважно навколо відмов обладнання.
Два блоки живлення.
RAID.
Два комутатори.
Кластер серверів.
Дизель-генератор.
Декілька каналів зв’язку.
Все це правильно. Але всі ці механізми вирішують проблему лише доти, доки доступний сам фізичний майданчик.
Якщо основний сервер, резервний сервер і backup знаходяться в одній будівлі, з погляду географічного резервування це фактично одна точка відмови.
Навіть два дата-центри в одному місті в умовах війни вже не можна розглядати як достатнє географічне рознесення.
У цей складний час інформацію потрібно зберігати і за кордоном
Для українського бізнесу закордонний майданчик сьогодні потрібно розглядати як один із рівнів Disaster Recovery.
Це особливо важливо для:
- ERP та бухгалтерських систем;
- баз даних;
- електронного документообігу;
- CRM;
- корпоративної пошти;
- систем управління виробництвом;
- медичних інформаційних систем;
- архівів документів;
- репозиторіїв програмного коду;
- конфігурацій серверів та мережевого обладнання.
Це не означає, що всю інфраструктуру необхідно переносити з України.
Навпаки, найбільш стійкою є географічно розподілена модель.
Наприклад:
Основна інфраструктура в Україні
↓
Резервний майданчик в іншому регіоні України
↓
Резервна інфраструктура в Німеччині
↓
Ще одна незалежна копія даних
Головне правило — критична інформація не повинна залежати від одного сервера, одного дата-центру, одного міста, одного оператора або навіть однієї країни.
Копій має бути багато, і вони повинні бути територіально розподілені
Класичне правило резервного копіювання 3-2-1 сьогодні для України набуває особливого значення:
3 копії даних
2 різні системи або типи зберігання
1 копія географічно віддалена
Для критичної корпоративної інформації в умовах війни доцільно піти ще далі.
Наприклад:
Production — Україна
↓
оперативна репліка — інший майданчик
↓
Backup №1 — Україна
↓
Backup №2 — Німеччина
↓
Backup №3 — незалежне сховище в іншій географічній точці
При цьому хоча б одна копія повинна бути максимально ізольована від основної інфраструктури.
Це захищає не тільки від фізичної втрати обладнання, але й від помилки адміністратора, пошкодження файлової системи, злому, шифрувальника або ситуації, коли пошкоджені дані автоматично реплікуються на резервні сервери.
Реплікація — це не backup
Це принциповий момент.
Якщо база PostgreSQL у реальному часі реплікується із сервера в Україні на сервер у Німеччині — це чудовий механізм забезпечення безперервності роботи.
Але це не заміна резервному копіюванню.
Випадкове видалення інформації або логічне пошкодження бази може автоматично потрапити і на репліку.
Тому правильна схема повинна поєднувати:
реплікацію + snapshots + versioned backups + географічно розподілені копії.
Backup потрібно не тільки створювати, але й перевіряти
Наявність повідомлення:
Backup completed successfully
ще не гарантує можливості відновити систему.
Потрібно регулярно виконувати повний цикл:
Backup → перевірка → тестове відновлення → запуск системи → контроль цілісності даних.
У критичній ситуації компанія повинна вперше не з’ясовувати, як відновлювати систему.
Вона повинна виконати вже багато разів перевірену процедуру.
Що ми зробили в K2 ERP
Останні події змусили і нас додатково переглянути географію власної інфраструктури.
Критичні системи K2 ERP були перенесені до Німеччини.
Водночас частина інфраструктури продовжує працювати в Україні.
Ми будуємо систему так, щоб інформація не залежала від одного фізичного майданчика, а резервні копії та критичні дані знаходилися в декількох територіально розподілених точках.
Логіка дуже проста:
втрата сервера не повинна означати втрату системи;
втрата дата-центру не повинна означати втрату даних;
недоступність одного регіону не повинна означати зупинку бізнесу.
Це вже не надмірна пересторога
Вартість ще одного сервера, сховища або кількох терабайтів резервних копій незрівнянно менша за потенційну вартість втрати корпоративної бази даних.
Сервер можна купити.
Обладнання можна замінити.
Програмне забезпечення можна встановити заново.
Але десятирічну історію бухгалтерії, складських операцій, виробництва, взаєморозрахунків, договорів та документів купити ще раз неможливо.
Тому в цей складний час українському бізнесу варто виходити з простого принципу:
критична інформація повинна існувати одночасно в декількох незалежних, територіально розподілених точках, а щонайменше одна з них — за межами України.
Не варто чекати аварії, щоб уперше перевірити, чи працює резервування.
Найкращий backup — це той, який знаходиться достатньо далеко від основного сервера і який ви вже успішно відновлювали.

Чудовий розбір суворої реальності. В контексті High-Hazard Risk Architecture, стратегії оцінки ризиків, що я пропоную, головне уроки вересневих атак наступні:
1. Будь-який локальний майданчик (і навіть два дата-центри в одному місті) в умовах війни є Single Point of Failure.
2. Потрібна перебудова архітектури з класичної захищеності на полірегіональну стійкість (Resilience) із вибором географічно та юридично віддалених локацій.
3. Реплікація поширює помилки й пошкодження, тому ізольовані ізольовані backups (3-2-1+) + процедура їх постійної перевірки — це єдиний страховий поліс бізнесу.
Дякую за сильний кейс та практичні рекомендації!