Налаштувати автоматичне резервне копіювання та аварійне відновлення з

У нас невелика продакшн-платформа на кількох Linux-серверах та кілька баз MySQL під нею, й поточна ситуація з бекапами нас чесно лякає. Копії робляться руками час від часу, лежать на тій же машині, де живуть бойові дані, й відновлення з них ніхто ні разу по-справжньому не перевіряв. Потрібен спеціаліст, який вибудує нормальну автоматичну систему резервного копіювання та аварійного відновлення, щоб вийшов з ладу диск, помилковий DELETE чи шифрувальник перестали бути смертельною загрозою для бізнесу.

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

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

— Автоматичні бекапи серверів і баз MySQL за розкладом
— Зашифровані удалені або резервні копії з рівневим зберіганням
— Перевірка цілісності, моніторинг та тестові відновлення
— Письмовий runbook відновлення з цілями RPO та RTO