QNAP’s 2023 file-history settings example. Export needed run evidence before clearing history; confirm the equivalent controls in your installed HBS build.
Start an HBS3 warning investigation with the affected run and files. Record the job, time, source, destination and exact message. Repeating the job or changing several options can leave you with another status icon and no explanation of whether the files the business needs were protected.
This guide covers evidence collection and file-coverage diagnosis in QNAP Hybrid Backup Sync. Record the installed build, NAS operating system and destination type. The cited online guide is the HBS3 21.x edition; confirm the available report names and controls in your installed version. Use the actual message and file history to choose the next test.
Preserve the failed run before changing its settings
In the documented Jobs workflow, open the relevant job’s report and select the run that matches the complaint. The guide distinguishes run results, detailed affected-file downloads and event logs; it also provides log export. Capture those records before an update, job edit or a cleanup that could remove the useful history.[1]
Keep exported records in controlled support storage. They can reveal names of internal folders, users or business documents. An incident summary usually needs the failing operation, time and representative reason; it rarely needs the entire contents of the protected files.
| Evidence | Why it matters | Useful detail |
|---|---|---|
| Exact run | Separates this incident from an older failure | Job identity, start/end time and time zone |
| Affected-file record | Shows which part of coverage needs review | Representative path, recorded status and reason |
| Event log | Connects file outcomes to a failed operation | Relevant time, event and destination response |
| Job design | Establishes what should have been protected | Source/destination, filters, direction and scope |
| Change history | Narrows a formerly working configuration | Credential, share, mount, policy or version change |
Separate an intentional filter from an unexpected omission
QNAP documents per-run records for transferred, filtered and skipped files. Inspect the actual file record and its reason instead of assigning one meaning to every omission. A documented filter can be behaving as designed while still excluding something the business now requires.[2]
Illustrative example: a job excludes temporary files, and the report lists an intentionally excluded disposable file. That is a coverage decision to verify. If the same run unexpectedly misses the finance workbook, investigate its recorded reason and the job’s intended scope; the temporary-file rule does not explain the workbook without evidence.
For a sync job, check the configured direction and conflict action as well. The guide’s cloud one-way workflow can deliberately skip duplicate remote files under its chosen conflict policy. Keep that documented behavior separate from an inaccessible required source file.[6]
Create a short list of representative affected files. Group them by the actual reason, then choose one comparison that isolates the suspected difference. A large file-count total alone cannot show whether the important missed file is covered.
Check the recorded destination and identity
Compare the job’s recorded source and destination with what is currently available: share name, mounted storage, server or cloud location, and the intended account. Test a small approved operation through the same access path. A working browser sign-in or a similarly named destination does not establish that the job account can use the required location.
HBS3 storage spaces are reusable destination configurations. Before changing one, identify the jobs that depend on it. The documented editing workflow applies changes to the selected storage space; investigate the specific access or endpoint problem and coordinate the impact of that shared configuration.[3][4]
If the fault involves directory permissions, a disconnected destination, capacity or a changed identity, retain the actual error and involve the responsible owner. Preserve the repository while testing. Avoid broad permission grants or deletion of old versions as a substitute for understanding the failing operation.
Make one supported correction and compare the same work
The documented job-editing workflow lets an administrator review and save supported settings. Capture the previous configuration and make the correction that the evidence supports. Some options depend on job type, destination or release, so review the applicable help rather than assuming every field can be changed in place.[5]
For example, if a required file is unintentionally excluded, correct that coverage decision and run an approved comparison. If the destination account is denied, have its owner correct the intended access and test that path. Repeating the same run without changing the failed dependency supplies little additional evidence.
| Check | Useful result | Keep investigating when |
|---|---|---|
| Original affected sample | The required operation succeeds for the same file or representative case | Only unrelated files transfer |
| Intentional exclusions | The accepted excluded sample remains excluded | A broad filter change creates unwanted coverage |
| Destination and access | The intended job identity reaches the correct copy | A different account or location masks the problem |
| Result and logs | The new run’s records support the observed change | The message is hidden or ignored without explaining affected files |
| Recovery sample | The required version can be retrieved and used | File presence is the only acceptance evidence |
Use the HBS3 archive and file-recovery exercise to check the selected version and recovery-tool requirements. If the investigation reveals a missing retention or ownership decision, return to the HBS3 backup-job planning checklist.
Retain enough history to investigate the next occurrence
Review file-history retention deliberately. The HBS3 guide allows limits by age or number of runs and warns that clearing all history removes the ability to export previous run records. Export needed incident evidence before cleanup, then select retention that balances useful investigation history with storage use.[2]
Document the affected files, narrow correction, comparison result and unresolved action. Assign an owner for recurrence monitoring. Keep secrets and unnecessary file contents out of the support bundle.
ALLMSP QNAP Hybrid Backup Sync support covers monitoring, troubleshooting and backup-job administration. Request a review with the installed build, exact message, job type, destination and representative file-history evidence so the next action addresses the failed operation.
Use the backup-systems security review when the incident exposes gaps in recovery credentials, alert ownership or ransomware protection.
Frequently asked questions
What should I capture when an HBS3 backup job reports a warning?
Save the exact job and run time, message, source and destination, affected-file records, relevant event logs and recent configuration changes. Preserve that evidence before editing or clearing history.
Where does the cited HBS3 guide place run details and logs?
Open the job report from Jobs. The guide describes past run results, affected-file detail downloads and event logs with an export option. Match the labels to the installed build.
[1]Does every filtered or skipped file mean the same fault?
How should an unexpectedly missed business file be investigated?
Choose a representative affected file, compare its recorded reason with the approved job scope and test the suspected source, filter, access or destination difference. Retest the same case after a narrow correction.
Can a cloud one-way sync job deliberately skip a duplicate file?
Yes. The cited workflow includes a conflict policy that can skip duplicate remote files. Confirm the actual job type and policy before treating that result as a transfer failure.
[6]Why should other jobs be checked before editing a storage space?
Does a successful browser sign-in prove the HBS3 job account has access?
Test the intended account and required storage path through the job’s actual access method. A different user or interface can succeed while the job’s required operation remains denied.
Should the job be rerun repeatedly before reading its report?
Collect the report and choose a specific comparison first. A controlled rerun can confirm a supported correction; repeated attempts without examining the failed dependency do little to establish coverage.
Can old HBS3 file-history records be exported after clearing all history?
The cited guide warns that clearing all history removes the ability to export records from previous runs. Preserve required incident records before cleanup and review retention deliberately.
[2]What proves that an HBS3 warning investigation is complete?
The required affected case works, intentional exclusions remain correct, the new run records support the correction, and a representative required version can be retrieved and used. Record remaining exceptions and their owner.
