Географічне резервування корпоративних даних

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

1. Квітень 2024 року: енергетична інфраструктура знову під ударом

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

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

11 квітня відбулася чергова атака. За інформацією НЕК «Укренерго», пошкоджень зазнали об’єкти генерації та підстанції в Одеській, Харківській, Запорізькій, Львівській і Київській областях. У Харківській області були запроваджені аварійні відключення.

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

Ці події мають безпосереднє значення для корпоративного ІТ.

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

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

Для підприємства, яке використовує ERP, CRM, WMS, MDM і корпоративне сховище даних, особливо небезпечною стає ситуація, коли різні компоненти інформаційної архітектури працюють із різною доступністю.

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

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

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

Головне завдання корпоративного Data Management у квітні 2024 року — забезпечити стійкість інформації до багаторазових порушень інфраструктури, а не тільки до одноразової аварії.

2. Чому резервування одного дата-центру недостатньо

Традиційний корпоративний дата-центр може мати високий рівень локальної відмовостійкості.

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

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

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

Необхідно розрізняти декілька рівнів стійкості.

Жоден рівень не замінює інші.

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

Тому корпоративна архітектура повинна поєднувати реплікацію та незалежне резервне копіювання.

3. Реплікація та резервне копіювання — різні механізми

Поняття Data Replication і Backup часто використовуються разом, проте вони виконують різні функції.

Реплікація підтримує один або декілька екземплярів даних у відносно актуальному стані.

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

Розглянемо простий приклад.

Підприємство використовує PostgreSQL для операційної бази.

Основний сервер розташований у дата-центрі А. Резервний — у дата-центрі Б.

Між ними налаштована потокова реплікація WAL.

Якщо основний сервер стає недоступним, резервний може бути підготовлений до приймання операцій.

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

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

Порівняння

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

4. Синхронна та асинхронна реплікація

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

Синхронна реплікація

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

Це може зменшувати ризик втрати підтверджених транзакцій під час перемикання.

Однак географічна відстань і затримка мережі збільшують час фіксації транзакції.

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

Отже, сильніші гарантії узгодженості можуть знижувати доступність запису.

Асинхронна реплікація

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

Це дозволяє зменшити затримки для користувачів.

Проте між основною системою та резервним сервером може існувати відставання.

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

Архітектурне порівняння

Необхідно враховувати, що конкретні гарантії синхронної реплікації залежать від СУБД, режиму підтвердження та політики перемикання.

Наприклад, у PostgreSQL налаштування synchronous_commit дозволяє визначати різні рівні очікування підтвердження. Вибір режиму повинен відповідати вимогам до збереження транзакцій.

5. RPO, RTO та Recovery Consistency

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

RPO — максимально допустима втрата даних у часовому вимірі.

RTO — цільовий час відновлення сервісу до погодженого рівня працездатності.

Але для багатосистемних процесів виникає ще одне запитання: до якого узгодженого стану мають відновитися взаємозалежні системи?

Припустимо, ERP відновлена до 10:15.

WMS містить операції до 10:20.

CRM має замовлення, створені о 10:25.

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

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

Приклад цільових вимог

Це умовні цільові значення. Реальні вимоги визначаються Business Impact Analysis.

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

6. Географічно розподілена архітектура

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

Географічне резервування повинно враховувати не тільки відстань.

Необхідно оцінити:

• енергетичні залежності;
• канали зв’язку;
• доступність адміністрування;
• фізичну безпеку;
• можливість аварійного запуску;
• правила зберігання даних;
• експлуатаційні витрати.

Логічна схема

• Основний дата-центр
• ERP · CRM · транзакційні бази · інтеграції
• Реплікація
• Backup
• Резервний дата-центр
• Репліки БД
• Резервні застосунки
• Окремі мережі
• Незалежне сховище
• Історичні копії
• Незмінюваність
• Окремі права
• Керований Disaster Recovery
• Моніторинг реплікації · рішення про перемикання · перевірка Data Integrity

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

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

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

7. Практичний приклад PostgreSQL: контроль стану реплікації

