The safe approach is to treat preserve the bundle, distinguish identity from image damage, recover files or continuity, and start new history only after verification as a sequence of observable gates, not a single command.
On a macOS Time Machine backup stored on an SMB NAS, the practical risk is a Mac cannot open, continue, or reliably browse an existing NAS Time Machine history. Record the current identity and recovery point, start with the least invasive discriminator, interpret pass and fail results before changing another variable, and stop when storage becomes unstable or the only recoverable copy would be exposed. The workflow below ends only after the original workload succeeds or the evidence reaches an escalation boundary.
Preserve the existing history and stop automatic writes
Turn off automatic Time Machine backups on the affected Mac and block other Macs from writing to the same bundle. Record the NAS share path, bundle name and size, modification time, quota, free space, Mac identity, and tmutil destinationinfo. If possible, snapshot or copy the bundle before repair attempts.
Network Time Machine history may live in a sparsebundle or backupbundle whose many band files form one disk image. An independent recovery account shows a read-only recovery path approach for extracting files without first forcing the old history back into normal automatic use.
Do not rename, compact, delete bands, or run read-write repair on the only copy. If the NAS reports I/O errors or the bundle changes while no backup should be running, stop and protect the storage layer before troubleshooting Time Machine.
Separate share access from backup identity
Mount the SMB share manually with the intended account and confirm the bundle is visible, writable only when appropriate, and within quota. Then compare whether Time Machine sees the same destination identity or proposes a new backup. A reachable folder does not prove that macOS associates it with the prior history.
Use the ZimaSpace test for whether Time Machine is continuing or recreating backup history. A new bundle, missing historical snapshots, or near-full transfer size indicates a new chain; normal incremental behavior and the expected destination identity support continuity.
Fix share advertising, credentials, quota, or identity before touching the bundle. If the old history can be browsed after restoring those conditions, perform a small restore and one controlled backup; if it still cannot mount, move to image-health diagnosis.
Open the backup image conservatively
Work from a NAS snapshot or copy whenever possible. Attach the image read-only first and inspect whether its volumes appear. For encrypted history, verify you have the password or recovery material before any change. Long verification time alone is not proof of corruption, so save the exact error rather than interrupting repeatedly.
A Netgear community walkthrough documents moving a Time Machine sparsebundle and making the Mac recognize the existing history on a new NAS. Use community steps only after matching your macOS version, NAS implementation, bundle format, and permissions; old recipes that edit bundle metadata can be unsafe on newer formats.
If read-only attachment succeeds, recover the highest-value files immediately to separate storage. If it fails, try supported Disk Utility or platform repair only on a protected copy. Repeated I/O errors, missing bands, or repair that wants destructive changes is an escalation point, not permission to keep experimenting on the original.
Choose continuity or a new history and validate it
Attempt inheritance or reassociation only when the old bundle mounts, the destination identity is understood, and the Macโs history can be matched confidently. Otherwise keep the old bundle as an offline recovery source and start a new history in a separate share or name so new backups cannot overwrite evidence.
Validate continuity by browsing several dates, restoring files from two periods, and completing two incremental cycles across a reboot. Validate a new chain by restoring from the new backup while confirming the preserved old image remains readable and quota separates the two histories.
Delete an abandoned history only after required files are recovered, the replacement history passes restore testing, and retention obligations are satisfied. Escalate when encryption material is missing, the NAS storage is unstable, or repair fails on a copy; those conditions are beyond a routine Time Machine reset.
Support & Tips
More to Read

Borg Backup Migration Guide for Moving a Repository to New Storage
Move a Borg repository as one consistent object: stop writers, preserve keys and identity, verify restores, then update clients while retaining the source.

Restic Repository Maintenance Workflow: Check, Prune, Compact, and Test Restore
Restic has no separate compact command: prune performs repacking. Protect locks and free space, recheck afterward, and finish with an isolated restore.

Snapshot Retention Review Checklist for a Home NAS
A useful retention review connects every snapshot tier to a restore need, owner, capacity budget, and replication boundary before deleting history.

