# Резервні копії, які справді відновлювали Побудувала зашифроване резервне копіювання поза хостом на restic з очищенням за політикою зберігання, перевіркою цілісності та щомісячним автоматичним тренувальним відновленням, а потім провела аудит готовності до відновлення й задокументувала прогалини, щоб їх не довелося виявляти під час інциденту. вересень 2026 **Ситуація.** Усе, що має компанія, — git‑репозиторії, база даних, сайт — працювало на одному хмарному інстансі, і вся можливість відновлення трималася на знімку від провайдера. Такий знімок добре мати, але погано на нього покладатися: він лежить у тому самому обліковому записі, що й машина, яку він захищає, ніхто в компанії його не шифрує, і з нього жодного разу ніхто не відновлювався. **Завдання.** Резервні копії мали бути зашифрованими, лежати поза хостом, очищатися за політикою зберігання і — цю частину зазвичай пропускають — справді слугувати для відновлення: за розкладом і без того, щоб хтось мусив про це пам'ятати. **Дія.** Резервне копіювання запускає таймер systemd: спершу дамп бази даних, якщо вона є, потім зашифрований знімок із дедуплікацією в сховище іншого провайдера через SFTP, далі очищення за політикою зберігання і перевірка цілісності. Сигнал для dead man's switch надсилається лише після успішного запуску, і саме ця відмінність робить його сигналізацією, а не журналом — невдалий запуск нічого не надсилає, і якраз ця тиша здіймає тривогу. Окремо щомісяця відбувається тренування з відновлення: воно дістає з репозиторію відомий файл і звіряє його, тож перевіряється саме відновлення, а не резервне копіювання. Парольна фраза лежить у файлі, який читають юніти, а не передається через змінні середовища, бо супервізор обробляє екранування в значеннях змінних, і фраза зі зворотною скісною рискою непомітно відрізнялася б від тієї, якою створено репозиторій. Після цього можливості відновлення перевірено й описано, а прогалини, що лишилися, названо в документі, а не залишено до того, як їх виявить інцидент. **Результат.** Компанія може втратити хост і повернути свої дані, і це твердження спирається на відновлення, виконане минулого місяця, а не на резервну копію, зроблену минулої ночі. Найцінніше, що дав аудит, — перелік того, що досі не охоплено: саме цього зелений звіт про резервне копіювання за самою своєю будовою не може сказати нікому. --- - Роль: Інженер з надійності (SRE) - Категорії: [Інфраструктура](https://engineer.company/uk/categories/infrastructure/), [Автоматизація та CI/CD](https://engineer.company/uk/categories/automation/), [Надійність і резервне копіювання](https://engineer.company/uk/categories/reliability/), [Linux та сервери](https://engineer.company/uk/categories/linux/), [Безпека](https://engineer.company/uk/categories/security/), [Документація](https://engineer.company/uk/categories/documentation/) - Послуги: [Infrastructure as Code](https://engineer.company/uk/services/infrastructure-as-code/), [Надійність та моніторинг (SRE)](https://engineer.company/uk/services/site-reliability/), [Резервне копіювання та відновлення](https://engineer.company/uk/services/backup-recovery/), [Системне адміністрування](https://engineer.company/uk/services/system-administration/)