Розглянемо умовну ERP, яка використовує PostgreSQL 16.

Основний сервер передає WAL-записи резервному серверу.

Адміністратор може перевірити стан реплік через системне представлення pg_stat_replication.

SELECT
    application_name,
    client_addr,
    state,
    sync_state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

Цей запит дозволяє оцінити стан підключених реплік та характеристики передавання журналу.

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

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

Для оцінювання різниці між поточною позицією WAL та підтвердженою позицією запису на резервному вузлі можна використовувати:

SELECT
    application_name,
    pg_wal_lsn_diff(
        pg_current_wal_lsn(),
        flush_lsn
    ) AS bytes_behind
FROM pg_stat_replication
WHERE flush_lsn IS NOT NULL;

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

Сам факт надходження WAL не гарантує коректного аварійного перемикання всіх прикладних компонентів.

8. Split-brain: небезпека одночасної роботи двох основних вузлів

Одним із найбільш небезпечних сценаріїв розподіленої архітектури є split-brain.

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

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

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

Автоматично об’єднати такі дані не завжди можливо.

Тому системи аварійного перемикання повинні використовувати:

• кворум або інший механізм арбітражу;
• fencing для усунення старого вузла від запису;
• контрольовані правила вибору основного;
• перевірку стану реплікації;
• документовану процедуру повернення.

Особливо обережно слід ставитися до автоматичного перемикання між географічно віддаленими майданчиками.

Втрата мережевого зв’язку не завжди означає, що основний сервер припинив роботу.

9. Data Warehouse: інша стратегія відновлення

Для корпоративного DWH вимоги до відновлення можуть істотно відрізнятися від транзакційної ERP.

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

Проте невідтворювані історичні записи потребують незалежного захисту.

Тому доцільно розділити інформацію за можливістю відновлення.

Стратегія захисту

Застосування повної синхронної реплікації до великого DWH може бути економічно невиправданим.

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

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

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

10. Data Lake та багаторівневе зберігання

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

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

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

Але критичні дані для щоденного відновлення операцій повинні бути доступними протягом погодженого RTO.

Порівняння класів даних

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

В умовах війни архівні дані можуть бути єдиним доступним джерелом для відновлення втрачених операційних систем.

11. Відновлення ETL після тривалих перерв

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

Після відновлення зв’язку одночасний запуск усіх інтеграцій здатен перевантажити ERP або DWH.

Тому потрібна контрольована процедура catch-up processing.

Вона повинна враховувати:

1. Пріоритет джерел.
2. Послідовність пакетів.
3. Унікальність операцій.
4. Стан контрольних точок.
5. Допустимість повторного виконання.
6. Продуктивність приймача.
7. Перевірку повноти.

Для критичних потоків слід запроваджувати ідемпотентні механізми завантаження.

Наприклад, кожний пакет може мати власний ідентифікатор, а таблиця контролю — зберігати останній підтверджений стан.

SQL-приклад журналу пакетів

CREATE TABLE etl_batches (
    batch_id BIGSERIAL PRIMARY KEY,
    source_name VARCHAR(100) NOT NULL,
    source_from TIMESTAMPTZ NOT NULL,
    source_to TIMESTAMPTZ NOT NULL,
    status VARCHAR(20) NOT NULL,
    rows_loaded BIGINT,
    completed_at TIMESTAMPTZ
);

Пошук останньої підтвердженої точки:

SELECT
    source_name,
    MAX(source_to) AS last_completed
FROM etl_batches
WHERE status = 'SUCCESS'
GROUP BY source_name;

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

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

12. Технологічні можливості станом на квітень 2024 року

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

Apache Kafka 3.7.0 випущений 27 лютого 2024 року. У цій версії продовжено розвиток KRaft, зокрема представлено ранню підтримку JBOD для KRaft-кластерів, яку ще не слід трактувати як універсально готову для критичного виробничого застосування.

Apache Airflow 2.9.0 випущений 8 квітня. Серед нових можливостей — розвиток планування завдань на основі наборів даних та вдосконалення інтерфейсу.

