Why Does Restic or Borg Report a Missing or Relocated Repository After a Mount-Point Change?
Restic or Borg can appear to forget a repository when the configured path now points to an empty directory, another filesystem, or a relocated repository identity.
The repository data may still be intact on the backup disk, but the job can open the bare mount directory before the disk arrives, use a changed container path, read an outdated environment variable, or refuse a Borg repository whose ID appears at a new location. Diagnose the mounted source and repository identity before initializing anything. Running an init command against the wrong empty path can create a second repository and obscure the original failure.
Confirm What Is Mounted at the Configured Repository Path
Record the repository path used by the scheduled job, then compare the path before and after the backup disk mounts. Capture the filesystem source, UUID, mountpoint, and available capacity.
The Linux findmnt utility resolves the active mount behind a target path, making it the correct first check when a familiar directory may actually be the unmounted host folder.
If the path belongs to the root filesystem instead of the backup disk, stop the backup service before it writes a new repository or backup set into that empty directory.
Verify the Exact Restic Repository Location
Compare the path passed with -r, --repository-file, or RESTIC_REPOSITORY against the current mountpoint. Check wrapper scripts, NAS fields, credentials files, and scheduled-task environments.
Restic defines a local repository as a specific directory containing its config, data, index, keys, locks, and snapshots, so changing the mountpoint changes the location the command attempts to open.
Do not run restic init merely because the new path reports that no repository exists. First locate the original repositoryโs config and data directories on the mounted disk.
Handle Borgโs Relocated-Repository Warning Deliberately
Record the Borg repository URL, repository ID, previous location, current location, cache path, and security directory. Confirm that the same repository was intentionally moved.
Borgโs FAQ explains that it asks for approval after repository relocation because seeing the same repository ID at a new path can also indicate an unsafe substitution.
Approve relocation only after comparing the repository ID and storage contents. Do not suppress the warning globally when several removable repositories may be connected under changing paths.
Replace Device-Order Paths With Persistent Storage Identity
Check whether the mount configuration references /dev/sdX, a duplicated label, filesystem UUID, partition UUID, or device ID. Compare all rotated disks for duplicate identifiers.
ArchWiki notes that UUIDs reduce naming collisions compared with labels and kernel-assigned device names that can change with discovery order.
A stable identifier must still map to the intended fixed mount directory. UUID prevents disk-order drift but does not update a backup job that still contains the former path.
Check Container and Bind-Mount Path Translation
For a containerized Restic, Borg, or backup UI, compare the host mountpoint with the bind-mount source and the repository path inside the container. Inspect the running container rather than only its saved compose file.
Docker documents that bind mounts depend on the exact host path, so moving a disk from /mnt/backup-a to /media/backup-a can leave the container mapped to an empty directory.
Keep the stable hardware path on the host and expose one stable container path. Do not store host-specific removable-media paths directly inside the repository configuration when a fixed mapping is available.
Make the Backup Service Wait for the Mount
Compare boot and service timestamps. Confirm that the mount completed before the backup scheduler, container, repository UI, or maintenance task attempted access.
Red Hatโs persistent-mount guidance recommends defining a fixed mount in fstab, which can then be paired with service dependencies and pre-start validation.
A nofail boot option may be appropriate for a removable backup disk, but the backup service must still refuse to start when the required filesystem is absent.
Reconnect the Existing Repository Before Running a Backup
Stop schedules, mount the intended filesystem at the fixed path, verify repository structure, open it read-only or list snapshots, and perform a small repository check before enabling writes.
The ZimaSpace article on stable UUID-based app paths covers the general mount chain; this article focuses on repository identity and backup-tool safety after the path changes.
The issue is resolved when the same repository ID and snapshot history open at the intended path after repeated reboot and disk-rotation tests, with no new repository created in the bare mount directory.
Frequently Asked Questions
Can a Restic repository be moved to another mountpoint?
Yes, provided the complete repository is moved intact and every job now references the new location. Restic identifies the repository at the path or backend supplied to the command.
Why does Borg warn when the repository data is unchanged?
Borg records repository identity and prior location as a security measure. The same ID appearing at another path requires deliberate approval.
Should I initialize a repository at the new path?
No, not until you have proven the old repository is absent. Initializing an empty mountpoint creates a separate repository rather than reconnecting the original one.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
