Сайт может работать, хотя резервные копии уже несколько дней не обновляются. Чтобы обнаружить это до аварии, контролируйте не только запуск задания, но и появление нового завершённого комплекта в хранилище, а отсутствие результата проверяйте независимо от сервера, который делает бэкап.
Минимальная схема — срок ожидаемого завершения, подтверждение успешной записи и уведомление, если подтверждение не пришло. Сигнал «процесс запущен» не означает, что база и файлы скопированы; свежая копия, в свою очередь, ещё не доказывает возможность восстановления.
1. Найдите последний завершённый комплект
Откройте каталог копий или список снимков в системе резервирования. Для каждого важного объекта — базы, пользовательских файлов, конфигурации — найдите последний результат и сопоставьте его с журналом задания.
Проверьте:
- какой сайт и какие данные входят в комплект;
- к какой точке времени относятся данные;
- когда закончились создание и передача;
- есть ли идентификатор снимка или отметка завершения;
- доступен ли результат именно в целевом хранилище.
Не ориентируйтесь только на имя архива и дату изменения файла. Перенос старой копии может обновить отметку времени, а незавершённая загрузка — оставить файл с сегодняшней датой. Отсутствие новых байтов тоже не всегда ошибка: система с дедупликацией может создать новый снимок без заметного роста хранилища.
Для инкрементальной схемы учитывайте необходимые предыдущие копии и журналы. Один свежий фрагмент без доступной цепочки не образует самостоятельную точку восстановления.
2. Задайте срок, после которого нужен сигнал
Запишите расписание с часовым поясом, обычную длительность задания и допустимую задержку передачи. Контроль должен ожидать завершение к определённому сроку, а затем сообщать об отсутствии результата.
Условный пример: копирование начинается ежедневно в 02:00, обычно заканчивается до 02:40, ещё 20 минут отведено на задержку. В 03:00 отсутствие завершённого комплекта уже требует проверки. Эти значения — пример настройки, а не универсальная норма.
Отдельно задайте предельный возраст точки данных: время завершения загрузки и свежесть скопированной базы могут различаться. Порог предупреждения должен оставлять время на реакцию до превышения допустимой потери данных. Как выбрать этот предел, объясняет руководство по RPO, RTO и частоте бэкапов.
3. Подтверждайте результат, а не попытку
Скрипт должен отправлять подтверждение только после успешного создания копии и завершения предусмотренной передачи. Ошибку дампа нельзя маскировать успешной упаковкой пустого файла или последней командой, которая завершилась без ошибки.
Проверяйте код завершения каждой существенной операции и наличие ожидаемого результата. Учитывайте правила конкретной программы: например, документация restic описывает код 3 для backup как невозможность прочитать часть исходных данных. Такой исход нельзя считать полностью успешным только потому, что снимок появился.
Сохраните небольшой служебный отчёт: идентификатор задания и результата, время начала и конца, точку данных, статус и наличие обязательных компонентов. Сравнивайте состав и объём с обычным диапазоном, но разбирайте отклонения: маленькая копия после удаления ненужных файлов может быть корректной.
4. Проверяйте отсутствие подтверждения снаружи
Если проверка работает на том же сервере, его остановка выключит и копирование, и уведомление. Используйте отдельный контроллер расписания, который ожидает сигнал завершения — heartbeat — и замечает его отсутствие. Принцип такой проверки описан в документации Healthchecks.
Заведите отдельную проверку для каждого задания. При параллельных запусках сопоставляйте сигнал с конкретным результатом, чтобы запоздалое сообщение старого процесса не скрыло пропуск нового. Адрес приёма сигнала храните как секрет; не размещайте его в публичных инструкциях.
По возможности дополните сигнал независимым чтением метаданных целевого хранилища. Если копия есть, а подтверждение не дошло, проверяйте канал контроля; если подтверждение есть, а копии нет, проверяйте условия, при которых скрипт объявляет успех.
5. Разберите место остановки
Идите по цепочке, сохраняя время и идентификатор неудачного запуска:
- Задание не стартовало. Проверьте, включено ли расписание, его часовой пояс, пользователя запуска и работу планировщика.
- Стартовало, но не завершилось. Найдите последний этап в журнале; проверьте зависший процесс, блокировку, лимит времени и свободное место.
- Копия создана локально, но не передана. Проверьте доступность хранилища, квоту, срок действия доступа и ошибки передачи.
- Результат появился, но неполный. Сверьте состав: дамп, загрузки и нужная конфигурация должны соответствовать принятой схеме.
Перед повтором убедитесь, что прежний процесс завершён: одновременные копирования могут мешать друг другу. Сохраните последнюю известную пригодную копию и журналы, устраните причину, затем выполните один контролируемый запуск.
Как проверить, что контроль действительно работает
В согласованном тесте пропустите подтверждение одного запуска, сохранив само копирование. Убедитесь, что уведомление приходит после установленного срока, содержит понятное имя задания и попадает ответственному. Затем проверьте сообщение о восстановлении контроля после следующего успешного результата.
Такой тест подтверждает маршрут оповещения, но не проверяет содержимое копии. Для этого требуется отдельное пробное восстановление в изолированной среде.
Web-Puls помогает контролировать внешнюю доступность сайта; ответ главной страницы не подтверждает свежесть бэкапа. Для резервирования нужен отдельный контроль расписания и результата.
Если пропуски повторяются и причина неясна, отправьте заявку на профессиональную поддержку: укажите публичный адрес сайта, расписание с часовым поясом, время последнего успешного комплекта и обезличенную ошибку. Специалист оценит задачу и предложит формат работ; пароли и содержимое базы в заявку не включайте.