Apache NiFi 1.25.0 доступний із 29 січня. Наступна гілка 1.26.0 на дату цієї статті ще не випущена.

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

13. Економіка реплікації та резервних майданчиків

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

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

Тому необхідно порівнювати декілька стратегій.

Умовна фінансова модель

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

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

14. Практичний сценарій: підприємство з двома дата-центрами

Розглянемо умовну українську дистриб’юторську компанію, що використовує ERP, CRM, WMS, DWH та MDM. Основний дата-центр розташований у центральній частині України.

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

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

Етап 1. Інвентаризація

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

Етап 2. Перевірка реплікації

Вимірюється фактичне відставання та здатність резервних серверів відновити транзакційний стан.

Етап 3. Перевірка незалежності

Аналізуються облікові записи, резервні копії, DNS, VPN та інші залежності.

Етап 4. Контрольоване перемикання

У тестовому сценарії підприємство імітує недоступність основного дата-центру.

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

Етап 5. Відновлення ERP

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

Етап 6. Відновлення інтеграцій

Потоки CRM–ERP, ERP–WMS та ERP–DWH запускаються після перевірки контрольних точок.

Етап 7. Data Reconciliation

Звіряються операції за період перемикання.

Етап 8. Повернення до основного майданчика

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

Це умовний сценарій архітектурного тестування.

15. Дорожня карта на 60 днів

Реальні строки залежать від масштабу підприємства та доступності інфраструктури.

Роботи з фізичним обладнанням повинні виконуватися лише за безпечних умов.

16. KPI географічної інформаційної стійкості

Показники потрібно перевіряти практично.

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

17. Ризики та типові помилки

Використання реплікації замість backup. Логічне пошкодження може бути передане на резервний сервер. Недостатній контроль мережевої затримки. Синхронна реплікація може суттєво погіршувати продуктивність.

Автоматичне перемикання без fencing. Існує ризик split-brain. Незалежні точки відновлення для взаємозалежних систем. ERP та WMS можуть опинитися в різних логічних станах.

Неперевірені резервні копії. Успішне виконання backup не гарантує відновлення. Надмірна складність. Географічна архітектура повинна відповідати можливостям експлуатаційної команди.

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

Ігнорування резервного зв’язку користувачів. Доступність серверів не гарантує доступності бізнесового процесу. Непідготовлений failback. Повернення на основний майданчик може бути складнішим за первинне перемикання.

18. Компетенції Intecracy Group

Забезпечення стійкості корпоративних даних вимагає поєднання інфраструктурних, інтеграційних та інформаційних компетенцій. Data Management IG (dmig.com.ua) спеціалізується на ETL, MDM, Data Quality, Data Warehouse, Data Lake, Data Governance та корпоративній аналітиці. У проєктах географічного резервування особливо важливі контроль цілісності інформації, відновлення ETL-процесів, узгодження довідників і забезпечення достовірності аналітики після перемикання.

IQusion IT (iqusion.com) представляє системну інтеграцію, електронний документообіг, BPM та автоматизацію бізнесових процесів. Відповідні компетенції можуть використовуватися для відновлення наскрізних процесів, керування станом документів та інтеграції прикладних систем між майданчиками. Softline IT (softline.kiev.ua) працює в напрямі серверної та мережевої інфраструктури, систем зберігання та інфраструктурних проєктів. Ці компетенції є основою проєктування резервних дата-центрів, мережевої зв’язності й надійного зберігання даних.

SL Global Service (sgs4business.com) спеціалізується на хмарній інтеграції, віртуалізації та гібридній інфраструктурі. Відповідні технології дозволяють розглядати географічно розподілені середовища, резервне розміщення прикладних систем і гнучке використання обчислювальних ресурсів.

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

географічна стійкість повинна починатися з архітектури даних

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

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

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

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

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

Для Data Warehouse важливим залишається розмежування невідтворюваних історичних даних і похідних аналітичних результатів. Це дозволяє визначати економічно доцільну стратегію відновлення.

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

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

Саме ця вимога визначає подальший розвиток корпоративного Data Management в умовах війни.