Статья

Как не потерять сайт: копии, мониторинг и план восстановления

Резервная копия, которую никогда не разворачивали, — это файл, а не копия. Что проверить, пока ничего не случилось.

3 минуты чтенияЦТБ Центр, Разработка и консалтинг

О резервных копиях вспоминают дважды: когда настраивают и когда они понадобились. Между этими моментами обычно проходят годы, за которые копии успевают сломаться незаметно.

Правило 3-2-1

Классическое и до сих пор рабочее: три копии данных, на двух разных носителях, одна — в другом месте.

Применительно к сайту: боевая база на сервере, копия на том же сервере (для быстрого восстановления), копия в другом хранилище — другой провайдер или другой дата-центр.

Смысл третьей копии не в паранойе. Она нужна для случая, когда проблема с самим сервером: отказ диска, блокировка аккаунта, ошибка провайдера, шифровальщик, добравшийся до подключённых дисков.

Что копировать

Три вещи, и забывают обычно вторую и третью.

  • База данных. Заявки, товары, статьи, пользователи.
  • Загруженные файлы. Фотографии, документы, вложения. Их нет в репозитории, и при потере восстановить неоткуда.
  • Конфигурация. Настройки сервера, переменные окружения, сертификаты, задания по расписанию. Формально восстановимо, но на это уйдут дни.

Код в копиях не нуждается — он в репозитории. Если репозиторий один и он на том же сервере, это отдельная проблема.

Частота и глубина

Отталкивайтесь от вопроса: потерю данных за какой период вы переживёте?

  • Сайт-визитка, меняется раз в месяц — копия раз в сутки, хранить месяц.
  • Корпоративный сайт с заявками — копия базы раз в час, файлов раз в сутки, хранить два месяца.
  • Интернет-магазин — копия базы каждые 15 минут, хранить полгода.

Глубина важна не меньше частоты. Если хранятся только копии за три дня, а порча данных обнаружилась через неделю, все копии уже содержат испорченные данные.

Главная проверка

Копия существует, только если из неё разворачивались. Всё остальное — предположение.

Заведите правило: раз в квартал развернуть последнюю копию на тестовый сервер и убедиться, что сайт запускается, данные на месте, файлы открываются.

Проверка регулярно обнаруживает: в копию не попала часть таблиц; файлы не копировались вовсе; архив бьётся при распаковке; копия делается, но перезаписывает саму себя и глубины нет; задание сломалось полгода назад, и никто не заметил.

Последнее — самое частое. Поэтому нужно уведомление о том, что копия не сделана, а не только об успехе: письма об успехе перестают читать через неделю.

Мониторинг

Копии спасают после аварии, мониторинг сообщает о ней вовремя. Минимальный набор:

  • Доступность. Проверка с внешнего сервиса раз в минуту. Обязательно снаружи: изнутри сети сайт может быть доступен, а из интернета нет.
  • Срок сертификата. Уведомление за две недели. Просроченный сертификат отпугивает посетителей сильнее, чем недоступность.
  • Место на диске. Заполненный диск роняет сайт, и происходит это внезапно.
  • Ошибки в журнале. Резкий рост числа ошибок — предвестник аварии.
  • Заявки. Самое ценное и самое редко отслеживаемое: если заявок не было дольше обычного, что-то сломалось. Форма может «отправляться» и ничего не сохранять — сайт при этом полностью доступен.

План восстановления

Документ на одну страницу, написанный заранее и доступный без сервера — потому что читать его придётся, когда сервер недоступен.

Что в нём: кому звонить и в каком порядке; где лежат копии и доступы к хранилищу; последовательность восстановления; у кого доступы к домену и хостингу; что сказать клиентам.

Отдельно — доступы. Классическая ситуация: сайт лежит, а домен оформлен на бывшего сотрудника. Проверьте прямо сейчас, на кого зарегистрирован домен и есть ли у вас доступ к почте, на которую он оформлен.

ИнфраструктураПоддержкаDevOps

Следующий шаг

Нужна такая же работа?

Резервные копии и мониторинг сайта — как не потерять данные | ЦТБ Центр