Без резервних копій: найдавніший технічний жах без монстрів

Що насправді означає «немає резервних копій»

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

В операційних термінах «немає резервних копій» означає принаймні одне з наступного:

• Немає незалежної копії. Усі копії належать одному домену відмов: той самий акаунт, той самий регіон, та сама система зберігання, ті самі облікові дані, та сама зона ураження рансомваром.
• Немає перевіреного шляху відновлення. Резервна копія може існувати, але її не можна відновити в межах вашого RTO або взагалі.
• Немає відомої правильної точки відновлення. Копії можуть бути пошкоджені, неповні, зашифровані з відсутніми ключами або знятими під час транзакції без консистентності.
• Ніхто не володіє процесом відновлення. Резервні копії «належать IT», а відновлення — «команді додатку», що фактично означає: «ніхто цим не займеться, поки не стане занадто пізно».
• Жоден моніторинг не фіксує проблему. Завдання не запускалося 47 днів і ніхто цього не помітив, бо зелені дашборди — декоративні.

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

Одна думка, яка заощадить вам гроші та біль: якщо ви не проводили відкат‑тест нещодавно, у вас не резервні копії — у вас надія.

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

Короткий жарт №1: Резервні копії як парашути: якщо ви протестували їх тільки один раз, ви будете дуже впевнені недовго.

RPO і RTO: єдині слова, які важливі, коли вимикають світло

RPO (Recovery Point Objective) — скільки даних ви готові втратити. Якщо ваш RPO — 15 хвилин, то резервна копія, що робиться щодня, — не план відновлення; це лист про відставку, написаний у YAML.

RTO (Recovery Time Objective) — скільки часу ви готові бути недоступними. Якщо ваш RTO — 1 година, а відновлення вимагає, щоб людина знайшла ключ дешифрування в особистому сховищі колишнього співробітника, то це не відновлення; це полювання за скарбами.

Не домовляйтеся про RPO/RTO під час інциденту. Визначте наперед, отримайте підтвердження та побудуйте систему, що їх виконує. Інциденти все одно будуть. Просто не буде сюрпризів.

Факти й історія: чому це повторюється

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

8 фактів і контекстних моментів (коротко, конкретно)

1. Раніше корпоративні резервні копії будувалися навколо стрічок, бо диски були дорогі; операційна дисципліна була важливішою за залізо. Носій змінився, дисципліна — ні.
2. Правило «3-2-1» (три копії, два типи носіїв, одна офф‑сайт) передує хмарному хайпу і досі відображає істину: незалежність важливіша за елегантність.
3. RAID десятиліттями неправильно сприймали як «резервне копіювання»; RAID — це доступність, а не відновлюваність. Воно запобігає деяким відмовам і підсилює інші.
4. Снапшоти стали популярними, бо вони дешеві й швидкі (copy-on-write), що зробило їх легко недооцінити — допоки система знімків не опинилася в тому ж домені відмов.
5. Рансомваре змінив модель загрози з «відмова обладнання» на «активний противник». Якщо зловмисник може видалити резервні копії — резервних копій немає.
6. Хмара створила нову ілюзію: що довговічність автоматично означає можливість відновлення. Дурна стійкість об’єкта не допоможе, якщо ви перезаписали не те або видалили бакет з адміністративними обліковими даними.
7. Збої програмного забезпечення для бекапів часто безшумні, бо успіх зазвичай вимірюють «завдання завершено», а не «відновлення перевірене». Ви можете «успішно» завершити сміття.
8. Вимоги відповідності збільшили правила збереження (і витрати), що штовхнуло команди до агресивної дедуплікації та правил життєвого циклу — двох інструментів, які потужні й небезпечні при неправильному налаштуванні.

Ідея надійності, яку варто пам’ятати

Ось одне речення, яке має бути у ваших рунах для виконання:

«Все ламається; проектуйте так, щоб відмови були переживані.» — Werner Vogels

Якщо ви будуєте системи, це ваша задача. Не уникати відмов. Виживати під час них.

Режими відмов: як «маємо копії» перетворюється на «їх ніколи не було»

1) Той самий акаунт, ті самі ключі, той самий радіус ураження

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

