Резервное копирование NAS всё равно не удалось после возврата VPN

VPN переподключается в 06:10, панель показывает туннель зелёным, а ночная резервная копия всё ещё не имеет новой точки восстановления. Это не противоречие; это два расписания, которые никогда не согласовывались. Туннель, который восстанавливается, — это сетевое событие. Резервная копия, которая завершается, — это событие приложения с собственной машиной состояний, и прерванный запуск может быть приостановлен, отменён или поставлен в очередь за чем-то совсем другим.

Планируйте окно вокруг завершённой точки восстановления, а не вокруг индикаторной лампы туннеля.

Начинайте с точки восстановления, а не со времени запуска

Запишите требование как срок для принятой версии: новая точка восстановления, которая проходит собственную проверку целостности задачи к заданному времени. Затем идите назад через ожидаемую длительность, обычную вариацию и одну прерванную попытку. Время запуска — не обязательство; это лишь момент, когда планировщик попытался. Поместите срок в политику резервного копирования, а не в сообщение чата. Число, живущее только в чьей-то памяти, не является порогом мониторинга.

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

Что делает прерывание с задачей

Hyper Backup различает работу, которую можно возобновить, и работу, которую нельзя: документированное поведение состоит в том, что возобновляемые задачи приостанавливаются, а невозобновляемые отменяются при обрыве соединения. Ни одно из состояний не видно из клиента VPN, и ни одно не исправляется переподключением туннеля. Прочитайте состояние задачи и записанную причину, прежде чем предполагать, что следующий запланированный запуск продолжит с того места, где остановился предыдущий.

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

У назначения свои требования

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

Если сам NAS назначения перезагрузился, его службы могут ещё запускаться, когда срабатывает задача резервного копирования. Короткая проверка готовности дешевле неудачного запуска и повторной попытки.

Проверки целостности конкурируют за одни и те же часы

Проверка целостности может израсходовать окно вообще без сетевого сбоя. DSM документирует один активный процесс на задачу, и запланированная резервная копия может ждать за проверкой целостности этой задачи, а затем быть пропущенной после максимального ожидания около трёх часов. Разнесите два расписания по наблюдаемым длительностям и рассматривайте пропущенный запуск как находку планирования, а не как доказательство того, что VPN снова отказал.

Включите уведомления с реальным способом доставки, затем назначьте кого-то их читать. Задача, которая так и не началась, и задача, которая провалилась на середине, могут давать не одно и то же оповещение.

Сделайте утреннюю проверку проверкой копии

Утренний вопрос — существует ли актуальная, восстановимая копия, а не работает ли туннель. Проверьте возраст последней принятой версии относительно срока, затем выполните безопасный тест восстановления на небольшом файле из этой версии. Сохраняйте предыдущие хорошие версии, пока исследуете всё, что выглядит неправильно.

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