Як перевірити, що ваші резервні копії справді відновлюють (без видалення даних на ПК)

Відновлюваність — це результат, а не «наявність резервних копій»

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

Підступ у тому, що «відновлення» — це не одне й те саме. Відновлення може означати:

• Відновлення файлів: «Поверніть мені taxes-2024.pdf.»
• Відновлення додатка: «Поверніть базу даних на 09:14 до міграції.»
• Відновлення системи: «ПК має завантажуватися й бути придатним до роботи.»
• Відновлення після катастрофи: «Бізнес працює знову: ідентичність, додатки, дані, мережа, облікові дані.»

Перевірка має відповідати тому, що ви заявляєте, що вмієте робити. Якщо ваш план — «Я можу перевстановити ОС і відновити файли», — перевіряйте відновлення файлів. Якщо ваш план — «Я можу зробити bare-metal відновлення образу», — перевіряйте завантажуваність. Все інше — театр.

І так, ви можете перевіряти відновлення, не стираючи машину. Основні методики:

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

Цитата, яку варто приклеїти до монітора:

«Надія — не стратегія.» — генерал Гордон Р. Салліван

Жарт №1: Резервні копії — як парашути: якщо ви перевіряєте їх тільки після стрибка, ви граєте в хард-моді.

Факти та історія: чому перевіряти резервні копії складно

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

1. Ранні робочі процеси з магнітними стрічками нормалізували підхід «запиши і сподівайся на краще». Перевіряти кожну стрічку було повільно й пришвидшувало зношування носія; багато організацій перевіряли тільки заголовки або випадкові зразки.
2. Термін «вікно бекапу» з’явився через нічні задачі на стрічках. Він формував дизайн програмного забезпечення навколо «завершити до ранку», а не «швидко відновити під час паніки».
3. RAID зменшив час простою, але створив хибну впевненість. Люди почали ставитися до надлишковості як до резервного копіювання, а потім виявили, що корупція, ransomware і людська помилка не зважають на парність.
4. Контрольні суми у файлових системах (наприклад, ZFS) змінили очікування. Вони виявляють корупцію, але не дивним чином гарантовано перевіряють, що додаток можна послідовно відновити.
5. Ланцюги інкрементальних копій можуть бути крихкими. Втратили одне посилання або індекс каталогу — і «успішний бекап» перетворюється на «креативну археологію».
6. «Air-gapped» раніше був буквальним. Тепер це часто логічне відокремлення (immutable/object-lock), бо фізична ізоляція дорога й операційно болюча.
7. Ransomware змінив режим відмов з «помер диск» на «все зашифровано, включно з мережевими бекапами». Перевірка тепер включає: чи можна відновити чисті дані швидко та офлайн?
8. Дедуплікація зробила відновлення неочевидним. Дані можуть існувати тільки як чанки, на які посилається метадані; втрата метаданих може бути фатальною навіть якщо диски виглядають заповненими.
9. Хмарне зберігання зробило надійність дешевішою, але відновлення потенційно повільнішим. Експорт, обмеження швидкості та затримки «rehydration» перетворюються на реальний простої, якщо їх не протестувати.

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

Визначте, що ви перевіряєте: файли, образи системи чи повне відновлення

Перед тим як торкатися командного рядка, вирішіть твердження, яке ви хочете мати можливість робити. Оберіть одне основне «обіцянка відновлення» та другеарне. Інакше ви зробите купу перевірок, які здаються корисними, але нічого не доводять.

1) Рівень файлів (більшість людей має починати звідси)

Типові інструменти: snapshots на основі rsync, Borg, Restic, Time Machine, Windows File History. Перевірка означає:

• Успішні перевірки цілісності репозиторію
• Вміння перелічувати знімки/версії
• Можливість відновити випадкову вибірку файлів
• Права доступу, відмітки часу та символьні посилання виглядають правильно
• Для критичних даних: можна відновити все дерево в нове місце й порівняти хеші

2) Образи дисків (bare-metal стиль)

Типові інструменти: агенти Veeam, Macrium, Clonezilla, Windows System Image Backup (legacy), деякі OEM-інструменти. Перевірка означає:

