# Побудувала зашифровані резервні копії поза хостом на restic із обрізанням за терміном зберігання, перевіркою цілісності та щомісячним автоматизованим навчальним відновленням, а тоді проаудитувала позицію відновлення й записала прогалини, замість лишати їх на знаходження під час інциденту. вересень 2026 **Ситуація.** Усе, що зберігає компанія — git‑репозиторії, база даних, сайт, — стояло на одному хмарному примірнику, чий провайдерський знімок був усією позицією відновлення. Провайдерський знімок — добра річ, щоб її мати, і погана, щоб на неї покладатися: він лежить у тому самому обліковому записі, що й машина, яку він захищає, він не зашифрований тут нікому відомим ключем, і ніхто ніколи з нього не відновлювався. **Завдання.** Резервні копії мали бути зашифрованими, поза хостом, підрізаними за політикою зберігання і — та частина, яку зазвичай пропускають — справді відновлюваними, за розкладом, без того, щоб хтось про це пам'ятав. **Дія.** Резервне копіювання виконується за таймером systemd: дамп бази даних, де така існує, потім зашифрований знімок із усуненням дублікатів до сховища в іншого провайдера через SFTP, потім підрізання за політикою зберігання, потім перевірка цілісності. Перемикач мертвої руки пінгується лише в разі успіху, і саме ця відмінність робить його тривогою, а не журналом — невдалий прогін не каже нічого, а сказати нічого і є тим, що здіймає тривогу. Окремо щомісяця виконується навчання з відновлення: воно витягує відомий файл із репозиторію та порівнює його, тож перевіряється саме відновлення, а не резервне копіювання. Парольну фразу записано у файл, який читають модулі, а не передано через середовище, бо наглядач обробляє екранування у значеннях середовища, і парольна фраза, що містить зворотну похилу риску, мовчки відрізнялася б від тієї, що створила репозиторій. Згодом позицію відновлення було перевірено й описано, а прогалини, що лишилися, названо в документі, а не залишено на виявлення під час інциденту. **Результат.** Компанія може втратити хост і повернути свої дані, і це речення спирається на відновлення, що відбулося минулого місяця, а не на резервну копію, зроблену минулої ночі. Найціннішим виходом перевірки був перелік того, що досі не покрито, — саме та частина, про яку зелений звіт про резервне копіювання структурно не здатен нікому сказати. --- - Роль: Інженер з надійності систем - Категорії: [Інфраструктура](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/)