Резервне копіювання даних за правилом 3-2-1

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

Розбираємо, як побудувати резервне копіювання даних за правилом 3-2-1, що додає до нього сучасна версія 3-2-1-1-0 і як переконатися, що копії справді спрацюють.

Правило 3-2-1: що воно означає

Правило описане, зокрема, в документі американської команди US-CERT (нині у складі агенції CISA) «Data Backup Options»:

3 копії важливих даних: оригінал і дві резервні.
2 різні типи носіїв — щоб одна причина збою не знищила всі копії. Наприклад, дискове сховище в серверній і стрічкова бібліотека або об’єктне сховище в хмарі.
1 копія поза офісом — на іншому майданчику або в хмарі, щоб пожежа, затоплення чи втрата доступу до приміщення не забрали й резервні дані.

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

3-2-1-1-0: правило з урахуванням шифрувальників

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

Тому до класичного правила додають ще дві цифри. У рекомендаціях Veeam це звучить так:

+1 копія офлайн, ізольована або незмінна — така, яку неможливо змінити чи видалити з основної мережі.
0 помилок. Відновлюваність кожної копії перевіряється автоматично.

Посібник #StopRansomware американських агенцій CISA, NSA і FBI так само радить тримати офлайн-копії критичних даних у зашифрованому вигляді й регулярно їх перевіряти.

Що саме копіювати

Сервери й віртуальні машини — цілком, щоб швидко повернути систему, а не лише файли.
Бази даних (Microsoft SQL Server, Oracle, MySQL) — узгоджені копії засобами самої СУБД або агентом, який підтримує цей застосунок; копія файлів працюючої бази може не відновитися.
Active Directory — без неї після аварії не запрацюють облікові записи й доступи.
Файлові ресурси й SharePoint.
Конфігурації мережевого обладнання та міжмережевих екранів — відновити їх з пам’яті довго.
Хмарні сервіси, зокрема Microsoft 365. У моделі спільної відповідальності, яку описує Microsoft, за дані за будь-якого типу сервісу відповідає клієнт.

Окремо про те, що резервною копією не є:

Знімок (snapshot) на тому самому сховищі: втрачається разом зі сховищем.
Реплікація й RAID: вони захищають від збою обладнання, але так само швидко копіюють видалення й шифрування.
Синхронізація з хмарним диском: видалений чи зашифрований файл синхронізується теж.

Як часто копіювати й скільки зберігати

Частоту визначає RPO — допустима втрата даних. Якщо системі допустимо втратити не більше години роботи, копія чи реплікація має бути щонайменше щогодини. Як визначити RPO і RTO для кожної системи, ми розповідали в статті «Блекаут: як захистити ІТ-інфраструктуру бізнесу».
Спосіб відновлення визначає RTO — допустимий час простою. Відновлення великої віртуальної машини зі стрічки й запуск її прямо зі сховища копій — це різний час, і його треба знати заздалегідь.
Глибина зберігання. Тримайте щоденні, щотижневі й щомісячні копії. Зловмисники можуть перебувати в мережі задовго до шифрування, тож потрібна точка відновлення, що передує проникненню. Для частини даних строки зберігання визначає законодавство — їх варто уточнити з юристом.

Як захистити самі копії

Окремі облікові записи для системи резервного копіювання, не пов’язані з основним доменом, і багатофакторна автентифікація на консолі. Veeam називає сервер резервного копіювання ціллю номер один в інфраструктурі й радить жорстко обмежувати доступ до нього.
Незмінні сховища (наприклад, об’єктне сховище з блокуванням змін) або офлайн-носії — стрічки, від’єднувані диски.
Шифрування копій, особливо тих, що зберігаються поза офісом; ключі — окремо від копій.
Мережеве відокремлення сховища копій від робочих мереж.
Моніторинг: сповіщення про невдалі завдання, видалення копій і зміну політик зберігання. Такі події — привід для негайної перевірки; їх варто передавати в моніторинг безпеки, наприклад SOC as a Service.

Перевірка відновлення

Копія, з якої ніколи не відновлювались, — це припущення, а не гарантія.

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

План відновлення

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

Порядок відновлення: мережа й Active Directory, потім бази даних, потім застосунки.
Ролі: хто ухвалює рішення, хто відновлює, хто перевіряє й повідомляє бізнес.
Куди відновлювати, якщо основний майданчик недоступний: резервна серверна, приватна чи публічна хмара. Про варіанти — у статті «Перенесення серверів у ЄС: коли це виправдано».
Де лежать інструкції й паролі доступу до копій — так, щоб вони були доступні, навіть якщо основні системи не працюють.

Якщо причина — атака, спершу закрийте шлях проникнення, а вже потім відновлюйтеся; інакше зловмисники зашифрують і відновлені системи. Перші кроки при атаці — у статті «Кібератаки на бізнес: 10 базових заходів захисту».

Типові помилки

Усі копії на тому самому сховищі або в тому самому домені, що й робочі системи.
Резервна копія доступна з облікового запису адміністратора, якого можна викрасти.
Не копіюються бази даних застосунків, Active Directory чи Microsoft 365.
Глибина зберігання — кілька днів, а атаку помічають пізніше.
Відновлення жодного разу не перевірялося.

Чек-лист

Як допоможе Bereg-IT

Почнемо з аудиту резервування: що копіюється, де зберігається, як швидко відновлюється. Далі побудуємо стратегію 3-2-1 — зокрема з резервним копіюванням як сервісом (BaaS) у хмарі чи на власних серверах, налаштуємо відновлення файлів і застосунків, зокрема Active Directory, SharePoint, Microsoft SQL Server та Oracle, і автоматичну перевірку цілісності копій. Працюємо, зокрема, з Veeam. Детальніше — на сторінках ІТ-інфраструктура і хмарні рішення; почати можна з консультації чи аудиту.

Перша консультація — безкоштовна. Залиште запит — з вами зв’яжеться ІТ-інженер.

Джерела

P. Ruggiero, M. A. Heckathorn, Data Backup Options, US-CERT (2012) — правило 3-2-1: https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf
Veeam, Best Practice Guide — Protect — правило 3-2-1-1-0 і захист сервера резервного копіювання: https://bp.veeam.com/security/Design-and-implementation/Protect.html
CISA, MS-ISAC, NSA, FBI, #StopRansomware Guide (вересень 2023) — офлайн-копії в зашифрованому вигляді: https://www.cisa.gov/stopransomware/ransomware-guide
Національний координаційний центр кібербезпеки при РНБО України, Огляд національної системи кібербезпеки України 2025 — атаки на системи резервного копіювання: https://www.rnbo.gov.ua/files/2026/NATIONAL_CYBER_SCC/kiber_2025.pdf
Microsoft Learn, Shared responsibility in the cloud — відповідальність клієнта за дані: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (2010) — RTO і RPO: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final