Synology Hyper Backup / Troubleshooting
Synology Hyper Backup Task Suspended After Interruption
Distinguish a resumable interruption from cancellation, identify the interruption context, and preserve the right backup-version expectations.
An interrupted task becomes suspended when it can be resumed; a non-resumable interruption becomes cancelled. First identify the actual state, then establish whether someone suspended it or an external interruption occurred.[1][2]
Applicability
- Products
- Synology DSM · Synology Hyper Backup
- Scope
- For Hyper Backup data-backup tasks on DSM 7 that explicitly show Suspended after an interruption. This is not a diagnosis of a running slow task, a cancelled task, or Restore Only. The workflow follows DSM 7 help, without extending its menu behavior to DSM Enterprise or entire-system backup.[1][2]
- Last verified
Symptoms
- The task displays Suspended and the interrupted backup version may be incomplete. A manually suspended scheduled task also stops generating scheduled versions.[2]
Quick diagnosis
Start with the recorded state and preserve the evidence before choosing a next action.
Read the task state before choosing an action
Record the task name, current state and interruption context. Do not treat Cancelled as another spelling of Suspended.[1]
Inspect Version List
Read version status and creation/completion times in Version List. Viewing this list does not require deleting a version.[2]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceDoes the task explicitly show Suspended?
Read the current state, not just the last interruption notification.[1]
Read the complete diagnostic tree without using the controls
- Does the task explicitly show Suspended?
Read the current state, not just the last interruption notification.[1]
- Yes, Suspended → What is known about how the task became Suspended?
- No, or I have not checked → Establish the correct task-state workflow
- What is known about how the task became Suspended?
Separate an operator action from a documented network or power interruption.[2]
- An operator suspended it → Do not wait for a disabled schedule
- An external network or power interruption is documented → Has the original interruption ended?
- Unknown → Investigate the unresolved interruption
- Has the original interruption ended?
For a scheduled task, automatic recovery depends on removal of the interruption.[2]
- Yes → Is this backup task scheduled?
- No, or not established → Investigate the unresolved interruption
- Is this backup task scheduled?
Synology documents automatic resumption after an external interruption for scheduled backup tasks; do not assume the same path for an unscheduled task.[2]
- Yes → Did the source change while suspended?
- No, or not established → Use the suspended-task management path
- Did the source change while suspended?
Distinguish later source changes from the interrupted version.[2]
- Yes, or uncertain → Plan protection for the later source changes
- No known changes → Observe the scheduled recovery path
- Establish the correct task-state workflow
Cancellation and suspension have different meanings. Re-read the task before selecting management actions.[1]
- Do not wait for a disabled schedule
Review the official suspended-task controls and source-change caveat before planning continuation.[2]
- Investigate the unresolved interruption
Record whether connectivity is stable now, whether the destination is reachable, and whether the same interruption recurs before a continuation decision. The Suspended state alone does not identify the cause.[1]
- Use the suspended-task management path
The documented scheduled-resumption path does not apply unless a schedule is established. Review the official suspended-task controls before planning continuation; this page does not initiate Resume or Discard.[2]
- Plan protection for the later source changes
Include a newly generated version; the resumed version is not evidence of later changes being backed up.[2]
- Observe the scheduled recovery path
For a scheduled task interrupted externally, compare subsequent version completion with the documented resumption behavior. No universal retry timer is asserted.[2]
Detailed diagnosis
1. Separate manual suspension from an external interruption
Establish whether an operator suspended the task. If not, compare its interruption with documented network or power events. An unknown interruption remains unknown; the state alone does not identify a failed component.[2][1]
2. Check whether the interruption is still present
For an externally interrupted scheduled task, establish whether the original network or power problem has ended. Scheduled resumption depends on removal of that factor; elapsed time alone is not evidence that it is resolved.[2]
3. Account for source changes
Record whether source files changed while the task was suspended. Synology distinguishes the resumed version from a newly generated version; do not use completion of the older version as proof that later changes are protected.[2]
Supported scenarios
Match each explanation to the observation before treating it as the diagnosis.
An operator suspended the scheduled task
Manual suspension disables its schedule.[2]
How to check: Confirm the operator action rather than assuming an automatic retry is pending.[2]
A resumable external interruption occurred
A resumable interruption leaves a suspended task rather than a cancelled one.[1]
How to check: Compare the recorded state with the interruption context and current connectivity.[1]
Next actions and procedure boundaries
Use the appropriate suspended-task management path
Consult Manage a suspended backup task in the Tasks source after the interruption is understood. Resume continues backup writes; this page does not initiate it or promise an undo of those writes. If source data changed, include a new backup version in the recovery plan.[2]
Resolve the interruption before treating resumption as a fix
If connectivity is still unstable, preserve the task evidence and investigate that condition first. Repeatedly changing task state does not establish a stable network or adequate transfer conditions.[1]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-05. Reachability and automated validation do not replace editorial verification of each claim.
- Settings
Synology · Tier A · accessed 2026-09-03 - Backup Tasks
Synology · Tier A · accessed 2026-09-03