• Образ читається й монтується (тільки для читання)
• Можна витягти файли з нього
• Можна завантажити його у ВМ (краще безпечне недеструктивне підтвердження)
• У вас відпрацьовані драйвери/налаштування завантажувача (UEFI vs BIOS)

3) Консистентність додатків

Якщо ви запускаєте бази даних, поштові сервери чи будь-що станоутворююче, копіювання файлів часто — це «резервна копія» в тому самому сенсі, як фото працюючого двигуна — «запасний двигун». Потрібні quiesce, snapshots, WAL-логи або рідні дампи додатка. Перевірка означає:

• Можна відновити на тестовий інстанс
• Служба стартує
• Проходять базові перевірки (версія схеми, кількість рядків, відтворення логів)

4) Модель загроз: корупція, ransomware та «ой»

Ваш план перевірки має явно покривати:

• Пошкодження медіа: bit rot, ненадійні диски, дивакуватість контролера
• Логічна корупція: погані записи, баги додатків, приховане усікнення
• Зловмисні зміни: ransomware, wipers, компрометація облікових даних
• Людська помилка: видалення, перезапис, синхронізація не тієї папки

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

План швидкої діагностики: знайдіть вузьке місце за хвилини

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

Перше: чи здоровий каталог/репозиторій резервних копій?

• Запустіть перевірку цілісності інструмента (Borg/Restic/тощо).
• Шукайте відсутні пакети, пошкоджені індекси, проблеми автентифікації або дивну поведінку після prune.
• Якщо репозиторій нездоровий — зупиніться. Виправте це перед оптимізаціями продуктивності.

Друге: чи веде себе ціль відновлення та файловий вузол?

• Підтвердіть вільне місце, доступність інодів та права на запис.
• Протестуйте сирий запис пропускною здатністю тимчасовим файлом (потім видаліть його).
• Перевірте антивірус/endpoint, чи не сканує він директорію відновлення в реальному часі.

Третє: чи транспорт повільний або ненадійний?

• Для мережевих відновлень: перевірте втрати пакетів, параметри монтування SMB/NFS, накладні витрати VPN.
• Для cloud/object: перевірте обмеження швидкості, облікові дані та чи не тягнете ви з холодного сховища.
• Міряйте одним великим файлом, а не директорією з 400k дрібними файлами.

Четверте: чи вузьке місце у метаданих або дрібних файлах?

• Мільйони файлів покарають вас за латентність та фільтри антивірусу.
• Дедуплікаційні відновлення можуть бути обмежені CPU (декомпресія/розшифрування) або I/O (випадкове читання).
• Спробуйте відновити підмножину, щоб бачити, чи час масштабується лінійно чи вибухово.

П’яте: чи ви відновлюєте правильне?

• Підтвердіть часову мітку, ім’я знімка та вибір версії.
• Огляньте на предмет ransomware: розширення файлів, ентропія, «README_RESTORE_FILES».
• Перевірте «відомі хороші» файли, чи відкриваються вони коректно.

Практичні завдання для перевірки відновлення (команди, виводи, рішення)

Нижче — практичні завдання, які ви можете виконати на Linux-станції або сервері. Навіть якщо ви на Windows або macOS, ідеї мапуються добре: перелічити резервні копії, перевірити репозиторій, змонтувати тільки для читання, відновити в пісочницю, порівняти контрольні суми і зробити тест завантаження у ВМ.

Кожне завдання містить: команду, що означає вивід, і яке рішення ухвалити далі. Це не «милі демонстрації». Це ті самі ходи, які я використовую, коли хтось клянеться, що бекапи в порядку, і мені потрібні докази, перш ніж ми поставимо на це уїк-енд.

Завдання 1: Підтвердіть, що тестуєте правильне джерело бекапу

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
NAME   SIZE FSTYPE MOUNTPOINTS MODEL            SERIAL
sda    1.8T        /           Samsung_SSD_870   S6PUNX0T123456
sdb    3.6T ext4   /mnt/backup  WDC_WD40EFRX     WD-WCC4E7ABCDEF

Що це означає: Ви бачите, який диск є диском бекапу (/mnt/backup) і підтверджуєте, що випадково не тестуєте живий кореневий диск.

