Коротка відповідь: Тест відновлення — це контрольована спроба отримати з резервної копії конкретні дані та запустити їх поза робочим середовищем: в іншій папці, на іншій віртуальній машині або на резервному обладнанні. Він нічого не перезаписує, його можна провести за один день, і він відповідає на два запитання, на які не відповідає зелена позначка в програмі резервного копіювання: чи взагалі вдасться відновлення і скільки часу воно триватиме. Результат слід зафіксувати в односторінковому звіті: дата, що відновлювали, звідки, куди, скільки часу це зайняло, хто проводив тест, результат і виявлені проблеми. Vyhláška č. 409/2025 Sb. прямо вимагає тестувати відновлення й документувати результати для режиму вищих обов’язків, а vyhláška č. 410/2025 Sb. для режиму нижчих обов’язків — ні. Періодичність не встановлює жодна з них.
Більшість компаній, з якими ми говоримо про резервне копіювання, перебувають в однаковій ситуації: резервні копії в них є. NAS у серверній, копія в хмарі, електронна пошта в Microsoft. Щоранку програма резервного копіювання повідомляє, що завдання виконано успішно. Кілька місяців ці повідомлення читають, а потім просто фільтрують в окрему папку. Коли ми запитуємо, коли востаннє хтось щось відновлював із цієї резервної копії, відповідь одна: ніколи. Це означає, що резервна копія у вас є, але її працездатність не перевірено. Різниця між цими двома станами стає очевидною лише в день, коли від неї залежить робота компанії.
Чому «резервне копіювання працює» не означає «ми зможемо відновитися»
23 квітня 2025 року Veeam оприлюднила результати опитування 1 300 організацій, 900 із яких уже зазнали кібератаки. За попередні дванадцять місяців атаковано було 69 % із них. Однак найважливіші цифри стосуються відновлення: лише 10 % організацій відновили понад 90 % своїх даних, а 57 % — менше половини. Водночас атаки зачепили 66 % сховищ резервних копій.
Отже, більшість постраждалих компаній мали резервні копії, але все одно не змогли повернути навіть половину даних. Десь резервну копію зашифрували разом із робочим середовищем, оскільки вона була підключена до того самого домену й використовувала ті самі облікові дані. Десь у ній не виявилося саме того, що ніхто не додав до завдання: бази даних, конфігурації або поштових скриньок. А десь ніхто не знав, як перетворити резервну копію на працездатний сервер.
При цьому програма резервного копіювання повідомляла про успіх. Але її повідомлення означає не те, що зазвичай у ньому бачать: воно лише підтверджує, що завдання завершилося й дані було записано до цільового сховища. Воно не повідомляє, чи містить резервна копія все необхідне, чи можна повернути дані в роботу і чи вміє хтось у компанії це зробити.
Перевірка цілісності — це не тест відновлення
Найчастіше з тестом відновлення плутають функцію, яка виглядає як перевірка можливості відновити дані. У Synology Hyper Backup це перевірка цілісності даних. Згідно з документацією Synology, вона перевіряє, чи може завдання резервного копіювання продовжувати роботу і чи можна відновити резервну копію, але самі дані під час перевірки не передаються. Цю функцію варто ввімкнути, проте вона не замінює тест відновлення: перевіряється лише сховище резервної копії, а не весь шлях повернення даних у роботу. Вона не підтвердить, що за дві години ви зможете запустити бухгалтерську систему.
Що саме потрібно перевірити
Немає сенсу тестувати все одночасно. Розділіть перевірку на чотири рівні.
| Рівень | Що відновлюється | На яке запитання відповідає |
|---|---|---|
| 1. Файл і папка | Документ зі спільного диска, бажано його старіша версія | Чи можемо ми повернути видалений файл і знайти правильну версію? |
| 2. Уся машина | Сервер або ноутбук у віртуальну машину чи на резервне обладнання (bare-metal) | Чи запуститься машина, якої фізично не існує? |
| 3. База даних і бухгалтерська система | База даних, бухгалтерські дані, ERP — і передусім їх фактичний запуск | Чи запуститься програма з відновленими даними і чи правильні ці дані? |
| 4. Microsoft 365 | Поштова скринька, OneDrive, SharePoint | Чи маємо ми власну копію, чи покладаємося лише на кошик постачальника? |
Рівень 2 майже ніколи не перевіряють, хоча саме він стає вирішальним у день збою. Рівень 3 — найпідступніший: файл бази даних скопіювати зазвичай вдається, але копія, створена під час роботи без взаємодії з програмою, може бути неузгодженою, і програма відмовиться її відкривати. Тому під час тесту відновлену базу даних необхідно справді запустити. Рівень 4 — окрема тема; ми розглядаємо її у статті про те, чому Microsoft 365 не створює резервні копії ваших електронних листів.
Як провести тест відновлення на Synology
Відновлення файлу через Hyper Backup до іншої папки. Відкрийте оглядач резервних копій для конкретного завдання, виберіть версію за датою та позначте папку або файл. Під час відновлення вкажіть інше цільове розташування — тестову папку, а не початковий шлях. Відновлення в інше місце не може пошкодити робочі дані, тому тест можна провести навіть у робочий час. Після завершення відкрийте файл, перевірте його версію та видаліть тестову папку.
Відновлення всієї машини через Active Backup for Business. Згідно зі специфікацією Synology, ця програма підтримує bare-metal-відновлення за допомогою Recovery Media Creator: створюється завантажувальний носій, із якого машину відновлюють на чисте обладнання. Також доступне instant restore — негайний запуск резервної копії як віртуальної машини у vSphere, Hyper-V або Synology Virtual Machine Manager.
Для тестування найзручніше використовувати instant restore: резервна копія запускається як віртуальна машина безпосередньо на NAS у VMM, без будь-якого втручання в оригінальну систему. Під час запуску від’єднайте мережеву карту або підключіть машину до ізольованої мережі. Відновлений сервер має те саме ім’я, IP-адресу й ролі, що й робочий, а дві однакові машини в одній мережі спричинять проблеми.
Враховуйте також зазначені Synology обмеження на одночасну роботу: Active Backup for Business підтримує одночасно не більше 10 файлових серверів, а залежно від обсягу оперативної пам’яті NAS — 10, 30 або 50 комп’ютерів і віртуальних машин. Тому плануйте тест поза часовим вікном виконання звичайних резервних копій.
Як провести тест відновлення у Veeam Backup & Replication
У випадку Veeam перше запитання зазвичай стосується ліцензії. Veeam Backup & Replication Community Edition безплатна для 10 інстансів, причому робоча станція рахується як 1 інстанс, а сервер — як 3 інстанси. Десяти інстансів вистачить, наприклад, для трьох серверів і однієї робочої станції або для двох серверів і чотирьох робочих станцій. Невелика компанія цілком може вкластися в цей ліміт і тестувати відновлення без витрат на придбання ліцензії.
Сам тест проводиться за тим самим принципом, що й у Synology: відновлювати потрібно поруч із робочим середовищем, а не поверх нього. Віртуальну машину запускають під іншим ім’ям в ізольованій мережі, а файли відновлюють до нової папки. Перезапис оригіналу — це не тест, а втручання в роботу системи.
На відновленій машині перевірте три речі: чи завантажилася операційна система, чи запустилися служби — база даних, сервер застосунку, спільний доступ до файлів — і чи відкривається в програмі реальний, відомий вам запис. Лише це можна вважати відновленням. Завантажений екран входу ще не доводить, що дані всередині справні й мають сенс.
Як виміряти RTO та RPO вашої компанії
Ці дві абревіатури постійно з’являються в документації про резервне копіювання, але мало хто уявляє за ними конкретні цифри.
RTO (час відновлення роботи) — це час, протягом якого служба має повернутися до нормальної роботи. Його вимірюють від моменту збою до миті, коли люди знову можуть нормально працювати, а не лише до завершення відновлення даних. До нього входить і час, необхідний для виявлення збою та пошуку резервного обладнання.
RPO (точка відновлення даних) — це допустимий обсяг втраченої роботи, виражений у часі. Якщо резервна копія створюється раз на день о другій ночі, а система виходить із ладу о 16:00, ви втратите весь робочий день. На практиці RPO приблизно дорівнює інтервалу між резервними копіями.
Обидва показники визначаються не технікою, а потребами компанії. Для кожної важливої служби дайте відповідь на два запитання: як довго компанія зможе працювати без неї і скільки годин роботи ви готові виконати повторно. Запишіть відповіді як цільові значення.
Тест відновлення дасть фактично виміряні значення. Окремо заміряйте три етапи: підготовку — пошук носія, паролів і документації; саме відновлення даних; завершальні дії до досягнення працездатного стану. Порівняйте їхню суму з необхідним RTO. Якщо виміряний RTO значно вищий, це не привід переписувати цільове значення. Це виявлена проблема, для якої потрібне окреме рішення: швидший канал передавання, підготовлена резервна машина або задокументована процедура. Перший тест зазвичай показує, що найбільше часу забрало не передавання даних, а пошук: де ліцензійний ключ, хто знає пароль до NAS і де зберігається остання офлайн-копія.
Шаблон звіту про тест відновлення
Звіт не повинен бути десятисторінковим протоколом. Однієї сторінки на кожен тест достатньо; її цінність у тому, що вона існує й має дату. Зберігайте її в експлуатаційній документації, а не в електронній пошті.
| Поле | Що потрібно зазначити |
|---|---|
| Дата й час | Коли тест почався і коли завершився |
| Що відновлювали | Конкретна система або дані: файловий сервер, бухгалтерська база даних, поштова скринька |
| Звідки | Джерело резервної копії: завдання, сховище, версія за датою |
| Куди | Тестова папка, ізольована віртуальна машина, резервне обладнання — з прямим зазначенням, що це не було робоче середовище |
| Скільки часу | Виміряний час: підготовка, відновлення даних, доведення до працездатного стану |
| Хто | Ім’я людини, яка проводила тест, і тих, хто був присутній |
| Результат | Успішно / успішно із застереженнями / невдало — і чим це підтверджено: відкритим документом, запущеною службою |
| Виявлені проблеми й виправлення | Які проблеми виявлено, хто їх виправить і до якого терміну |
Додайте до звіту доказ, а не лише твердження: знімок екрана із завершеним відновленням, витяг із журналу або знімок відкритого файлу. Рядок «Виявлені проблеми й виправлення» — найцінніший. Тест, після якого ніхто нічого не виправив, залишається лише навчальною вправою.
Що вимагають нормативні акти, а чого вони не вимагають
Із 1 листопада 2025 року правила відрізняються залежно від режиму обов’язків. Який режим стосується вашої компанії і чи стосується її взагалі будь-який із них, ми пояснюємо у статті про Zákon č. 264/2025 Sb. і суб’єктів, на яких він поширюється. Тут ідеться лише про резервні копії.
Режим вищих обов’язків — Vyhláška č. 409/2025 Sb. У § 26 odst. 3 písm. a) a b) зобов’язана особа повинна забезпечити регулярне тестування цілісності, доступності й можливості відновлення резервних копій, а також документування результатів цих тестів. Písmeno c) того самого відступу вимагає захищати резервні копії щонайменше шифруванням відповідно до § 25, а odstavec 5 — відокремлювати середовище резервного копіювання від інших середовищ. Крім того, § 15 písm. c) a e) зобов’язує встановити час відновлення роботи й точку відновлення даних, тобто RTO та RPO, а також регулярно тестувати плани безперервності діяльності й плани відновлення.
Режим нижчих обов’язків — Vyhláška č. 410/2025 Sb. Вона м’якша. У § 6 písm. c) вимагається регулярне резервне копіювання, але прямої вимоги тестувати можливість відновлення там немає. Натомість § 11 písm. a) вимагає сегментації мережі, зокрема відокремлення робочого середовища від середовища резервного копіювання. На практиці це означає, що резервна копія не повинна використовувати ті самі облікові дані й перебувати в тому самому сегменті, що й система, яку вона захищає.
А тепер про поширену помилку. Часто стверджують, що закон зобов’язує щомісяця тестувати відновлення. Це не так: жодна з двох vyhláška не встановлює періодичності тестів. Режим вищих обов’язків вимагає регулярно тестувати й документувати результати, але інтервал зобов’язана особа визначає самостійно. Режим нижчих обов’язків узагалі прямо не вимагає тестувати можливість відновлення.
Зі строками пов’язаний також Zákon č. 264/2025 Sb.: відповідно до § 6 odst. 1 про регульовану послугу потрібно повідомити Úřadu не пізніше ніж протягом 60 днів, а згідно з § 13 odst. 4 заходи безпеки потрібно впровадити не пізніше ніж протягом одного року з моменту отримання рішення про реєстрацію.
Як часто тестувати відповідно до належної практики
Наведене нижче — уже не цитата нормативного акта, а практична рекомендація. Визначайте періодичність залежно від того, як довго компанія може працювати без конкретної служби.
- Після кожної істотної зміни. Новий сервер, міграція, зміна завдання резервного копіювання, нова бухгалтерська система. Саме після змін резервне копіювання часто непомітно перестає працювати, хоча повідомлення й надалі виглядають успішними.
- Відновлення файлу: короткий інтервал, мінімальні витрати часу. Воно займає кілька хвилин і допомагає не втрачати навичку. Його можна проводити щокварталу.
- Відновлення всієї машини: щонайменше раз на рік, а для ключових систем — частіше. Саме цей тест дає виміряне RTO. Заплануйте для нього пів дня в спокійний період, а не під час закриття звітного періоду.
- Відновлення бази даних і бухгалтерської системи: прив’яжіть до бухгалтерського циклу, коли зрозуміло, які саме дані повинні міститися в копії.
- Завжди залучайте того, хто робитиме це під час справжнього збою. Якщо тест здатна провести лише одна людина, це вже виявлена проблема: компанія має єдину точку відмови серед людей, а не в техніці.
Резервна копія також має бути достатньо віддалена від робочого середовища, інакше ви тестуєте копію, яку той самий інцидент знищить разом з оригіналом. Правило трьох копій, двох типів носіїв і однієї копії поза основним майданчиком ми описуємо у статті про зовнішній диск і правило 3-2-1, а порядок дій, якщо інцидент уже стався, — у матеріалі про перші 24 години після атаки програм-вимагачів.
Саме це ми робимо в ITHOPE у Брно в межах керування IT та резервного копіювання: контролюємо, чи справді завдання резервного копіювання завершилися, і через погоджені проміжки часу проводимо тест відновлення. Після нього залишається датований звіт із виміряними значеннями часу й виявленими проблемами. Отже, компанія має не лише резервну копію, а й підтвердження, що з неї можна відновитися, і знає, скільки часу це займе. Перелік послуг наведено в огляді IT для компаній.
Якщо тест відновлення покаже, що NAS або ланцюжок резервного копіювання потребує втручання фахівця, ми вирішимо це в межах обслуговування NAS у Брно — від заміни дисків до налаштування резервного копіювання, з якого справді можна відновити дані.
Джерела
- Vyhláška č. 409/2025 Sb. (режим вищих обов’язків), § 15 a § 26 — e-sbirka.cz/sb/2025/409
- Vyhláška č. 410/2025 Sb. (режим нижчих обов’язків), § 6 a § 11 — e-sbirka.cz/sb/2025/410
- Zákon č. 264/2025 Sb., § 6 a § 13 — e-sbirka.cz/sb/2025/264
- Veeam: пресреліз про опитування 1 300 організацій (23. 4. 2025) — veeam.com
- Veeam: Backup & Replication Community Edition — veeam.com/blog
- Synology: Hyper Backup — Backup Settings — kb.synology.com
- Synology: Active Backup for Business — Software Specifications — synology.com
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).