Short answer: A Hyper Backup job is useful only when the business can open its repository, select the required version and restore data that users can actually use. Before starting, confirm the source version, recovery destination, encryption key, access rights and whether existing data will be overwritten. Test on non-production files or an isolated folder before an incident.
This is part 2 of the Hyper Backup setup guide. It focuses on evidence of recovery, not merely a green job status. See Synology solutions for business for the wider NAS, permission and separate-copy design.
Plan the restore test before opening the repository
Select an edited file, a deleted file and a folder with meaningful access permissions. Record the expected version, business owner and safe recovery path. For an active production workload, restore into an isolated location before considering any overwrite. Only authorized staff should test with sensitive data.
Verify that the destination repository is reachable with a recovery account, the available DSM and Hyper Backup versions are compatible, and there is enough free space. An encrypted .hbk repository needs its password or encryption key; successful backup logs cannot replace lost key custody. Agree RPO, the acceptable recovery point, and RTO, the target service restoration time, so the exercise has measurable criteria.
Restore a file or folder from a chosen version
Open the task in Hyper Backup and use Backup Explorer or the supported repository access tool. Authenticate, choose the timestamp on the version timeline, locate the test item and inspect its size and modification date. Labels and button placement vary across DSM releases and destination types; follow the vendor documentation for the installed release rather than an old screenshot.
Restore to a test path where possible. Open the result in its actual application and compare content with the expected version. Sign in with a representative user to check read and edit privileges. For folders, check nested structure, filenames, permissions and application links. Do not delete the current production copy merely because the restore operation completed.
Wider recovery: folders, packages and a failed NAS
For a large restore, pause related writes and agree scope with the data owner. Identify whether the repository sits on another NAS, external media or cloud, then select a version before the incident. Confirm that supported package data was included in the original task. Restoring files does not automatically restore system settings, accounts, licences or application consistency.
If the source appliance is unavailable, use a compatible recovery device and the vendor’s path to the external repository. Budget for transfer time, especially from cloud, and prioritize critical departments. After malware, isolate the source, protect the repository and scan restored data before reconnecting users. Re-enabling a sync client too soon may overwrite the clean version.
Record evidence and close the recovery gap
The test record should include date, operator and approver, repository and target, version timestamp, file sample, start/finish time, application-open result and post-restore permissions. On failure, retain logs and classify the cause: unreachable destination, missing key, missing version, corrupt content or RTO exceeded. Assign a fix and repeat the test; opening Backup Explorer alone is not proof of recovery.
Retest after changes to the NAS, destination account, retention policy or network path. Snapshots on supported volumes may provide rapid rollback, but a snapshot on the same appliance is not a separate backup. Use a documented backup and restore-test process for recurring evidence.
Frequently asked questions
Can I browse an .hbk repository like an ordinary folder?
No. The multiversion format is accessed using Hyper Backup or supported Explorer/Vault tools.
Can an encrypted backup be restored without its key?
It may not be possible. Store and hand over credentials outside the source NAS under controlled access, then periodically test repository access.
How often should restores be tested?
Set the interval from business criticality and system changes. Repeat after major destination, permission, retention or application changes.
Technical sources
Synology: Restore backup data; Synology Hyper Backup overview. Verify instructions for the installed DSM release and repository type.