Рішення: Якщо ціль бекапу не ідентифікована чітко, позначте її зараз (мітка файлової системи, unit монтування, фізична бирка). Невизначеність — як відновлення перетворюється на інцидент.

Завдання 2: Перевірте вільне місце й запас інодів на цілі відновлення

cr0x@server:~$ df -h /restore-sandbox
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc1       500G  120G  355G  26% /restore-sandbox

cr0x@server:~$ df -i /restore-sandbox
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/sdc1      32768000 2100000 30668000    7% /restore-sandbox

Що це означає: Місця достатньо і інодів багато. Закінчення інодів виглядає як «No space left on device», навіть коли df -h задоволений.

Рішення: Якщо використання інодів високе, відновлюйте на ФС з великим числом інодів або змініть підхід (відновлюйте менше дрібних файлів або спочатку створіть tar).

Завдання 3: Перевірити репозиторій Borg (цілісність перед продуктивністю)

cr0x@server:~$ export BORG_REPO=/mnt/backup/borg/laptop
cr0x@server:~$ borg check --verify-data
Starting full repository check
Verifying data integrity
Repository check complete, no problems found.

Що це означає: Структура репозиторію і чанки даних відповідають очікуваним хешам. Це найшвидший спосіб спіймати сценарій «виглядає змонтованим, але пошкодженим».

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

Завдання 4: Перелічити знімки/архіви і підтвердити реальність ретеншну

cr0x@server:~$ borg list --short
laptop-2026-01-10T020001
laptop-2026-01-17T020001
laptop-2026-01-24T020001
laptop-2026-01-31T020001

Що це означає: У вас є кілька точок відновлення. Якщо список коротший, ніж ви очікували, політики ретеншну/prune можуть їсти історію.

Рішення: Якщо є лише один знімок, у вас не «резервні копії», а єдина точка відмови з кращим маркетингом.

Завдання 5: Зробіть маленьке селективне тестове відновлення у пісочницю

cr0x@server:~$ mkdir -p /restore-sandbox/test1
cr0x@server:~$ borg extract --progress --destination /restore-sandbox/test1 ::laptop-2026-01-31T020001 home/alex/Documents/taxes-2025.pdf
0.01 GB O 0.05 GB C 1 files restored

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

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

Завдання 6: Перевірте відновлений файл на очевидну корупцію

cr0x@server:~$ file /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
/restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf: PDF document, version 1.7

cr0x@server:~$ sha256sum /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
5ef2bf9a9c3c6d1a0c7b1c0e8b0a5d2d3b2c1f1a9e0d6c5b4a3f2e1d0c9b  /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf

Що це означає: Підпис файлу правдоподібний. Контрольна сума дає стабільну ідентичність для подальших порівнянь.

Рішення: Якщо file каже «data» або «ASCII text» для того, що має бути PDF чи JPEG, підозрюйте зашифровані ransomware резервні копії або усічені відновлення.

Завдання 7: Перевірте метадані (власник, права, мітки часу)

cr0x@server:~$ stat /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
  File: /restore-sandbox/test1/home/alex/Documents/taxes-2025.pdf
  Size: 248112     Blocks: 488        IO Block: 4096   regular file
Device: 8,33   Inode: 131089      Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1000/    alex)   Gid: ( 1000/    alex)
Access: 2026-01-31 02:14:03.000000000 +0000
Modify: 2026-01-29 18:51:22.000000000 +0000
Change: 2026-01-31 02:14:03.000000000 +0000

Що це означає: Права і власник збережені. Для деяких відновлень (особливо на Windows-шарінгах або NAS) тут тихо виникають проблеми.

Рішення: Якщо власник став root або права — 777, ваше відновлення «працює», але додатки впадуть. Виправте опції інструмента бекапу, опції монтування або обробку ACL.

Завдання 8: Перевірка репозиторію Restic + селективне відновлення

cr0x@server:~$ export RESTIC_REPOSITORY=/mnt/backup/restic/workstation
cr0x@server:~$ restic check
using repository at /mnt/backup/restic/workstation
created new cache in /home/cr0x/.cache/restic
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

