Резервне копіювання NAS усе одно не вдалося після повернення VPN

VPN перепідключається о 06:10, панель показує тунель зеленим, а нічна резервна копія досі не має нової точки відновлення. Це не суперечність; це два розклади, які ніколи не узгоджувалися. Тунель, що відновлюється, — це мережева подія. Резервна копія, що завершується, — це подія застосунку з власною машиною станів, і перерваний запуск може бути призупинений, скасований або поставлений у чергу за чимось зовсім іншим.

Плануйте вікно навколо завершеної точки відновлення, а не навколо індикаторної лампи тунелю.

Починайте з точки відновлення, а не з часу запуску

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

Використовуйте історію завдання для оцінки тривалості. Обробка блоків, дедуплікація та робота з індексом є частиною запуску, тому ділення змінених байтів на швидкість каналу занижує вікно так, що згодом це виглядає як мережева проблема.

Що переривання робить із завданням

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

Ручне призупинення та мережеве переривання можуть мати різні життєві цикли. Якщо оператор призупинив завдання, повторне підключення мережі не змінює геть нічого.

Призначення має власні вимоги

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

Якщо сам NAS призначення перезавантажився, його служби можуть ще запускатися, коли спрацьовує завдання резервного копіювання. Коротка перевірка готовності дешевша за невдалий запуск і повторну спробу.

Перевірки цілісності конкурують за ті самі години

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

Увімкніть сповіщення з реальним способом доставки, потім призначте когось їх читати. Завдання, яке так і не почалося, і завдання, яке зірвалося на півдорозі, можуть давати не однакове попередження.

Зробіть ранкову перевірку перевіркою копії

Ранкове питання — чи існує актуальна копія, яку можна відновити, а не чи працює тунель. Перевірте вік останньої прийнятої версії щодо дедлайну, потім виконайте безпечний тест відновлення на невеликому файлі з цієї версії. Зберігайте попередні добрі версії, поки досліджуєте все, що виглядає неправильно.

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