Виправлення: розміщуйте резервні копії в окремому акаунті/проекті/тенанті з окремими обліковими даними і суворими схемами запису тільки між акаунтами. Якщо ви можете переглянути репозиторій резервних копій зі свого ноутбука під звичайною роллю SSO — ви вже зробили знищення надто простим.

2) Снапшоти плутають з резервними копіями

Снапшоти чудові. Вони також часто не є резервними копіями:

• Снапшоти на тому ж томі не переживуть втрату тому.
• Снапшоти на тому ж масиві не переживуть втрату масиву.
• Снапшоти, доступні з тими ж правами адміністратора, не переживуть рансомвар.

Снапшоти краще використовувати як швидке локальне відновлення. Резервні копії — як незалежне відновлення.

3) «Резервні копії пройшли» але відновлення падає

Це класика. Логи завдання показують «успіх». Репозиторій наповнений файлами. Потім ви пробуєте відновити і дізнаєтесь:

• ланцюжок залежить від відсутніх інкременталів,
• ключ шифрування зник,
• резервна копія бази даних неконсистентна,
• інструкції з відновлення ніколи не були задокументовані,
• цільова платформа змінилася (kernel, filesystem, DB major version).

Резервні копії — це продукт; відновлення — це тест прийнятності.

4) Політики зберігання, що стирають ваше минуле

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

• Ретеншн налаштовано для економії й випадково встановлено «зберігати 7 днів», а рансомвар був невиявлений 21 день.
• Правила «перемістити на дешевший шар зберігання», які порушують RTO, бо вилучення займає години.
• Версіонування об’єктів вимкнено, бо «це дорого», і потім автоматичне завдання перезаписало все.

5) «Оптимізація» як пастка: дедуплікація та інкрементальні ланцюги

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

Коли хтось каже «ми заощадили 60% місця», ваше наступне питання має бути: «Покажіть тест повного відновлення за минулий місяць.»

6) Резервні копії без ідентифікації та походження

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

Щонайменше кожен артефакт резервної копії має бути відслідкований за:

• ідентифікацією джерела (хост/БД/кластер),
• часовим вікном,
• методом консистентності (заморожування файлової системи, знімок БД, WAL‑архів),
• класом ретеншну (щоденний/тижневий/місячний),
• методом шифрування і власністю ключів,
• посиланням на процедуру відновлення (розділ руна, а не племінна пам’ять).

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

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

Компанія SaaS середнього розміру тримала основну базу даних на керованому Postgres. У них також були «резервні копії» на окремій VM: нічне завдання, яке запускало pg_dump і копіювало файл до об’єктного сховища. На папері це виглядало безпечно: керовані бекапи плюс їхня власна страховка.

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

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

Відновлення впало з помилками про відсутні зв’язки і неконсистентний стан схеми. Дамп не був чистим знімком точки в часі БД у вигляді, якого очікував додаток; це був артефакт еволюції системи. Їхня «резервна копія» не була неправильною; вона просто не підходила для відновлення, яке вони намагалися здійснити.

Вони зрештою відновилися через керовану PITR після тривалої, виснажливої сесії навчання і великого часу простою. Виправлення не було екзотичним: припинити сприймати дампи як основну страховку для гарячої, мінливої БД. Використовуйте методи бекапу, призначені для консистентності (фізичні бекапи з WAL, знімки, узгоджені з БД, або нативний PITR провайдера) і проводьте відновні тести щоквартально.

Міні-історія №2: оптимізація, що вдарила у спину

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

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

Три місяці потому баг контролера сховища пошкодив невелику частину dedup‑магазину. Не достатньо, щоб зламати систему бекапів. Не достатньо, щоб з’явилося в метриках «успіху завдання». Але достатньо, щоб зробити ланцюги відновлення ненадійними.

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

Вони відбудували репозиторій, додали періодичні синтетичні повні (верифіковані) і впровадили автоматизовані тести відновлення, які монтували відновлені файлові системи й перевіряли контрольні суми. Витрати зросли. Але й здатність спати спокійно — також.

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

