Коротка відповідь: Зелена позначка біля завдання резервного копіювання означає лише, що завдання завершилося, а не те, що компанія зможе повернутися до роботи за допомогою цієї копії. Перевірка цілісності в Synology Hyper Backup, за описом виробника, підтверджує, що завдання може тривати й резервну копію можна відновити, але дані при цьому не переносяться. Тест відновлення, навпаки, означає відновлення копії окремо від робочого середовища та перевірку працездатності відновлених даних і систем. Vyhláška č. 409/2025 Sb. зобов’язує суб’єктів у режимі вищих обов’язків тестувати відновлюваність і документувати результати; vyhláška для нижчого режиму прямо цього не вимагає, а конкретного інтервалу не встановлює жодна з них.
Найдорожча фраза, яку ми чуємо під час роботи із замовниками: «У нас є резервна копія». Після паузи додають: «Просто ми ніколи не пробували її відновити». У цей момент компанія не знає, чи має вона резервну копію, чи лише програму для резервного копіювання. Різниця виявиться того дня, коли від цього залежатиме робота компанії.
Цей матеріал не пояснює, на кого поширюється Zákon o kybernetické bezpečnosti; для цього є окремий огляд Zákon č. 264/2025 Sb.. Тут розглядається одне питання: що таке тест відновлення, що насправді вимагають відповідні виконавчі vyhlášky та як компанія з NAS може провести такий тест за пів дня, включно зі складанням документа, який можна надати для перевірки.
Перевірка цілісності — не тест відновлення
Ці дві процедури плутають найчастіше, адже в інтерфейсі вони виглядають схоже: обидві завершуються зеленою позначкою.
Перевірка цілісності перевіряє саму резервну копію — чи відповідають дані у сховищі тому, що записала туди програма резервного копіювання. Для Synology Hyper Backup виробник зазначає, що перевірка цілісності визначає, чи може завдання тривати та чи можна відновити резервну копію, але дані під час неї не переносяться. Це перевірка стану архіву, а не випробування відновлення.
Тест відновлення передбачає протилежний напрямок передавання даних. Ви берете резервну копію, відновлюєте з неї конкретні дані або весь комп’ютер у безпечне цільове середовище та перевіряєте, чи можна реально користуватися відновленим об’єктом: база даних запускається, бухгалтерська програма відкриває дані за минулий рік, а спільна папка містить останні документи.
Різниця має практичне значення. Перевірка цілісності не виявить, що:
- резервне копіювання роками виконується без помилок, але не охоплює папку, яку хтось перемістив;
- база даних копіюється під час роботи без узгодженого знімка й після відновлення не запускається;
- ключ до зашифрованої резервної копії знає лише одна людина, яка зараз у відпустці;
- відновлення 900 ГБ через інтернет триває три дні, тому «резервна копія існує» і «компанія завтра працюватиме» — це два різні твердження.
Що vyhlášky говорять про тести відновлення — і чого не говорять
Із 1 листопада 2025 року діють дві виконавчі vyhlášky, і саме в цьому питанні їхні вимоги відрізняються. Режим, який поширюється на компанію, залежить від класифікації за законом; нижче наведено лише вимоги кожної vyhláška до резервних копій.
| Тема | Нижчий режим — vyhláška č. 410/2025 Sb. | Вищий режим — vyhláška č. 409/2025 Sb. |
|---|---|---|
| Резервні копії | § 6 písm. c) вимагає «pravidelné zálohy» | § 26 odst. 3 písm. a) вимагає «pravidelné testování jejich integrity, dostupnosti a obnovitelnosti» |
| Документування тесту | прямої вимоги тестувати відновлюваність немає | § 26 odst. 3 písm. b) вимагає «dokumentování výsledků» цих тестів |
| Захист резервних копій | — | § 26 odst. 3 písm. c) — захист щонайменше шифруванням відповідно до § 25 |
| Відокремлення середовища резервного копіювання | § 11 písm. a) — сегментація мережі «včetně oddělení provozního a zálohovacího prostředí» | § 26 odst. 5 — відокремлення середовища резервного копіювання від інших середовищ |
| RTO та RPO | — | § 15 písm. c) — визначити час відновлення роботи та точку відновлення даних |
| Тестування планів | — | § 15 písm. e) — «pravidelně testovat plány kontinuity činností a plány obnovy» |
З цього випливають три висновки, які варто озвучити.
По-перше, поширене твердження «закон зобов’язує щомісяця тестувати відновлення» неправильне. Жодна з vyhlášky не встановлює конкретної періодичності тестів. Vyhláška č. 409/2025 Sb. використовує слово «pravidelné»; частоту компанія визначає на основі власних ризиків, погоджених RTO та RPO, а також частоти змін у середовищі. Той, хто продає вам певний інтервал як цитату із закону, насправді цитує самого себе.
По-друге, обов’язок тестувати відновлюваність і документувати результати міститься в тексті для вищого, а не нижчого режиму. Vyhláška č. 410/2025 Sb. вимагає регулярного резервного копіювання, але прямої вимоги тестувати відновлюваність у ній немає. Утім, неперевірена резервна копія стає експлуатаційною проблемою раніше, ніж юридичною.
По-третє, відокремлення середовища резервного копіювання передбачають обидві vyhlášky. У нижчому режимі це входить до сегментації мережі, у вищому є окремою вимогою. На практиці суть однакова: резервні копії не повинні бути доступні через той самий обліковий запис і в тому самому сегменті, що й робоче середовище.
Строки впровадження встановлює сам Zákon č. 264/2025 Sb.: § 6 odst. 1 передбачає повідомлення Úřad про регульовану послугу не пізніше ніж протягом 60 днів, а § 13 odst. 4 — запровадження заходів безпеки не пізніше ніж протягом одного року від дня отримання рішення про реєстрацію. Рік здається достатнім строком, доки не спробуєш провести перший тест відновлення.
Цифри, які доводять, що це не просто формальність
23 квітня 2025 року Veeam опублікувала результати опитування 1 300 організацій, 900 із яких уже пережили кібератаку; за попередні дванадцять місяців атак зазнали 69 % опитаних. Ще важливіше те, що відбулося далі:
- лише 10 % постраждалих відновили понад 90 % даних;
- 57 % відновили менше половини;
- 66 % репозиторіїв резервних копій постраждали внаслідок атаки.
Остання цифра пояснює, чому обидві vyhlášky наполягають на відокремленні середовища резервного копіювання. Зловмисник, який проник у мережу, насамперед полює не на дані, а на те, за допомогою чого їх можна відновити. Компанія, що зберігає резервну копію на тому самому NAS і в тому самому домені, у такій ситуації має одну копію, а не дві. Якщо з дискового масиву або робочого сервера не залишиться нічого придатного для використання, це вже завдання з іншої галузі — відновлення даних із сервера, з невизначеним результатом і зовсім іншим рівнем витрат, ніж у планового тесту.
Тест відновлення на Synology: покрокова інструкція
Ця процедура передбачає використання NAS Synology з DSM і резервних копій із Hyper Backup або Active Backup for Business. Якщо заздалегідь підготувати цільове середовище, тест триватиме приблизно пів дня.
1. Виберіть, що саме тестуватимете. Не намагайтеся перевірити все одразу. Виберіть одну критично важливу для компанії систему — бухгалтерію, файловий сервер або базу замовлень — і один сценарій: «відновимо спільну папку станом на тиждень тому» або «запустимо бухгалтерський сервер із резервної копії bare-metal».
2. Підготуйте цільове середовище, яке не є робочим. Відновлюйте у віртуальну машину, на запасне обладнання або в тимчасову спільну папку — ніколи поверх даних, що використовуються. Active Backup for Business підтримує bare-metal-відновлення за допомогою Recovery Media Creator та миттєве відновлення у vSphere, Hyper-V або Synology VMM; в останньому випадку тестова машина запускається безпосередньо на NAS.
3. Запишіть час початку. Без цього тест не дасть показника часу відновлення роботи — залишиться лише враження, що «все пройшло доволі швидко».
4. Відновіть дані. У Hyper Backup виберіть версію й ціль відновлення через Backup Explorer. В Active Backup залежно від сценарію виберіть окремі файли, весь том або безпосередній запуск машини.
5. Переконайтеся, що відновлені об’єкти працюють. Саме на цьому етапі тест або стає корисним, або перетворюється на виставу. Відкрийте три-п’ять конкретних файлів, запустіть програму, увійдіть до неї та перевірте останній проведений документ. Перевіряйте вміст, а не розмір папки.
6. Запишіть час завершення та відхилення від RPO. Якщо остання резервна копія створювалася вночі, а система вийшла з ладу після обіду, компанія втратить цілий робочий день. Це інформація для керівництва, а не лише для ІТ-відділу.
7. Приберіть тестове середовище та оформте запис. Видаліть тестову машину й відновлену папку, а документ про тест збережіть там, де його можна буде знайти через рік.
Заздалегідь перевірте потужність системи: за даними виробника, Active Backup for Business може одночасно обслуговувати щонайбільше 10 файлових серверів і 10, 30 або 50 комп’ютерів та віртуальних машин залежно від обсягу пам’яті NAS. Для віртуалізованого середовища альтернативою є Veeam Backup & Replication Community Edition — безплатна версія для 10 інстансів, де робоча станція рахується як один інстанс, а сервер — як три.
Шаблон запису про тест відновлення
Vyhláška č. 409/2025 Sb. вимагає в межах вищого режиму документувати результати тестів, але не встановлює форми документа. Достатньо однієї сторінки, яка відповідає на запитання: «Що ми перевірили, яким був результат і що зробимо далі?»
| Поле | Що зазначити |
|---|---|
| Дата й час тесту | Час початку та завершення, а не лише день |
| Хто проводив тест | Ім’я та роль; для постачальника також назва компанії |
| Система, яку тестували | Конкретний сервер, спільна папка або база даних |
| Джерело резервної копії | Завдання, сховище, версія або дата відновлюваної копії |
| Сценарій і ціль відновлення | Наприклад, відновлення тому у VMM; куди саме відновлювали |
| Час відновлення | Виміряний час до досягнення працездатного стану |
| Втрата даних | Вік відновленої копії відносно моменту збою |
| Перевірка працездатності | Що перевірено та з яким результатом |
| Результат | Успішно / успішно із застереженнями / невдало |
| Виявлені недоліки | Відсутня папка, невідомий пароль, повільне з’єднання |
| Коригувальні заходи та строк | Хто й до якого строку усуне проблему |
| Відповідність RTO та RPO | Чи вклалися ми у встановлені значення? |
Найцінніший тут передостанній рядок. Тест, який завершився зеленою позначкою й нічого не змінив, — лише документ. Тест, після якого виправили охоплення резервного копіювання або забезпечили доступ до ключа, може заощадити компанії день простою.
Що найчастіше виявляється під час першого тесту
За нашим досвідом роботи з компаніями, які вперше проводять такий тест:
- Охоплення резервного копіювання не відповідає реальності. Копіюється те, що існувало на момент створення завдання. Нової папки або нового сервера в ньому немає.
- База даних копіюється як звичайний файл під час роботи. Відновлення завершується, але служба не запускається. Проблему вирішують за допомогою знімка або штатного режиму резервного копіювання бази даних.
- Ні в кого немає ключа шифрування. Резервні копії справні, але прочитати їх неможливо. Ключ слід зберігати поза системою, яку він захищає, і не лише в пам’яті однієї людини.
- RTO існує лише в уяві. Керівництво очікує відновлення за годину, а технічно воно займає два дні. Тест — єдиний спосіб виявити цю невідповідність до реального збою.
Якою має бути система резервного копіювання, яку можна тестувати, — локальна копія, відокремлене сховище та копія поза межами компанії — ми пояснюємо на сторінці резервне копіювання для компаній.
Поширені запитання
Чи зобов’язує закон щомісяця тестувати відновлення?
Ні. Vyhláška č. 409/2025 Sb. вимагає «pravidelné testování» цілісності, доступності й відновлюваності резервних копій, а також документування результатів, але конкретного інтервалу не встановлює. Компанія визначає частоту на основі ризиків, погоджених RTO та RPO і частоти змін у середовищі.
Чи достатньо перевірки цілісності в Hyper Backup як підтвердження проведення тесту?
За описом виробника, перевірка цілісності підтверджує, що завдання може тривати й резервну копію можна відновити, але не переносить дані. Щоб підтвердити відновлюваність, необхідно фактично відновити резервну копію та перевірити її вміст.
Компанія працює в режимі нижчих обов’язків — чи повинна вона тестувати відновлення?
Vyhláška č. 410/2025 Sb. у § 6 písm. c) вимагає регулярного створення резервних копій і не містить прямої вимоги тестувати відновлюваність; однак у § 11 písm. a) вона вимагає сегментації мережі, зокрема відокремлення робочого середовища від середовища резервного копіювання. Отже, з цих положень не випливає обов’язок проводити тест відновлення, але як експлуатаційний захід він доцільний незалежно від режиму.
Що робити, якщо тест завершився невдало?
Це найкорисніший із можливих результатів: ви виявили проблему в день, який обрали самі. Запишіть, що саме не спрацювало, призначте відповідального за виправлення, установіть строк і повторіть тест після усунення проблеми.
Якщо ви не наважуєтеся самостійно провести перший тест або вам потрібно налаштувати резервні копії так, щоб їх узагалі можна було перевірити, зв’яжіться з нами — ми перевіримо охоплення резервного копіювання, відокремлення відповідного середовища та підготуємо запис, який витримає контроль.
Джерела
- Vyhláška č. 409/2025 Sb. (režim vyšších povinností), § 15 a § 26 — https://www.e-sbirka.cz/sb/2025/409
- Vyhláška č. 410/2025 Sb. (režim nižších povinností), § 6 a § 11 — https://www.e-sbirka.cz/sb/2025/410
- Zákon č. 264/2025 Sb. o kybernetické bezpečnosti, § 6 a § 13 — https://www.e-sbirka.cz/sb/2025/264
- Veeam, tisková zpráva 23. 4. 2025 — https://www.veeam.com/company/press-release/veeam-report-finds-close-to-70-percent-of-organizations-still-under-cyber-attack-despite-improved-defenses.html
- Synology: Hyper Backup — nastavení zálohování dat — https://kb.synology.com/en-uk/DSM/help/HyperBackup/data_backup_settings?version=7
- Synology: Active Backup for Business — parametry — https://www.synology.com/en-us/dsm/7.4/software_spec/abb
- Veeam: Backup & Replication Community Edition — https://www.veeam.com/blog/backup-replication-community-edition-features-description.html
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).