Why Does Time Machine Start a New Sparsebundle Instead of Continuing the Existing NAS Backup?

Time Machine starts a new sparsebundle when it no longer associates the current Mac and NAS destination with the existing backup history.

The old backup can remain visible as files while Time Machine treats it as belonging to another computer, another network volume, another share identity, or an incompatible destination configuration. Common triggers include macOS migration, logic-board or hostname changes, choosing “Create New Backup,” renaming the NAS or share, changing Time Machine advertising, switching users, or presenting a different volume UUID. Preserve both sparsebundles before trying to reconnect the history.

Confirm That a Second Sparsebundle Was Actually Created

List the Time Machine share before and after one backup attempt. Record sparsebundle names, creation times, logical sizes, owners, Mac name, NAS hostname, share name, and the selected destination.

Apple explains that a new Mac can either inherit an old backup history or create a new backup, making migration choice the first boundary when the new bundle appears after hardware replacement or Migration Assistant.

If only temporary files appear inside the existing sparsebundle, diagnose an interrupted backup instead. If a distinct bundle with a new machine-oriented name appears, continue with Mac and destination identity.

Compare the Current Mac Identity With the Existing History

Record the Mac’s current computer name, hardware UUID or platform identity available to Time Machine, migration history, logic-board changes, and whether the old Mac still uses the backup.

The Samba vfs_fruit module provides Time Machine SMB support and server identity behavior that affects how macOS sees the network destination.

Do not rename the new sparsebundle to match the old one while Time Machine or SMB has it open. A filename change cannot safely rewrite the backup’s internal identity.

Verify the NAS Still Presents the Same Share and Path

Compare the old and current NAS hostname, SMB address, share name, dataset path, Time Machine purpose, discovery name, and dedicated backup account.

TrueNAS requires a share to be configured with the Time Machine SMB purpose, so recreating a general SMB share at the same-looking path may still present a different destination capability.

If the old share was renamed or rebuilt, restore the original service identity when safe or deliberately migrate the old bundle into a newly validated destination before selecting it.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Check Whether the Time Machine Folder and User Changed

Confirm that the same shared folder is still selected for Time Machine and that the current account can read, create, rename, and delete a test file beside the bundle.

Synology’s setup guidance requires selecting the specific SMB shared folder for Time Machine.

A new user or folder can make the old bundle invisible or unwritable even when Finder shows another share with the same display name. Avoid mounting the same NAS simultaneously under several accounts during testing.

Verify SMB Time Machine Settings Were Not Recreated Differently

Compare NAS upgrades, SMB protocol settings, Time Machine flags, quotas, recycle-bin options, durable handles, and any migration from AFP to SMB.

QNAP documents a dedicated Time Machine backup-folder setting, showing that an ordinary writable share and a Time Machine-advertised share are not necessarily equivalent.

Reapply the supported Time Machine preset instead of manually copying one or two Samba parameters from an older configuration. Preserve the old bundle before service changes.

Check Whether the Advertised Backup Volume UUID Changed

Record Bonjour or service-discovery details and compare the current advertised volume identity with saved configuration or the prior server instance.

Netatalk documents that the advertised volume UUID disambiguates Time Machine volumes, explaining why the same path under a new server identity can be treated as another backup disk.

Do not invent or duplicate a UUID across two active destinations. Restore the prior identity only when the old server is retired and the storage history is known to be the same.

Reconnect the Existing History Without Deleting Either Bundle

Stop automatic backups, snapshot or copy the share metadata, disconnect other Macs, verify that the old sparsebundle mounts read-only, and confirm which Mac owns each history.

The ZimaSpace article on an unavailable Time Machine SMB backup covers general reachability and image-health failures; this article focuses on creation of a second history.

The issue is resolved when Time Machine appends a new backup to the intended existing history, no third bundle appears, and both current restore browsing and a test file recovery succeed.

Frequently Asked Questions

Can two sparsebundles be merged?

There is no simple supported file-level merge. Preserve both histories and reconnect the correct one, or retain the older bundle as a separate recovery source.

Should I delete the newly created sparsebundle?

Not until the old history is safely reconnected and tested. The new bundle may contain the only recent backup created after the identity change.

Will reselecting the same visible share always continue the old backup?

No. The share path can look identical while the Mac identity, account, advertised volume identity, or Time Machine service configuration differs.