Виробнича компанія мала невелику SRE‑команду, що підтримувала суміш легасі VM і контейнеризованих сервісів. Їхня система бекапів не була витонченою: ZFS‑знімки реплікувалися щодня на другий майданчик, плюс щотижневі експорті в незмінне об’єктне сховище. Рунбуки були докладно описані, і команда проводила відновний тест щомісяця.

Під час планового вікна патчів оновлення прошивки на основному масиві пройшло не так. Масив не помер драматично; він просто перестав коректно представляти кілька LUNів. З перспективи ОС файлові системи стали лише для читання, а потім неконсистентними. Додатки почали падати заплутаними способами. Інцидент не був блискучим. Це була повільна спіраль.

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

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

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

Швидкий плейбук діагностики: знайдіть вузьке місце

Коли хтось каже «бекап падає» або «відновлення надто повільне», вам потрібен швидкий шлях до обмежуючого фактора. Не починайте з переписування всього. Почніть з пошуку того, що реально обмежено: облікові дані, ємність, IOPS, мережа, CPU, здоров’я репозиторію або коректність.

По‑перше: перевірте, яка саме відмова (доступність vs коректність vs час)

• Доступність: завдання бекапу не запускаються, репозиторій недоступний, відмови в дозволах.
• Коректність: бекапи «успішні», але відновлення падає або дані відсутні/пошкоджені.
• Час: відновлення триває довше за RTO, бекапи перекриваються і ніколи не закінчуються, реплікація відстає і ламає RPO.

По‑друге: перевірте чотири вузькі місця в порядку

1. Ідентичність і дозволи: прострочені облікові дані, зламані політики IAM, змінені ключі, MFA/SSO зміни.
2. Ємність сховища і ретеншн: репозиторій заповнений, знімки обрізані зарані, об’єктний життєвий цикл видаляє дані.
3. Пропускна здатність: мережа перевантажена, дискові I/O обмежені, хмара тротлить, однопоточна компресія.
4. Консистентність: відсутнє призупинення додатку для узгодженого знімка, бекапи БД не скоординовані з логами.

По‑третє: доведіть можливість відновлення невеликим детермінованим тестом

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

• відновіть один диск VM і змонтуйте його тільки для читання,
• відновіть Postgres base backup + відтворіть WAL до відомого таймстемпу,
• відновіть одне дерево директорій і перевірте контрольні суми та кількості файлів.

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

Практичні завдання (з командами): доведіть, що можете відновити

Нижче реальні завдання, які ви можете виконати сьогодні. Кожне містить: команду, приклад виводу, що це означає і рішення, яке потрібно прийняти. Мета не милуватися виводом команди. Мета — перейти з «ми думаємо» до «ми знаємо».

Завдання 1: Переконайтеся, що у вас дійсно є свіжі резервні копії (рівень файлової системи)

cr0x@server:~$ ls -lh /backups/daily | tail -n 5
-rw-r----- 1 root backup 1.8G Jan 22 01:05 app01-etc-2026-01-22.tar.zst
-rw-r----- 1 root backup  22G Jan 22 01:12 app01-varlib-2026-01-22.tar.zst
-rw-r----- 1 root backup 4.1G Jan 22 01:18 db01-config-2026-01-22.tar.zst
-rw-r----- 1 root backup  91G Jan 22 01:55 db01-basebackup-2026-01-22.tar.zst
-rw-r----- 1 root backup 3.4M Jan 22 02:01 manifest-2026-01-22.json

Що означає вивід: Ви бачите сьогоднішні артефакти та їхні розміри, а також маніфест. Аномалії розміру (занадто маленькі/великі) — ранні ознаки проблем.

Рішення: Якщо сьогоднішні файли відсутні або явно неправильної розміри, припиніть довіряти листам про успіх. Негайно розслідуйте логи завдання та upstream‑дозволи.

Завдання 2: Перевірте успіх завдань бекапу через systemd timers

cr0x@server:~$ systemctl list-timers --all | grep backup
Tue 2026-01-22 01:00:00 UTC  6h left  Tue 2026-01-21 01:00:04 UTC  18h ago backup-daily.timer   backup-daily.service
Tue 2026-01-22 02:30:00 UTC  8h left  Tue 2026-01-21 02:30:02 UTC  16h ago backup-verify.timer  backup-verify.service

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

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

