A volume that went read-only while the share still opens is the copy window. A capacity upgrade that rebuilds one larger disk at a time is that page, and it already says a job that reported success is not the backup. Several bays that emptied in the same minute are a controller, backplane, cable, or power path. A cloud icon in place of a file is a placeholder. File History that still says On, with an old Last Backup time, is don't wipe that backup drive. This page is the check before you delete the old pool, format the old drive, or reuse the disks.
A finished job is not a complete copy
The screen you remember is the last line: Success, Completed, green tick, "backup finished." The files you need are a list. Those two are not the same record. A job is allowed to decide that some files are not its problem, copy the rest, and finish. The ways that happens are ordinary.
Permissions. The account running the job cannot read a folder. The job logs an error on that folder and keeps going. If you only look at the banner, the folder is gone from the story.
Names and paths the destination will not store. A different filesystem rejects characters the source allowed, or the path is longer than that system will take. The file stays behind. The rest of the tree copies.
Locked files and placeholders. A file another program has open may not be readable for the whole job. A OneDrive or iCloud item with a cloud icon may be a name until the contents are local. Count it as copied only after the destination has the file, which is the placeholder page.
Filters. Hidden files, file types, sizes, dates, symbolic links, and "only updated files" are rules. A job that obeys them can finish cleanly and still omit what you thought was included.
Files that change mid-copy. A database, a mailbox, or a virtual disk that is open during the copy can land as a consistent-looking file that the application will not open. The byte count can match. The file is still the wrong bytes.
QNAP's Hybrid Backup Sync is a documented case of the banner and the file list coming apart. In the HBS 3 backup-job documentation, the option Skipped file limit "specifies a maximum number of files to skip. After exceeding this limit, real-time jobs enter a warning state and scheduled jobs are suspended." Below that limit, the page does not say the job fails. The same option is on sync jobs. QNAP's completed-with-warning FAQ is the next status up: a job completed with a warning may mean the destination filesystem does not support certain attributes, or that permissions, ownership, modification time, or extended attributes differ, and "some files may have been skipped or may not have been fully transferred." A warning is not a success. It is also not permission to delete the source.
Filters are the success case people miss. On the QNAP forum, a sync to Google Cloud Storage was described as having executed successfully, with no errors or warning, while the summary said the job had filtered more than 1,800 files. The person who posted it found the cause: hidden files and folders were set not to sync. Turning that off dropped the filter count to zero. Another reply on that thread said skipped files are normal and filtered files are the ones that need an explanation. QNAP's own job page lists the rules that produce those counts, including exclude hidden files and folders, exclude symbolic links, exclude by size, date, or file type, and "Only back up updated files," which includes only files with a different modification date or file size. A successful job plus a filter count means the rule ran. It does not mean every file on the source is on the destination.
QNAP also documents the name problem. The extended-attributes FAQ says a destination that does not support symbolic links, or a destination filesystem that rejects characters in the source names, leaves files skipped. The @Recycle symbolic links on a QNAP are the example they give for an NTFS destination. You find those files in the file history, then rename or move them, then run the job again. You do not delete the source because the job already ended.
The job finished. The old pool is still the copy that matters until you have opened files from somewhere else. If the source is already gone, or a disk is clicking, stop writing and have the set evaluated. Free evaluation, no data, no fee.
Compare the files, not the banner
On the source, use the folder you meant to copy. On the destination, use the folder you can open. Read the file count and the total size of those two folders. Do not read the job's "transferred" number and call it the same thing. An incremental run transfers only what changed. A compressed or deduplicated store is smaller because the tool stored it that way. HBS documents both compression and QuDedup as reducing backup size. The size of that container is not the size of your files.
A plain folder that is short on files, or short on bytes, is a hole until you can name every file that accounts for the difference. Recycle bins, snapshots, and a filter you turned on are real differences. "Close enough" is not. A count that matches can still hide one file swapped for another of the same size, and it can hide a database that was copied while it was open. Counts are the screen that tells you to keep looking. They are not the proof.
Read the log for skipped and warning lines
Open the record of that run, not the schedule that says the task is enabled. You are looking for skipped, filtered, warning, failed, and any line that names a path.
HBS 3. QNAP's file-history FAQ, for HBS 3 v14 and later, says every job records the files that were skipped or filtered. The path they document is Jobs, the report icon, Job History, then Export File History as CSV. The columns are Name, Size, Status, Reason, and Date & Time. Status is where a file is marked skipped or filtered. If that export icon is not on the row, download the job's detailed log from HBS and look for the file list. A QNAP Community thread from December 2025 describes the icon missing in HBS 3 version 26.2 and the per-file log inside the diagnostics zip. Either way, read the reason. A skip of a file already at the destination is a different line from a skip the destination refused.
rsync. The rsync man page says exit code 0 is success, 23 is "partial transfer due to error," and 24 is "partial transfer due to vanished source files." Exit 23 means some of the transfer did not happen. Exit 24 means files disappeared between the scan and the copy, which is the mid-copy change in its blunt form. A wrapper, a NAS task screen, or a script that only tells you the task ended is not that exit code. Read it. -vv is what the man page points at when a filter is hiding files: at that verbosity, rsync shows why each file was included or excluded.
Robocopy. Microsoft's robocopy page says /V produces verbose output and shows all skipped files, and /LOG writes that output to a file. The same page says an exit code of 8 or higher means at least one failure. Exit code 0 means nothing was copied, nothing failed, and nothing mismatched, because the files were already in the destination and the copy was skipped. That is a match by robocopy's own check. It is not a checksum. The default retry count on that page is 1,000,000, and the default wait is 30 seconds. A locked file can sit in those retries for a long time. A log that never reached the summary is not a finished copy. A summary with a failure, or an exit code of 8 or higher, means files did not copy. Do not treat either one as a green banner.
Open real files on the destination
Pick files you would notice if they were wrong. Open them from the destination, not from the source share and not from a thumbnail cache.
- A photo, opened in a viewer, not the preview icon.
- A video that plays past the start.
- A database, mailbox, or accounting file that opens and shows a record from the day of the copy.
- A project file that opens in the application that created it.
- At least one large file. The small files at the top of the list are the ones a job copies first.
A zero-byte file with the right name is not the file. A file that opens on the source and will not open on the destination is a failed copy, including the case where the count matched. If you are migrating a PC folder that is OneDrive or iCloud, confirm you did not copy placeholders. That check is the cloud page.
Use the verify option that tool actually has
These checks compare copies that already exist. They are not a second migration, and they are not a reason to delete anything. Each one has a limit. Read the limit before you trust the result.
rsync, checksum, dry run. Without --checksum, the man page says rsync uses a quick check of size and modification time. With --checksum, it compares a 128-bit checksum for each file that has a matching size, and it selects a file whose size or checksum differs. That option reads the file data on both sides. The man page says so, and it says the read is slow. --dry-run makes no changes. The man page recommends combining it with --itemize-changes or verbose output so you can see what a real run would do.
A check of a copy you already made looks like this. The trailing slashes mean the contents of the folder. --dry-run is the part that keeps it from writing. Leave it in. Do not add --delete or --remove-source-files.
rsync -a --checksum --dry-run --itemize-changes /source/ /dest/
Lines in the itemize list are files rsync would still transfer. Exit 23 or 24 means the run was partial. An empty list and exit 0 means rsync found nothing to send among the files it included. Files excluded by a rule are not in that list. -vv shows those decisions. The man page also says rsync always checks a whole-file checksum of each file it actually transferred, and that this is not the same as the --checksum question of whether a file needs updating. Neither check proves that a database which was open during the original copy is internally consistent. The bytes can match a torn copy. Opening the database is the test for that.
Do not point --checksum at a drive that is already failing. It is a full read of both sides. A disk that is clicking, or a volume you are copying because it just went read-only, may not survive another pass over every file. Spot-check the destination and leave the source alone.
Robocopy, list only. Microsoft says /L lists files and does not copy, delete, or time-stamp them. A list-only pass against a copy you already made:
robocopy "D:\source" "E:\copy" /L /E /V /FP /BYTES /LOG:prove-the-copy.txt
/L is the part that keeps it from writing. Leave it in. Do not add /MIR, /PURGE, or /MOV. Read the log. Files that would still be copied are files the destination does not already match. /V shows the skipped files. An exit code of 8 or higher is a failure. An exit code of 0 means robocopy would skip the copy. That is still not a byte-for-byte hash. Use it to see the holes. Use an open file, or a hash of the specific files you care about, for the contents.
Hyper Backup integrity check. Synology's integrity-check article describes two stages, a backup data check and an index structure check, and says the data check looks for alterations and for drives with bad sectors. The index is checked every time. Check data is the optional box. On the settings page, a time limit of 0 minutes means no time limit, so that run checks all backup data. Any other limit means the log records a fraction this time and later runs continue. "No error was found" after a partial pass is the partial pass. If the check finds corrupted backup data, Synology says the task becomes Restore Only so more data is not written into that backup. Do not delete the source and start a fresh task over a backup that just failed this check. The check is of the backup Hyper Backup stored. A folder the task never included is not in it.
HBS data integrity check. The same backup-job page has a content check. QNAP says a content check may download all files temporarily for comparison, and that some cloud providers charge for that download. After you enable it once, HBS keeps recording MD5 hashes even if you turn it off later. Quick checks and content checks are not available on every job type. The page says NAS-to-NAS jobs with QuDedup disabled are one of the gaps. A content check hashes what the job stored. It does not put back a file the filter excluded. Run it when the job supports it, read the log, and still read the skipped and filtered CSV.
--dry-run and /L off, or add a mirror or a delete flag, and it is a write.Leave the old pool where it is
The copy that counts is on a different device, and you have opened files from it. Another folder in the same pool is the same disks. A USB drive plugged into the NAS you are about to retire is one power supply and one backplane away from the box that just made you nervous. The new pool you plan to build with these disks does not exist yet. You cannot delete the old one to create it and still have the old one.
HBS has a policy, "Delete source files after transmission," and the documentation limits it to one-time backup jobs. The warning on that page: if the data is lost or removed from the destination, it cannot be restored. Leave that policy off until the destination has been proved, and leave it off if you are not sure the file history was clean. rsync's --remove-source-files is the same class of option. It does not belong on the dry run, and it does not belong on the job that has not been checked.
HBS can also "Do not take a snapshot," which the same page defines as reading data directly from the disk instead of from a snapshot. That is the setting where files can change under the job. If the copy was made that way, or made from a live database with no snapshot, the spot-check is not optional. A matching file count will not show a torn database.
If the reason you copied was a capacity upgrade, this check is the gate on the upgrade page. That rebuild reads the old drives for a long time. It is a bad moment to discover the backup skipped a directory. If the reason you copied was a volume that went read-only, you already spent one pass on a volume that refused a write. Prove what landed, and do not start a repair, a scrub, or a disk swap because the copy job "finished."
If the old pool is already gone, stop writing
Deleted, removed, reinitialized, formatted, or a new volume created on the same disks: the copy you were going to prove is now the only copy, and the disks you wiped may still hold the old one in the sectors nothing has overwritten. Every new file, every format, every "repair," and every hour the NAS stays up and writes logs uses those sectors.
Stop. Do not create the replacement pool. Do not click Recover on a QNAP volume that is Not Active. Do not click Repair on a Synology volume that says Crashed. Do not delete a Storage Spaces pool that has gone Offline or Failed. Do not format an Unraid disk the WebGUI calls unmountable, and do not destroy a TrueNAS pool to recreate it. Do not accept Initialize Disk. If a member is clicking, power the unit off. Photograph the screen if you can do it without accepting a button. Label the bay each disk came from.
Then call the lab. Tell the technician on your case the banner the job showed, whether you still have the log, and what was clicked after the pool disappeared. We would rather have the log and the untouched disks than a screenshot of a new volume.
How a lab handles it
We do not finish the migration on the original disks. We do not recreate the pool, reinitialize, or format to see if the share comes back. We do not run the backup job again against disks that have already been reused.
Each member is imaged write-blocked, as far as it will read, and the work happens on the copies. A pool that was deleted and not yet overwritten is a filesystem problem on those images. A disk that was failing during the copy is a read problem first. The tools named on this site image the drives. They do not make a skipped folder reappear inside a backup that never stored it, and they do not make a marginal platter healthier by reading it harder.
The public case log has no job that arrived as a migration whose backup said success and whose old pool was then deleted. We will not invent one. The published case that shows a later write on a disk that still held data is DDR-2026-0014: two NVMe SSDs in an enclosure, striped as one APFS volume. One member had been initialized in Windows, which wrote a new partition table. The notes on that case say the Windows initialization was harmless only by luck of where it wrote. It is not a NAS migration. It is why "I'll just format and start the copy again" is a write. DDR-2026-0003 is a Synology RAID 5 that was already offline, imaged as a set, and reconstructed from the images, with nothing rebuilt in the NAS. Use it for what imaging looks like after the volume is gone. Do not use it as a prediction. We don't advertise a success rate.
If a disk has to be shipped, pack it like any other failed drive and keep the bay label on it. For the work itself, see RAID data recovery.
Prove the copy FAQ
The job says Success, or Completed. Can I delete the old pool?
HBS shows skipped files next to a normal result. Are those files missing?
The file counts and the total size match. Is that the proof?
Does a Hyper Backup integrity check, an HBS content check, or rsync --checksum replace opening the files?
--checksum decides whether a same-size file needs a transfer. None of those put a photo, a mailbox, or a project file on screen. They also do not add a folder the job's filter never selected. Use the check the tool has. Then open files from the destination.The copy is another folder on the same NAS, a USB disk plugged into it, or the disks I am about to reuse. Does that count?
I already deleted the pool, formatted the drive, or initialized it. What do I do?
Is this the read-only copy window, or the capacity-upgrade page?
Is there a case in the public log of a pool deleted after a successful backup?
A job that finished is not a copy you have proved. If the old pool is still there, leave it until you have opened files from the destination. If it is already gone, stop writing to those disks. Start with a free evaluation.
Request free evaluation →Free evaluation · No data, no fee · Talk directly with a technician.