Резервні копії, які справді відновлювали

Ситуація. Усе, що має компанія, — git‑репозиторії, база даних, сайт — працювало на одному хмарному інстансі, і вся можливість відновлення трималася на знімку від провайдера. Такий знімок добре мати, але погано на нього покладатися: він лежить у тому самому обліковому записі, що й машина, яку він захищає, ніхто в компанії його не шифрує, і з нього жодного разу ніхто не відновлювався.

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

Дія. Резервне копіювання запускає таймер systemd: спершу дамп бази даних, якщо вона є, потім зашифрований знімок із дедуплікацією в сховище іншого провайдера через SFTP, далі очищення за політикою зберігання і перевірка цілісності. Сигнал для dead man’s switch надсилається лише після успішного запуску, і саме ця відмінність робить його сигналізацією, а не журналом — невдалий запуск нічого не надсилає, і якраз ця тиша здіймає тривогу. Окремо щомісяця відбувається тренування з відновлення: воно дістає з репозиторію відомий файл і звіряє його, тож перевіряється саме відновлення, а не резервне копіювання. Парольна фраза лежить у файлі, який читають юніти, а не передається через змінні середовища, бо супервізор обробляє екранування в значеннях змінних, і фраза зі зворотною скісною рискою непомітно відрізнялася б від тієї, якою створено репозиторій. Після цього можливості відновлення перевірено й описано, а прогалини, що лишилися, названо в документі, а не залишено до того, як їх виявить інцидент.

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