Завдання 3: Перегляньте статус останнього запуску сервісу бекапу

cr0x@server:~$ systemctl status backup-daily.service --no-pager
● backup-daily.service - Nightly backup job
     Loaded: loaded (/etc/systemd/system/backup-daily.service; enabled)
     Active: inactive (dead) since Tue 2026-01-21 01:55:13 UTC; 18h ago
    Process: 18422 ExecStart=/usr/local/sbin/backup-daily.sh (code=exited, status=0/SUCCESS)
   Main PID: 18422 (code=exited, status=0/SUCCESS)

Jan 21 01:00:04 server backup-daily.sh[18422]: starting backup run id=2026-01-21T010004Z
Jan 21 01:55:12 server backup-daily.sh[18422]: upload complete: s3://backup-prod/daily/...
Jan 21 01:55:13 server backup-daily.sh[18422]: finished OK

Що означає вивід: Юніт завершився успішно і залогував завершення завантаження.

Рішення: Успіх тут необхідний, але недостатній. Потрібно все одно перевірити цілісність і можливість відновлення (див. завдання нижче).

Завдання 4: Виявити «репозиторій повний» раніше, ніж це стане аварією

cr0x@server:~$ df -h /backups
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       7.3T  7.1T  110G  99% /backups

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

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

Завдання 5: Перевірити контрольні суми артефакту бекапу (вибіркова перевірка)

cr0x@server:~$ sha256sum -c /backups/daily/manifest-2026-01-22.sha256 | head
app01-etc-2026-01-22.tar.zst: OK
app01-varlib-2026-01-22.tar.zst: OK
db01-config-2026-01-22.tar.zst: OK
db01-basebackup-2026-01-22.tar.zst: OK

Що означає вивід: Файли відповідають зафіксованим хешам. Це ловить корупцію в сховищі або під час передачі.

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

Завдання 6: Перевірити версіонування об’єктного сховища і статус блокування (стійкість до рансомвару)

cr0x@server:~$ aws s3api get-bucket-versioning --bucket backup-prod
{
    "Status": "Enabled"
}

Що означає вивід: Версіонування увімкнене; видалення стає маркером видалення, а перезаписи зберігають попередні версії.

Рішення: Якщо версіонування «Suspended» або відсутнє, вас легше стерти. Увімкніть версіонування і розгляньте Object Lock (незмінність) там, де це доцільно.

Завдання 7: Підтвердити конфігурацію S3 Object Lock (незмінність)

cr0x@server:~$ aws s3api get-object-lock-configuration --bucket backup-prod
{
    "ObjectLockConfiguration": {
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }
}

Що означає вивід: Стандартне зберігання незмінне на 30 днів у режимі COMPLIANCE. Навіть адміністратори не можуть скоротити його.

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

Завдання 8: Перевірити затримку реплікації ZFS (перевірка RPO)

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 3
tank/appdata@2026-01-22T0100Z  Tue Jan 22 01:00 2026
tank/appdata@2026-01-22T0200Z  Tue Jan 22 02:00 2026
tank/appdata@2026-01-22T0300Z  Tue Jan 22 03:00 2026

Що означає вивід: Снапшоти існують щогодини. Це ваш теоретичний найкращий RPO локально.

Рішення: Далі підтвердьте, що ці знімки реплікуються офф‑хост. Локальні знімки самі по собі не покривають потреби в аварійному відновленні.

Завдання 9: Підтвердити, що реплікація ZFS дійсно просунулася на цілі

cr0x@server:~$ ssh backup-target "zfs list -t snapshot -o name,creation -s creation | grep tank/appdata | tail -n 3"
tank/appdata@2026-01-22T0000Z  Tue Jan 22 00:00 2026
tank/appdata@2026-01-22T0100Z  Tue Jan 22 01:00 2026
tank/appdata@2026-01-22T0200Z  Tue Jan 22 02:00 2026

Що означає вивід: Ціль відстає на один знімок від джерела. Це затримка реплікації: ваш реальний RPO зараз ~1 година, а не «щогодини».

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

Завдання 10: Виміряти пропускну здатність репозиторію під час відновлення (перевірка RTO)

