Why Does One Rotated USB Backup Disk Gain a Suffixed Mount Path After Reboot?
A rotated USB backup disk can gain a suffixed mount path when its preferred label-based directory is already occupied, duplicated, or assigned by another automounter.
Backup rotation often uses several similar disks, and administrators may clone filesystems or reuse the same volume label for convenience. After reboot, discovery order, desktop automounting, stale mount directories, duplicate labels, or a competing fstab entry can force one disk to appear under a path such as BACKUP_1 instead of BACKUP. The disk may be healthy while the backup job now targets the wrong directory. Verify identity before moving files or editing paths.
Identify the Filesystem Behind the Unexpected Path
Record the actual device, filesystem UUID, label, serial or by-id path, mount source, target, filesystem type, and options for every connected rotation disk.
The Linux findmnt command maps a target to its active source, preventing a misleading folder name from being mistaken for the intended backup disk.
If the suffixed directory belongs to the correct UUID, the problem is path assignment. If it belongs to another disk, stop the backup before it writes into the wrong rotation set.
Check for Duplicate Filesystem Labels or UUIDs
Compare UUID, label, PARTUUID, serial, and by-id names across every rotated disk, including disks currently offline if records are available.
ArchWiki explains that labels are easier to duplicate than UUIDs, making label-only automounting risky when several backup disks intentionally share a friendly name.
Cloning a filesystem can also clone its UUID. Assign a unique filesystem identity before relying on unattended rotation, and document which physical disk owns each ID.
Understand Why Automounters Add a Suffix
Check whether a desktop session, NAS service, UDisks helper, or removable-media manager mounted the disk before fstab or the backup service acted.
The Filesystem Hierarchy Standard allows digits to be appended to removable-media mount directories when more than one device needs a similar mount location.
The exact suffix policy varies by automounter, but the diagnostic principle is the same: the preferred path was unavailable or ambiguous when the device arrived.
Check Whether the Preferred Mount Directory Was Already Occupied
Inspect the expected directory before connecting the disk. Determine whether it contains another mount, stray files written while the disk was absent, a bind mount, or a stale process working directory.
Oracle’s removable-media guidance notes that media labels are used to name mount paths, which creates a collision when multiple media objects present the same label-derived pathname.
Do not delete an occupied directory until checking whether it contains backups accidentally written to the root filesystem. Move verified stray data through a controlled recovery process.
Define One Fixed fstab Mountpoint Per Rotation Disk
Choose a stable policy: either each physical disk receives its own fixed directory, or a rotation script mounts the currently selected UUID at one controlled backup path after verifying identity.
Red Hat documents persistent mounting through fstab with a UUID and fixed mountpoint, removing discovery order and friendly-label collisions from the unattended path.
Do not create several active fstab entries that compete for the same target directory. A rotation workflow should confirm that the old disk is unmounted before attaching the next one.
Make Backup Startup Depend on the Verified Mount
Check whether the scheduler starts before USB discovery and mounting complete. Add a preflight check for UUID, mountpoint, writable state, and expected marker file.
Debian’s systemd mount documentation explains that fstab entries become systemd mount dependencies, allowing backup services to wait for a specific mount rather than an arbitrary directory.
A directory-exists check is insufficient because the bare directory exists even when the disk is absent. Validate the mounted filesystem identity.
Test the Entire Rotation Across Reboot and Disk Swaps
For each disk, perform clean unmount, disconnect, reboot, reconnect, identity validation, disposable write, backup dry run, and read-back verification. Record the expected path and UUID.
The ZimaSpace article on UUID mounts and stable app paths covers the broader fixed-path design; this article focuses on collisions created by rotating several removable backup disks.
The issue is resolved when every rotation disk maps to its documented path after repeated reboot and swap tests, and the backup refuses to run when the expected UUID is missing or mounted elsewhere.
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.
