Your NAS Backup Still Failed After the VPN Came Back

The VPN reconnects at 06:10, the dashboard shows the tunnel green, and the overnight backup still has no new recovery point. That is not a contradiction; it is two schedules that were never coordinated. A tunnel that recovers is a network event. A backup that completes is an application event with its own state machine, and an interrupted run may be suspended, cancelled, or queued behind something else entirely.

Plan the window around a completed recovery point rather than around the tunnel's indicator light.

Start from the recovery point, not the start time

Write the requirement as a deadline for an accepted version: a new recovery point that passes the task's own integrity check by a stated time. Then work backward through the expected duration, ordinary variation, and one interrupted attempt. A launch time is not a commitment; it is only the moment the scheduler tried. Put the deadline in the backup policy rather than in a chat message. A number that lives only in someone's memory is not a monitoring threshold.

Use the task's history for the duration estimate. Chunk processing, deduplication and index work are part of the run, so dividing changed bytes by a link speed underestimates the window in a way that looks like a network problem later.

What an interruption does to the job

Hyper Backup distinguishes work that can resume from work that cannot: the documented behaviour is that resumable tasks become suspended and non-resumable tasks become cancelled when the connection drops. Neither state is visible from the VPN client, and neither is repaired by reconnecting the tunnel. Read the task state and its recorded reason before assuming the next scheduled run will pick up where the old one stopped.

Manual suspension and a network interruption can follow different lifecycles. If an operator paused the task, reconnecting the network changes nothing at all.

The destination has its own requirements

A restored tunnel does not mount an encrypted shared folder, renew expired backup credentials, or finish maintenance on the destination. Those are separate readiness checks, and any one of them can turn a green tunnel into a failed job. Confirm the destination is reachable and writable before blaming the recovery schedule.

If the destination NAS itself rebooted, its services may still be starting when the backup task fires. A short readiness check is cheaper than a failed run and a retry.

Integrity checks compete for the same hours

An integrity check can consume the window without any network failure at all. DSM documents one active process per task, and a scheduled backup can wait behind that task's integrity check and then be skipped after a maximum wait of about three hours. Space the two schedules according to observed durations, and treat a skipped run as a scheduling finding rather than as evidence that the VPN failed again.

Enable notifications with a real delivery method, then assign someone to read them. A job that never started and a job that failed halfway may not produce the same alert.

Make the morning check about the copy

The morning question is whether a current, recoverable copy exists, not whether the tunnel is up. Check the age of the last accepted version against the deadline, then perform a safe restore test on a small file from that version. Preserve the previous good versions while you investigate anything that looks wrong.

Record the timestamps in one time zone, including the scheduler's zone, the destination's zone, and the zone of the person reading the dashboard. More than one of these investigations ends at a clock difference rather than a network fault, and the note is what makes that visible next time.