cr0x@server:~$ pv /backups/daily/db01-basebackup-2026-01-22.tar.zst > /dev/null
 91.2GiB 0:12:31 [ 124MiB/s] [==================================>] 100%

Що означає вивід: Ви можете читати файл бекапу приблизно на ~124 MiB/s з репо. Це жорстка межа швидкості відновлення перед декомпресією та відтворенням.

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

Завдання 11: Перевірити, що ваш бекап містить те, що ви очікуєте (листинг tar)

cr0x@server:~$ zstd -t /backups/daily/app01-etc-2026-01-22.tar.zst
/backups/daily/app01-etc-2026-01-22.tar.zst : OK

Що означає вивід: Стиснутий файл пройшов перевірку цілісності на рівні стиснення.

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

Завдання 12: Виконати реальний відновний тест директорії в тестовий шлях

cr0x@server:~$ mkdir -p /restore-test/app01-etc && tar -I zstd -xpf /backups/daily/app01-etc-2026-01-22.tar.zst -C /restore-test/app01-etc
cr0x@server:~$ ls -l /restore-test/app01-etc/etc | head
total 64
-rw-r--r-- 1 root root  296 Jan 21 23:59 hostname
-rw-r--r-- 1 root root 1177 Jan 21 23:59 hosts
drwxr-xr-x 2 root root 4096 Jan 21 23:59 systemd
drwxr-xr-x 2 root root 4096 Jan 21 23:59 ssh

Що означає вивід: Ви успішно витягли бекап і бачите очікувані файли. Це мінімальний життєздатний тест відновлення.

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

Завдання 13: Перевірити бекапи Postgres: чи налаштовано архівацію WAL?

cr0x@server:~$ sudo -u postgres psql -c "show wal_level; show archive_mode; show archive_command;"
 wal_level
----------
 replica
(1 row)

 archive_mode
--------------
 on
(1 row)

           archive_command
-------------------------------------
 test ! -f /wal-archive/%f && cp %p /wal-archive/%f
(1 row)

Що означає вивід: WAL‑архівація увімкнена. Це важливо для відновлення до точки в часі між базовими бекапами.

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

Завдання 14: Переконатися, що WAL‑архів дійсно приймає файли (не лише налаштовано)

cr0x@server:~$ ls -lh /wal-archive | tail -n 3
-rw------- 1 postgres postgres 16M Jan 22 02:54 00000001000000A7000000FE
-rw------- 1 postgres postgres 16M Jan 22 02:58 00000001000000A7000000FF
-rw------- 1 postgres postgres 16M Jan 22 03:02 00000001000000A700000100

Що означає вивід: Нові сегменти WAL приходять кожні кілька хвилин. Це жива ознака того, що ланцюжок PITR просувається.

Рішення: Якщо директорія застояна — ваш RPO тихо дрейфує. Виправте архівацію перш ніж довіряти плану відновлення.

Завдання 15: Підтвердити, що бекап не тільки присутній, але й відновлюваний (smoke test Postgres)

cr0x@server:~$ createdb restore_smoke
cr0x@server:~$ pg_restore --list /backups/daily/appdb-2026-01-22.dump | head
;
; Archive created at 2026-01-22 01:10:02 UTC
;     dbname: appdb
;     TOC Entries: 248
;     Compression: -1
;     Dump Version: 1.14-0

Що означає вивід: Дамп читається і містить об’єкти. Це легка перевірка перед повним відновленням.

Рішення: Якщо pg_restore не читає файл — ваш бекап фактично уявний. Перейдіть на інший тип бекапу і додайте кроки верифікації.

Завдання 16: Переконатися, що ви можете розшифрувати бекапи (реальність управління ключами)

cr0x@server:~$ gpg --decrypt /backups/daily/secrets-2026-01-22.tar.gpg > /dev/null
gpg: encrypted with 4096-bit RSA key, ID 7A1C2B3D4E5F6789, created 2025-10-03
gpg: decryption ok

Що означає вивід: Операція дешифрування успішна з наявними ключами.

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

Короткий жарт №2: Єдине гірше за відсутність бекапів — мати бекапи, які не можна розшифрувати — ніби покласти ключ від сейфа всередину сейфа.

Поширені помилки: симптоми → корінь → виправлення

