👋Известная истина гласит: люди делятся на два типа - те, кто ещё не делает бэкапы, и те, кто уже делает.
Но есть и третий, элитный подвид инженеров, познавших экзистенциальный ужас. Это те, кто регулярно тестирует разворачивание этих самых бэкапов.
Потому что самое главное в бэкапах - это не процесс их создания. Бэкап, который вы никогда не пробовали восстановить - это Бэкап Шрёдингера. Пока вы не попытались поднять из него упавший прод, данные в нём одновременно и существуют, и представляют собой битый gzip-архив весом в 1 килобайт.
Вы можете годами платить за бездонные S3-бакеты и любоваться зелеными галочками в CI/CD: «Backup completed successfully». Вы можете спать спокойно, чувствуя себя ответственным профессионалом.
А потом наступает пятница. Уставший мидл случайно путает контуры и делает DROP TABLE users; на проде. Вы с гордым видом, как спаситель человечества, идете расчехлять бэкап, и тут выясняется прекрасное:
👉Скрипт последние полгода дампил только структуру базы, без самих данных.
👉Дамп зашифрован, а ключ от него унес с собой девопс, который уволился со скандалом два года назад.
👉Бэкап абсолютно рабочий, весит 10 терабайт, но чтобы развернуть его и переиндексировать на текущем железе, вам понадобится трое суток. Бизнес в восторге.
Делать бэкапы - это полдела. Это просто складирование файлов. Настоящая работа начинается на этапе восстановления (Disaster Recovery).
1️⃣Бэкап не существует, пока из него не подняли систему. Точка. Если вы не пробовали развернуть данные на чистом тестовом контуре, считайте, что бэкапов у вас нет.
2️⃣Автоматизируйте процесс восстановления. Раз в неделю скрипт должен поднимать временную базу из дампа, прогонять SELECT 1 и базовые тесты целостности, а потом убивать её. И присылать вам алерт, если что-то пошло не так.
3️⃣ Выучите мантру RTO и RPO. Бизнесу плевать на ваши bash-скрипты. Ему важно знать RPO (Recovery Point Objective - за сколько часов мы потеряли данные?) и RTO (Recovery Time Objective - сколько часов мы будем лежать, пока админы потеют?). «Мы всё восстановим» - это не ответ. Ответ звучит так: «Мы поднимемся за 45 минут с потерей данных за последние 2 часа».
Бэкапы без регулярного тестирования разворачивания - это просто дорогой цифровой мусор, который успокаивает ваши нервы за деньги компании.
А теперь признавайтесь в комментариях: когда вы в последний раз пробовали развернуть свой прод из резервной копии? Только честно.
#заметкинаполях
🤡Токсичный (it) архитектор🤡
Но есть и третий, элитный подвид инженеров, познавших экзистенциальный ужас. Это те, кто регулярно тестирует разворачивание этих самых бэкапов.
Потому что самое главное в бэкапах - это не процесс их создания. Бэкап, который вы никогда не пробовали восстановить - это Бэкап Шрёдингера. Пока вы не попытались поднять из него упавший прод, данные в нём одновременно и существуют, и представляют собой битый gzip-архив весом в 1 килобайт.
Вы можете годами платить за бездонные S3-бакеты и любоваться зелеными галочками в CI/CD: «Backup completed successfully». Вы можете спать спокойно, чувствуя себя ответственным профессионалом.
А потом наступает пятница. Уставший мидл случайно путает контуры и делает DROP TABLE users; на проде. Вы с гордым видом, как спаситель человечества, идете расчехлять бэкап, и тут выясняется прекрасное:
👉Скрипт последние полгода дампил только структуру базы, без самих данных.
👉Дамп зашифрован, а ключ от него унес с собой девопс, который уволился со скандалом два года назад.
👉Бэкап абсолютно рабочий, весит 10 терабайт, но чтобы развернуть его и переиндексировать на текущем железе, вам понадобится трое суток. Бизнес в восторге.
Делать бэкапы - это полдела. Это просто складирование файлов. Настоящая работа начинается на этапе восстановления (Disaster Recovery).
1️⃣Бэкап не существует, пока из него не подняли систему. Точка. Если вы не пробовали развернуть данные на чистом тестовом контуре, считайте, что бэкапов у вас нет.
2️⃣Автоматизируйте процесс восстановления. Раз в неделю скрипт должен поднимать временную базу из дампа, прогонять SELECT 1 и базовые тесты целостности, а потом убивать её. И присылать вам алерт, если что-то пошло не так.
3️⃣ Выучите мантру RTO и RPO. Бизнесу плевать на ваши bash-скрипты. Ему важно знать RPO (Recovery Point Objective - за сколько часов мы потеряли данные?) и RTO (Recovery Time Objective - сколько часов мы будем лежать, пока админы потеют?). «Мы всё восстановим» - это не ответ. Ответ звучит так: «Мы поднимемся за 45 минут с потерей данных за последние 2 часа».
Бэкапы без регулярного тестирования разворачивания - это просто дорогой цифровой мусор, который успокаивает ваши нервы за деньги компании.
А теперь признавайтесь в комментариях: когда вы в последний раз пробовали развернуть свой прод из резервной копии? Только честно.
#заметкинаполях
🤡Токсичный (it) архитектор🤡