cr0x@server:~$ mkdir -p /restore-sandbox/restic-test
cr0x@server:~$ restic restore latest --target /restore-sandbox/restic-test --include "/home/alex/.ssh/config"
restoring  to /restore-sandbox/restic-test
Summary: Restored 1 files/dirs (1 B) in 0:00

Що це означає: Перевірка цілісності чиста, і можна відновити відомий чутливий файл. SSH config — хороший канарчик, бо права важливі і люди помічають, коли щось не так.

Рішення: Якщо restic check чистий, а відновлення падає, підозрюйте права файлової системи на цілі або невідповідність шляхів через include/exclude правила.

Завдання 9: Перевірка rsync-сnapshots шляхом порівняння випадкової вибірки

cr0x@server:~$ ls -1 /mnt/backup/snapshots | tail -5
2026-01-10
2026-01-17
2026-01-24
2026-01-31

cr0x@server:~$ find /mnt/backup/snapshots/2026-01-31/home/alex -type f | shuf -n 5
/mnt/backup/snapshots/2026-01-31/home/alex/Documents/taxes-2025.pdf
/mnt/backup/snapshots/2026-01-31/home/alex/Pictures/IMG_1882.jpg
/mnt/backup/snapshots/2026-01-31/home/alex/.ssh/config
/mnt/backup/snapshots/2026-01-31/home/alex/Projects/app/README.md
/mnt/backup/snapshots/2026-01-31/home/alex/Notes/meetings.txt

cr0x@server:~$ rsync -nac --delete /mnt/backup/snapshots/2026-01-31/home/alex/ /home/alex/ | head -20
sending incremental file list
.d..t...... ./
>fc........ Documents/taxes-2025.pdf
>fc........ Pictures/IMG_1882.jpg

sent 5,024 bytes  received 412 bytes  10,872.00 bytes/sec
total size is 148,801,932  speedup is 27,374.58 (DRY RUN)

Що це означає: -n робить це dry run; -c порівнює контрольні суми; рядки з початковим > вказують на відмінності в змісті. Це може означати, що живі файли змінилися після знімка (нормально) або ваш знімок не той, що ви вважаєте.

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

Завдання 10: Змонтувати образ диска в режимі лише для читання і переглянути його (без ризикового відновлення)

cr0x@server:~$ sudo mkdir -p /mnt/image
cr0x@server:~$ sudo losetup --find --partscan --read-only /mnt/backup/images/laptop-2026-01-31.img
/dev/loop7
cr0x@server:~$ lsblk /dev/loop7
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop7       7:7    0  238G  1 loop
├─loop7p1 259:0    0  512M  1 part
└─loop7p2 259:1    0  237G  1 part

cr0x@server:~$ sudo mount -o ro,noload /dev/loop7p2 /mnt/image
cr0x@server:~$ ls /mnt/image
bin  boot  etc  home  lib  opt  root  usr  var

Що це означає: Ви довели, що образ структурно читається і містить правдоподібну файлову структуру. ro і noload знижують шанс модифікації журналованих файлових систем під час тесту.

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

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

cr0x@server:~$ sudo test -e /mnt/image/boot/grub/grub.cfg && echo "grub.cfg present" || echo "grub.cfg missing"
grub.cfg present

cr0x@server:~$ sudo test -d /mnt/image/boot/efi && echo "EFI directory present" || echo "EFI directory missing"
EFI directory present

Що це означає: Ви шукаєте очевидні інгредієнти для завантаження. Не остаточно, але ловить випадки, коли «образ містив тільки /home».

Рішення: Якщо це відсутнє і ви очікували завантажуваний образ, перегляньте, що насправді включав ваш інструмент іміджування. «Системний бекап» іноді означає «деякі розділи», що є ввічливою формою «сюрприз».

Завдання 12: Тест завантаження відновленого образу у ВМ (краще підтвердження без стирання)

cr0x@server:~$ qemu-system-x86_64 -m 4096 -enable-kvm -drive file=/mnt/backup/images/laptop-2026-01-31.img,format=raw,if=virtio -boot c -net nic -net user
SeaBIOS (version 1.16.3)
Booting from Hard Disk...
[    0.000000] Linux version 6.5.0 ...
Reached target Graphical Interface.