Цей розділ призначений для реакції на інциденти та постмортемів. Симптоми — те, що ви бачите опів на другу. Корені — чому це сталося. Виправлення — конкретні дії, які можна виконати.

1) «Бекапи кажуть SUCCESS, але відновлення падає»

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

Корінь: Критерії успіху були «файл завантажено», а не «відновлення виконано і верифіковано». Або корупція в dedup‑сховищі, або неконсистентний знімок БД.

Виправлення: Додайте автоматичну верифікацію відновлення (монтування/розпаковка + контрольні суми + smoke‑тест на рівні додатку). Тримайте періодичні верифіковані повні бекапи. Для БД використовуйте методи, які знають про додаток, і валідуйте, відновлюючи в тестову інстанцію.

2) «Ми можемо відновити, але це займає дні»

Симптоми: Пропускна здатність відновлення низька; вилучення з холодного шару займає години; декомпресія навантажує CPU; мережа насичена.

Корінь: RTO ніколи не інформував архітектуру. Бекапи збережені в найдешевшому шарі без моделювання часу вилучення. Конвеєр відновлення однопотоковий або обмежений IOPS репозиторію.

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

3) «Рансомваре видалив наші резервні копії теж»

Симптоми: Бакет бекапів порожній, знімки видалені, репозиторій зашифрований, сервер бекапів скомпрометований.

Корінь: Загальні облікові дані і відсутність незмінності. Резервні копії доступні з адміністративними ролями. Відсутня сегрегація обов’язків.

Виправлення: Роздільні акаунти та облікові дані, впровадьте ролі тільки для запису при завантаженні, увімкніть Object Lock/WORM, обмежте видалення і тримайте офлайн або логічно ізольовану копію. Аудитуйте IAM на предмет прав видалення бекапів.

4) «Ми відновили неправильне»

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

Корінь: Погане маркування/метадані, непослідовні імена, відсутність маніфесту, відсутність рунбука для вибору точки відновлення.

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

5) «Бекапи припинилися тижнями; ніхто не помітив»

Симптоми: Останній успішний бекап дуже старий. Моніторинг не спрацював.

Корінь: Моніторинг дивиться на виконання задачі, а не на наскрізний успіх. Алерти приходять у мертві канали. На виклик не викликають відповідального.

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

6) «У нас є знімки, тож ми в порядку»

Симптоми: Самовпевнені заяви до моменту, коли диск/масив/акаунт вмирає; тоді офф‑хост копія відсутня.

Корінь: Плутання інструментів доступності (RAID, знімки) з незалежністю резервних копій.

Виправлення: Реплікуйте знімки на іншу систему/акаунт/регіон. Додайте незмінний ретеншн. Документуйте, які відмови покривають знімки, а які — ні.

7) «Політика ретеншну обрізала нашу єдину хорошу точку відновлення»

Симптоми: Потрібне відновлення старіше за вікно ретеншну (наприклад, період перебування рансомвару), але воно видалене.

Корінь: Ретеншн налаштовано під вартість, а не під час виявлення та бізнес‑ризик. Правила життєвого циклу занадто агресивні.

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

Чеклісти / покроковий план

Покроково: перейдіть від «ми думаємо» до «ми можемо відновити» за 10 кроків

1. Визначте RPO і RTO для кожної системи. Не «для компанії». Зарплатна БД і маркетингове вікі не заслуговують однакової інженерії.
2. Класифікуйте дані за методом відновлення. Відновлення образу VM, відновлення на рівні файлів, PITR бази даних, скасування версій об’єктів тощо.
3. Сплануйте домени відмов. Ідентифікуйте, що може впасти разом: акаунт, регіон, масив, облікові дані, сервер бекапів, ключі KMS.
4. Зробіть принаймні одну незалежну копію. Окремий акаунт/тенант з обмеженими дозволами. Віддавайте перевагу незмінності для сценаріїв рансомвару.
5. Забезпечте консистентність бекапів. Application‑aware знімки, WAL‑архівація, заморожування файлової системи або нативні інструменти баз даних.
6. Напишіть рунбук відновлення. Включіть передумови, ключі, кроки доступу, команди та як валідувати успіх. Ставте це як production‑фічу.
7. Автоматизуйте верифікацію. Як мінімум: перевірка контрольних сум + щомісячне відновлення в тестове середовище. Краще: безперервні малі тести відновлення.
8. Моніторте «час з останньої доброї точки відновлення». Не «завдання виконано». Оповіщайте на відповідального інженера.
9. Проводьте щоквартальні DR‑вправи. Оберіть одну критичну систему. Відновіть її під хронометром і задокументуйте, що зламалося.
10. Перегляньте і посиліть дозволи. Розділіть обов’язки: адміністратори продакшену не повинні мати можливість простого видалення незмінних бекапів.

