Пока всё работает, резервные копии кажутся скучной формальностью. Проблема в том, что они становятся интересными ровно в тот момент, когда уже поздно что-то менять. Поэтому лучше относиться к ним не как к архиву, а как к процедуре восстановления.
Архив — ещё не копия
Самый распространённый самообман — держать «бэкап» на том же сервере или на том же диске, где живут основные данные. Если носитель умрёт, вместе с ним умрут и данные, и их копия. Формально архив есть. Практически — нет.
Копия должна существовать отдельно от источника. Настолько отдельно, чтобы проблема с сервером не стала проблемой с копией. Это не обязательно сложная схема: важнее, чтобы путь восстановления не зависел от той же инфраструктуры.
Проверять нужно восстановление
Резервная копия, которую ни разу не восстанавливали, — это надежда, а не гарантия. Архив может быть повреждён, неполон, зашифрован не тем ключом или просто лежать в формате, который текущая версия сервиса уже не понимает.
Поэтому разумно иногда проходить весь путь: взять копию, развернуть её в отдельном месте, убедиться, что данные читаются и сервис запускается. Это скучно. Это занимает время. И именно это отличает копию от ритуала.
Хорошая резервная копия — та, которую вы уже однажды успешно восстановили. Остальные — просто файлы с обнадёживающим названием.
Отдельно от сервера
Мне нравится принцип, который часто называют «3-2-1»: несколько копий, на разных носителях, одна — вне основной системы. Для домашнего проекта не нужно превращать это в корпоративную процедуру. Достаточно, чтобы копия не зависела от единственного диска и не лежала рядом с оригиналом.
Отдельный носитель, внешний диск или удалённое хранилище — выбор зависит от того, что именно защищаем. Главное, чтобы доступ к копии не был автоматически доступен тому, кто сломал основной сервер.
Секреты и конфиги
Данные — не только сообщения. Это ещё и конфигурация, ключи, настройки доступа. Если восстановить базу без нужных секретов, сервис может подняться, но не заработать. Если сохранить секреты слишком открыто, копия сама станет риском.
Поэтому копии стоит шифровать и хранить так, чтобы доступ к ним был отдельным и осознанным. Это не делает схему идеальной, но убирает самый очевидный сценарий: «всё лежит в одном месте и открывается одним ключом».
Короткий чек-лист
- копия лежит отдельно от основных данных;
- есть не одна копия, а хотя бы две;
- восстановление проверялось, а не только создание;
- секреты и конфиги тоже попадают в копию;
- доступ к копиям защищён отдельно;
- понятно, что делать в первые минуты после сбоя.
Скучная часть — лучшая
В хорошей инфраструктуре резервные копии почти незаметны. Они не должны быть героической операцией раз в год. Они должны быть обычной, проверенной процедурой, о которой вспоминают только тогда, когда она понадобилась.
Именно поэтому я не публикую пути, расписания и внутренние детали. Рассказ о принципах полезен. Точная карта хранения — уже нет.