Що це означає: Це золотий стандарт недеструктивного тесту для образів: система завантажується. Ви щойно довели «можу відновити машину», не торкаючись реального ПК.

Рішення: Якщо вона не завантажується, зафіксуйте консольний вивід. Типові причини: невідповідність UEFI/BIOS, відсутні initramfs-драйвери для virtio, зашифрований корінь без обробки ключа або завантажувач встановлено не туди.

Завдання 13: Перевірка ZFS snapshot з scrub + вибіркове відновлення

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:18:22 with 0 errors on Sun Feb  2 03:20:41 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sda       ONLINE       0     0     0
          sdb       ONLINE       0     0     0

errors: No known data errors

cr0x@server:~$ zfs list -t snapshot -o name,creation | tail -3
tank/home@2026-01-24  Sun Jan 24 02:00 2026
tank/home@2026-01-31  Sun Jan 31 02:00 2026
tank/home@2026-02-02  Sun Feb  2 02:00 2026

cr0x@server:~$ mkdir -p /restore-sandbox/zfs-test
cr0x@server:~$ zfs clone tank/home@2026-01-31 tank/home-restore-test
cr0x@server:~$ zfs set mountpoint=/restore-sandbox/zfs-test tank/home-restore-test
cr0x@server:~$ ls /restore-sandbox/zfs-test/alex/Documents | head
invoices
taxes-2025.pdf

Що це означає: Scrub перевіряє контрольні суми на диску; clone доводить, що можна матеріалізувати точку в часі й отримати доступ до файлів без копіювання всього датасету.

Рішення: Якщо scrub показує помилки контрольних сум, вважайте пул компрометованим, поки не з’ясуєте, чи виправила надлишковість їх. Якщо clone/монтування падає, можлива проблема з простором імен або mountpoint-конфлікт — виправте це перед реальним відновленням.

Завдання 14: Виявлення «зашифрованих бекапів» після інциденту з ransomware (тест ентропії)

cr0x@server:~$ python3 - <<'PY'
import os, math
p="/mnt/backup/snapshots/2026-01-31/home/alex/Documents"
files=[os.path.join(p,f) for f in os.listdir(p) if os.path.isfile(os.path.join(p,f))][:20]
def entropy(data):
    from collections import Counter
    c=Counter(data)
    n=len(data)
    return -sum((v/n)*math.log2(v/n) for v in c.values())
for f in files:
    with open(f,'rb') as fh:
        b=fh.read(65536)
    e=entropy(b) if b else 0
    print(f"{e:0.2f} {os.path.basename(f)}")
PY
7.98 Q1-report.docx
7.99 taxes-2025.pdf
7.97 notes.txt

Що це означає: Дуже висока ентропія для багатьох типів файлів може бути червоним прапором шифрування (або стиснених форматів). Це не вирок; це пожежна тривога.

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

Завдання 15: Замірьте час відновлення (бо RTO — це число, а не відчуття)

cr0x@server:~$ /usr/bin/time -v borg extract --destination /restore-sandbox/perf ::laptop-2026-01-31T020001 home/alex/Projects
	Command being timed: "borg extract --destination /restore-sandbox/perf ::laptop-2026-01-31T020001 home/alex/Projects"
	User time (seconds): 92.11
	System time (seconds): 18.44
	Percent of CPU this job got: 325%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:45.33
	Maximum resident set size (kbytes): 812344
	File system outputs: 702400

Що це означає: У вас є реальні часи, використання CPU і I/O. Якщо CPU завантажений, шифрування/стиснення може бути обмежувачем. Якщо файлові операції великі й час довгий — сховище обмежує.

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

Завдання 16: Безпечне розмонтування/прибирання (бо залишені loop-пристрої перетворюють «тест» на «загадку»)

cr0x@server:~$ sudo umount /mnt/image
cr0x@server:~$ sudo losetup -d /dev/loop7
cr0x@server:~$ losetup -a | grep loop7 || echo "loop7 detached"
loop7 detached

