How to Move a USB Backup Repository to a New Mount Path Without Breaking Incremental History

Moving a USB backup repository to a new mount path is safe when the repository itself stays intact and the backup job is deliberately reconnected to it.

The dangerous mistake is treating the new path as a new destination and letting the backup application initialize an empty repository beside the old one. Before changing labels, mount rules, or directory layout, record the physical filesystem identity, repository root, repository ID where the tool exposes one, encryption material, job configuration, and last usable restore point. Then move or remount the existing repository as one unit and prove the application recognizes its prior history before the next write.

Record the Existing Repository Before Changing the Path

Save the current mount source, filesystem UUID or label, repository directory, job name, encryption key or password location, and the repository’s own identifier if the backup tool exposes one. List several recent snapshots or archives as a baseline.

Kopia separates repository creation from connecting to an existing repository, which is the first distinction to preserve during a mount-path move.

Do not start the relocation until you can identify the old history without relying only on the mount path. If the path is the only thing you recorded, a second USB disk mounted there later can look deceptively valid.

Move the Repository as One Complete Unit

Stop the backup job and any prune, compact, verify, or restore process before moving repository files. Copy or remount the complete repository root, including indexes, configuration, packs, locks, keys stored there, and tool-specific metadata.

Borg describes its repository as a structured transactional store with repository metadata beside backup data, so copying only visible archive-like files is not a safe relocation model.

Keep the original repository unchanged until the new path passes a read-only listing or check. Avoid opening both original and copied instances for normal writes when the tool considers them the same repository identity.

Change the Destination Path Without Initializing a New History

Update the existing job or repository connection to the new filesystem path. If the interface offers Create versus Connect, Import, Relink, or Use Existing, choose the existing-repository path and verify the destination before saving.

Duplicati maintainers explain that after moving an existing store you can edit the destination and continue when the job database is pointed at the relocated store.

If the application immediately offers to initialize an empty destination, cancel. That is evidence it has not recognized the old repository yet; initialization can create a second history and make later cleanup ambiguous.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Expect Some Tools to Notice Repository Relocation

A backup client can remember more than repository contents. Local caches may associate a repository identity with its previous location and ask for explicit approval when the same repository appears somewhere new.

A Duplicacy mount-path migration case centers on reassociate a moved repository, showing why a repository path change should be treated as a relink rather than a fresh initialization.

Approve relocation only after matching the repository identity, expected snapshots, encryption state, and USB filesystem. A warning on the wrong disk is a reason to stop, not proof that the software is being overly cautious.

Give the USB Filesystem a Stable Mount Identity

Once the repository is recognized, map the physical USB filesystem to a fixed administrator-owned path using an appropriate persistent identifier. Avoid tying scheduled backups to /dev/sdX discovery order or a desktop-session mount directory.

Linux tools can identify filesystems by stable label or UUID, which lets the same repository path survive ordinary device enumeration changes.

If you intentionally change a filesystem label, update the mount rule and test it before re-enabling backups. The backup application should keep seeing the same repository root even when the human-readable label changes.

Verify History Before the First Post-Move Write

Mount the USB disk at the new path, connect the existing repository, list prior snapshots, inspect the latest restore point, and restore one small file to a temporary directory. Only then run the first new backup.

A restic user example notes that a local repository can be renamed and pointed to again, reinforcing that repository history belongs to the repository contents rather than the spelling of one mount path.

The move is complete when old snapshots remain browsable, a test restore works, and the new backup appends to the same history. The related ZimaSpace article on USB mount paths changing after reboot is the upstream fix when the path change was unplanned rather than a controlled repository relocation.

Frequently Asked Questions

Does changing a USB volume label automatically break backup history?

Not necessarily. It becomes a problem when the mount rule or backup job uses that label as part of the destination identity and the repository is no longer found at the expected path.

Should I copy only the latest backup folder to the new path?

No for repository-based backup tools. Keep the complete repository structure together because indexes, catalogs, pack files, keys, and older restore points can be interdependent.

Can I keep the old and new repository copies online at the same time?

Keep the old copy as a rollback source, but avoid writing independently to two cloned instances that share one repository identity unless the backup tool explicitly supports that workflow.