Представьте: вы прыгаете с парашютом, дергаете кольцо, а из ранца вместо купола вылетает записка: «404: Not Found». В ИТ-инфраструктуре бэкап — именно такой парашют. И проблема в том, что 90% инженеров уверены: раз ранец за спиной висит, значит, гравитация им не страшна. Мало кто проверяет его «укладку» (валидацию) и тренирует само приземление (DR). Чаще всего процесс строится либо на слепой вере в собственную память, либо на тотальном доверии древним скриптам, которые DevOps-археолог написал еще пять лет назад. В момент свободного падения времени на исправление конфигов этих скриптов уже не будет.

Поэтому ниже — краткая инструкция по «укладке парашюта»: быстро и без воды про классические ошибки и как их обойти.

1. Мануальный режим: бэкап «по памяти»

Суть проста: админ запускает скрипт или копирует данные, когда выдается свободная минутка. Ключевой показатель здесь — RPO (Recovery Point Objective). Это объем данных, который вы готовы потерять при сбое. Если вы делаете бэкап вручную раз в день, ваше RPO — 24 часа. Сегодня это катастрофически много.

  • Как правильно: Полная автоматизация. Бэкап должен быть фоновым процессом, который не зависит от того, выспался сегодня ответственный инженер или нет. Современные системы оркестрации позволяют делать инкрементальные копии каждые 15–30 минут, сводя потери к минимуму.

2. Бэкап Шрёдингера 

Наличие файла в хранилище еще не означает, что у вас есть бэкап. Пока вы не попробовали развернуть из него систему, копия находится в суперпозиции: она одновременно и работает, и нет. Процедура валидации часто игнорируется, потому что она «ест» ресурсы и время. В итоге в критический момент выясняется, что бэкап битый, а RPO увеличивается вдвое или втрое, так как приходится откатываться к позапрошлой (тоже не факт, что живой) копии.

  • Как правильно: Настройте автоматическую проверку контрольных сумм и, что еще важнее, периодическое тестовое восстановление. Если ваша система DR умеет сама «поднимать» виртуальные машины из копий в изолированной сети для проверки — вы на правильном пути.

3. Контрольный выстрел в продакшн

Допустим: произошел сбой, данные повреждены. Админ запускает восстановление из последнего бэкапа прямо поверх того, что осталось на дисках. В процессе выясняется, что бэкап тоже поврежден или содержит старую версию конфигурации. Перезаписывая оригинальные (пусть и «подбитые») данные, вы отрезаете себе путь к отступлению. Выжившие фрагменты данных на источнике окончательно уничтожаются неудачным восстановлением.

  • Как правильно: Всегда делайте снапшот перед восстановлением. Или восстанавливайтесь на новую площадку/в новый инстанс. Это позволит сравнить данные и, если нужно, собрать рабочий вариант из «кусочков» разных копий.

4. Игра в тетрис

Бэкапы имеют свойство расти. Рано или поздно наступает момент, когда очередная копия просто не влезает на диск. Часто это приводит к ошибкам: старые бэкапы удаляются вручную в спешке, чтобы освободить место для новых. В этой суете легко снести единственную рабочую полную копию, оставив только бесполезные инкременты.

  • Как правильно: Используйте политики хранения (Retention Policies) и автоматическую ротацию. Система должна сама знать, что «дедуплицировать», что перенести в «холодное» хранилище, а что удалить по истечении срока давности.

5. Восстановление через уничтожение

Некоторые админы, стремясь сэкономить место, сначала удаляют старую копию, а затем запускают создание новой. Это «окно уязвимости». Если в процессе создания нового бэкапа произойдет сбой, вы останетесь вообще без актуальных данных. RPO в этот момент стремится к бесконечности.

  • Как правильно: Правило «3-2-1». Минимум три копии данных, на двух разных носителях, одна из которых — удаленная (в облаке или другом ДЦ). И никогда не удаляйте старую точку восстановления, пока новая не верифицирована.

Человеческий фактор по-прежнему остается главной причиной провалов при восстановлении. Именно поэтому индустрия уходит в сторону DR, автоматизируя не только сохранение, но и оркестрацию восстановления всей инфраструктуры. О разнице между обычным бэкапом и DR, и почему первый часто бесполезен в энтерпрайзе, я уже писал здесь.

Если интересно посмотреть, как эти проблемы (валидация, масштабируемость и автоматизация) решаются в нынешних реалиях, заходите к нам на вебинар. Будем разбирать релиз 4.4.1 и обновленную дорожную карту Акуры.