Що це означає: Ваш тест залишив систему чистою. Це важливо на хостах з кількома користувачами і довготривалих машинах, де залишені монтування і loop-пристрої створюють пізні загадки.

Рішення: Якщо розмонтування не вдається через «busy», знайдіть процес, який його тримає (lsof +f -- /mnt/image) і зупиніть його. Не робіть примусового відключення, якщо не готові прийняти ризик.

Три корпоративні міні-історії з поля бою відновлення

Міні-історія 1: Інцидент через хибне припущення

Компанія мала акуратну історію бекапів: нічні інкрементали, тижневі фули, реплікація за межі. Усі були задоволені. Аудиторам показали PDF з діаграмами ретеншну і скриншот віджета «останнє завдання виконано». Проблема була в тому, що віджет вимірював завершення бекапу, а не успіх відновлення.

Вийшов з ладу контролер зберігання і знищив первинний файловий сервер. Не катастрофа — поки не почалося відновлення. Інструмент бекапу попросив «том 12» у послідовності, якої більше не існувало, бо тижневий «full» насправді не був повним. Це був synthetic-full, зібраний з інкременталів плюс метадані в каталозі.

Каталог бази даних був захищений… на тому самому сховищі, яке вийшло з ладу. Тож «full backup» концептуально був присутній, але практично недоступний. Резервні копії були цілими чанками з відсутніми інструкціями.

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

Хибне припущення: «Успішне завдання бекапу означає можливість відновлення.» Ні. Ви повинні перевірити шляхи відновлення, включно з каталогами, ключами та залежностями метаданих.

Міні-історія 2: Оптимізація, що обернулася проти

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

Потім настав перший великий відновлення: розробник видалив проектну директорію й треба було її швидко повернути. Час відновлення був жахливий. Система бекапу мусила розгортати ліс дрібних чанків, розшифровувати, декомпресувати і реконструювати метадані файлів. CPU підскочив. Диски почали шалено шукати. Мережа була в порядку; сховище репо — ні.

Вони спробували «виправити» це додатковими потоками. Це підвищило випадкові I/O і зробило ще повільніше. Також це спровокувало ліміти швидкості на шлюзі об’єктного сховища, яке вони використовували для офсайду. Тепер відновлення були й повільними, і шумними.

Нарешті спрацювало нудне рішення: тримати недавній рівень відновлення на швидкому сховищі (NVMe або принаймні пристойний SSD), використовувати адекватне стиснення і розглядати дедуплікацію як фічу економії, а не як рятівну для відновлення. Вони все ще дедуплікували — просто не за рахунок продуктивності відновлення.

Наслідок оптимізації: Оптимізація під ефективність зберігання може саботувати час відновлення (RTO). Відновлення — аварійна смуга; не забивайте її цеглинами економії.

Міні-історія 3: Нудна практика, що врятувала день

Мала група операцій мала щомісячний ритуал: «п’ятничне тренування відновлення». Це не було гламурно. Вони вибирали випадковий хост, випадкову дату, відновлювали в пісочницю ВМ і виконували короткий чекліст: завантаження, логін, перевірка кількох кінцевих точок додатків і наявність найкритичніших наборів даних.

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

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

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

Рятівна практика: Рутинні тренування відновлення перетворюють DR з «технічної загадки» в «відрепетований процес». Нудність — це фіча.

Контрольні списки / поетапний план

Контрольний список A: Перевірка файлів (30–90 хвилин)

1. Виберіть точку відновлення. Оберіть знімок з минулого тижня і один з минулого місяця. Ви тестуєте ретеншн і версіонування, а не тільки вчорашню задачу.
2. Запустіть перевірку цілісності репозиторію. Для вашого інструмента: borg check, restic check тощо.
3. Відновіть у пісочницю. Ніколи не відновлюйте на оригінальний шлях для тесту.
4. Відновіть випадкову вибірку + критичні файли. Випадкова вибірка ловить невідомі проблеми; критичні — бізнес-реальність.
5. Перевірте вміст. Використайте file, безпечно відкрийте документи, перевірте архіви, запустіть sanity checks для додатків, якщо потрібно.
6. Перевірте метадані. Права, власники, мітки часу, символьні посилання, ACL де релевантно.
7. Заміряйте час. Швидкість відновлення — частина «воно працює».
8. Запишіть точні команди, які ви виконали. Якщо ви не можете повторити — ви не перевірили; вам просто пощастило один раз.