Операційний чекліст: перед тим, як погодити дизайн бекапу

• Чи можуть продакшенні облікові дані видалити резервні копії? Якщо так — виправте це першочергово.
• Чи є незмінний рівень ретеншну для критичних систем? Якщо ні — додайте.
• Чи тестувалося відновлення на поточній платформі/версії? Якщо ні — заплануйте тест.
• Чи дизайн відповідає RPO/RTO у виміряних тестах, а не в оцінках?
• Чи ключі шифрування відновлювані в умовах інциденту (SSO down, обмежений доступ on‑call)?
• Чи моніторинг базується на точках відновлення та верифікації, а не на завершенні завдань?
• Чи ретеншн покриває затримки виявлення (безпека) і юридичні вимоги?
• Чи рунбук написано так, щоб компетентний інженер, незнайомий із системою, міг його виконати?

Чекліст відновного тесту: як виглядає «готово»

• Відновлення завершено в ізольованому середовищі без втручання в продакшен.
• Цілісність верифікована (контрольні суми, кількість рядків, health‑чек додатка).
• Час відновлення виміряно і порівняно з RTO.
• Точка відновлення виміряна і порівняна з RPO.
• Проблеми зафіксовані як завдання з власниками і датами.
• Рунбук оновлено негайно на основі несподіванок, що виникли.

Поширені питання (FAQ)

1) Чи є знімки резервними копіями?

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

2) Чи є RAID резервною копією?

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

3) Яка мінімальна життєздатна стратегія резервного копіювання для маленької команди?

Почніть з: (1) автоматизовані щоденні бекапи, (2) офф‑хост копія в окремому акаунті, (3) щомісячний відновний тест в scratch‑середовищі, (4) оповіщення про пропущені бекапи. Додайте незмінність, якщо рансомвар у вашій моделі загрози (а зазвичай він є).

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

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

5) Яке вікно ретеншну «достатньо»?

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

6) Чи можемо покладатися на бекапи нашого хмарного провайдера?

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

7) Чи повинні бекапи бути зашифровані?

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

8) Що моніторити: завдання бекапу чи дані бекапу?

Моніторте існування недавньої перевіреної точки відновлення. Завдання може завершитися успішно, створивши непридатний результат. Відстежуйте «вік останньої перевіреної точки відновлення», ємність репозиторію і результати тестів відновлення.

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

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

10) Хто має відповідати за бекапи і відновлення?

Власність має бути явною. Інфраструктурні команди можуть володіти платформою, але команди додатків мають відповідати за коректність відновлення (чи працює додаток після відновлення?). Спільний рунбук і спільні вправи запобігають перекиданню відповідальності.

Висновок: кроки, які можна зробити цього тижня

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

Практичні наступні кроки, що змінять ситуацію:

1. Виберіть одну критичну систему і визначте RPO/RTO разом із бізнесом. Запишіть це. Зробіть відповідальною конкретну людину.
2. Проведіть відновний тест в тестовому середовищі. Засікайте час. Задокументуйте кожен сюрприз. Виправте один із них.
3. Розділіть домени відмов: забезпечте принаймні одну копію офф‑хост і недоступну для звичайних продакшенних облікових даних.
4. Увімкніть незмінність для тих бекапів, які важливі під час рансомвару.
5. Змініть моніторинг з «завдання виконано» на «вік останньої перевіреної точки відновлення». Налаштуйте пейджинг при дрейфі.

Системи ламаються. Люди помиляються. Є зловмисники. Єдина доросла реакція — проектувати для відновлення і доводити це вправами. Усе інше — оповідь.