Контрольний список B: Перевірка образів без стирання (60–180 хвилин)

1. Змонтуйте тільки для читання. Доведіть, що можна читати розділи й файли.
2. Витягніть файл. Витягніть файл з образу (або скопіюйте з змонтованої ФС) і провалідуйте його.
3. Тест завантаження у ВМ. QEMU/VirtualBox/Hyper-V — вибирайте те, що у вас є. Завантаження — це доказ.
4. Підтвердіть вхід у систему. Якщо образ зашифрований, підтвердіть, що можете подати ключ. Якщо використовується TPM — плануйте обхід.
5. Документуйте деталі режиму завантаження. UEFI vs BIOS, стан secure boot, драйвери контролера диска.
6. Зафіксуйте час і вузькі місця. Якщо на завантаження пішло 2 години на налаштування драйверів — це ваш фактичний час відновлення.

Контрольний список C: Перевірка з орієнтацією на ransomware (додатково 30–120 хвилин)

1. Підтвердіть існування незмінного/офлайн копію. Якщо нападник може його видалити — це не план відновлення.
2. Оберіть «відомо чисту» точку відновлення. Використайте хронологію інциденту. Не відновлюйте вчора лише тому, що це найновіше.
3. Скануйте відновлені дані в карантині. Використовуйте офлайн-сканування, уникайте запуску відновлених бінарників.
4. Шукайте індикатори шифрування. Розширення файлів, ентропія, пошкоджені заголовки, підозрілі README-файли.
5. Спочатку відновлюйте в ізольовану мережу. Не реінтroduкуйте шкідливе ПЗ, відновлюючи прямо в продакшн.

Жарт №2: Якщо ваш план відновлення залежить від «єдиного, хто знає», — вітаю, ви побудували людський RAID-0.

Типові помилки: симптом → коренева причина → виправлення

Це та частина, де ми перестаємо бути ввічливими щодо «best practices» і говоримо про те, що реально ламається о 2-й ночі.

1) Симптом: «Бекап успішний», але відновлення каже архів/знімок не знайдено

Коренева причина: Ви відновлюєте з іншого репозиторію/цілі, ніж той, куди робиться бекап, або ретеншн/prune видалив точку відновлення.

Виправлення: Перевірте шлях до репо/облікові дані; перелічіть знімки і підтвердіть конвенції іменування. Додайте алерти на кількість знімків і їхній вік, а не тільки на успіх задачі.

2) Симптом: Відновлення працює для деяких файлів, для інших — помилка контрольної суми або «chunk missing»

Коренева причина: Корупція репозиторію, ненадійне сховище, перервані завантаження або пошкоджений дедуп-пакет.

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

3) Симптом: Відновлені файли є, але додатки не стартують (помилки прав доступу, конфігурація недоступна)

Коренева причина: ACL/xattr не збережені, невірний користувач відновлення або відновлення на ФС, що не може представити потрібні метадані (наприклад, FAT/exFAT).

Виправлення: Використовуйте ФС, що підтримує потрібні метадані; переконайтеся, що опції інструмента бекапу включають xattrs/ACL; відновлюйте як root при потребі, потім свідомо виправляйте власність.

4) Симптом: Відновлення болісно повільне, але CPU високий, а диск виглядає проста

Коренева причина: Накладні витрати стиснення/розшифрування, однопоточна декомпресія або метадані дрібних файлів у поєднанні з антивірусом.

Виправлення: Протестуйте з одним великим файлом; виключіть шлях відновлення з реального часу сканування під час тестів; налаштуйте паралелізм обережно; тримайте недавні бекапи на швидшому носії.

5) Симптом: Монтування образу працює, але ВМ завантажується миттєво з помилкою

Коренева причина: Невідповідність режиму завантаження (UEFI vs BIOS), відсутній EFI-розділ, обмеження secure boot або відсутні драйвери для virtio-накопичення.

Виправлення: Запустіть ВМ у тому самому режимі; використайте емуляцію SATA, якщо драйверів virtio немає; підтвердіть наявність EFI-розділу; плануйте роботу з secure boot ключами.

6) Симптом: Відновлення завершено, але дані — «нісенітниця» або не відкриваються

Коренева причина: Ви зробили бекап уже зашифрованих файлів від ransomware, або інструмент бекапу зберіг тимчасові файли під час запису додатка (неконсистентний стан).

Виправлення: Виберіть відомо чистий знімок; запровадьте консистентність додатків (дампи БД, snapshots з quiesce); додайте canary-файли, які обов’язково мають відкриватися коректно.

7) Симптом: Офсайдовий відновлення можливе, але займає дні

Коренева причина: Офсайд на повільному каналі, з лімітами, у холодному сховищі, або ви ніколи не планували час на egress і rehydration.

Виправлення: Підтримуйте локальний швидкий рівень для недавніх даних; тестуйте офсайдові відновлення щоквартально; документуйте реалістичний RTO для найгіршого сценарію.

8) Симптом: Після відновлення виявляються відсутні папки, які «мали би бути»

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

Виправлення: Аудитуйте include/exclude шаблони; зберігайте маніфест критичних директорій; тестуйте відновлення цілих дерев каталогів, а не тільки кількох файлів.

Питання й відповіді

1) Чи можу я перевірити бекапи без відновлення всього?

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

2) Який одиний найкращий недеструктивний тест відновлення для системного образу?

Запустіть образ у ВМ. Монтування доводить читабельність; завантаження доводить весь стек: розділи, завантажувач, ядро/initramfs і базову працездатність ОС.

3) Скільки файлів слід перевірити випадково?

Достатньо, щоб покрити різноманітність: кілька великих файлів, багато дрібних, різні директорії і «метаданихно-важкі» предмети (символьні посилання, конфіги з правами). Я люблю 20 випадкових файлів плюс 10 критичних як базу.

4) Чи можна довіряти команді інструмента «verify» або «check»?

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

5) А як щодо Windows? Я не виконую Linux-команди.

Процес той самий: перевірте набір бекапів, змонтуйте образ у режимі тільки для читання, витягніть файли і зробіть тест у Hyper-V або VirtualBox. Назви зміняться; режими відмов — ні.

6) Якщо в мене є RAID/ZFS надлишковість, чи все одно треба перевіряти відновлення?

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

7) Як часто слід проводити тренування відновлення?

Щомісяця для систем, через які ви не спите. Мінімум щоквартально для решти. Після великих змін (новий інструмент бекапу, нове шифрування, нове сховище) зробіть тренування негайно — зміни — місця, де тіла поховані.

8) У чому різниця між «перевіркою бекапу» та «тестом відновлення після катастрофи»?

Перевірка доводить, що ви можете відновити дані з носія/репозиторію. DR-тест доводить, що ви можете відновити сервіс: обчислення, мережу, ідентичність, залежності, моніторинг і доступ. Перевірка — необхідна; DR-тест — доросла версія.

9) Як уникнути відновлення ransomware назад у середовище?

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

10) Чи потрібні мені контрольні суми, якщо інструмент вже шифрує?

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

Наступні кроки, які можна зробити сьогодні

Практично, не героїчно:

1. Оберіть одну критичну папку (документи, фото, репозиторії) і зробіть пісочне відновлення 10 файлів з тижневого знімка.
2. Запустіть перевірку цілісності інструмента і збережіть вивід у місці, що не на диску бекапу.
3. Заміряйте час відновлення для однієї середньої директорії (кілька ГБ). Запишіть число. Це ваша стартова RTO.
4. Якщо ви використовуєте образи, зробіть тест завантаження у ВМ один раз. Це найшвидший спосіб перетворити віру в доказ.
5. Заплануйте повторюване тренування відновлення (щомісяця). Поставте його в календар як будь-яке технічне обслуговування. Якщо його не запланувати, воно не відбудеться.
6. Документуйте кроки відновлення простими словами з точними командами, де лежать ключі/паролі і як знайти правильний знімок.

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