Eine rotierte USB-Sicherungsfestplatte kann einen Mount-Pfad mit Suffix erhalten, wenn das bevorzugte verzeichnisbasierte Label bereits belegt, doppelt vorhanden oder einem anderen Automounter zugewiesen ist.
Bei der Sicherungsrotation werden häufig mehrere ähnliche Festplatten verwendet, und Administratoren klonen möglicherweise Dateisysteme oder verwenden aus praktischen Gründen dasselbe Volume-Label erneut. Nach einem Neustart können Erkennungsreihenfolge, Desktop-Automounting, veraltete Mount-Verzeichnisse, doppelte Labels oder ein konkurrierender fstab-Eintrag dazu führen, dass eine Festplatte unter einem Pfad wie BACKUP_1 statt unter BACKUP erscheint. Die Festplatte kann dabei vollkommen intakt sein, während der Sicherungsauftrag nun auf das falsche Verzeichnis zugreift. Überprüfen Sie die Identität, bevor Sie Dateien verschieben oder Pfade bearbeiten.
Dateisystem hinter dem unerwarteten Pfad identifizieren
Erfassen Sie für jede angeschlossene Rotationsfestplatte das tatsächliche Gerät, die UUID des Dateisystems, das Label, die Seriennummer oder den by-id-Pfad, die Mount-Quelle, das Ziel, den Dateisystemtyp und die Optionen.
Der Linux-Befehl findmnt ordnet ein Ziel seiner aktiven Quelle zu und verhindert so, dass ein irreführender Ordnername mit der vorgesehenen Sicherungsfestplatte verwechselt wird.
Wenn das Verzeichnis mit Suffix zur richtigen UUID gehört, liegt das Problem in der Pfadzuweisung. Gehört es zu einer anderen Festplatte, stoppen Sie die Sicherung, bevor sie in den falschen Rotationssatz schreibt.
Auf doppelte Dateisystem-Labels oder UUIDs prüfen
Vergleichen Sie UUID, Label, PARTUUID, Seriennummer und by-id-Namen aller Rotationsfestplatten, einschließlich derzeit nicht angeschlossener Festplatten, sofern entsprechende Aufzeichnungen vorhanden sind.
ArchWiki erklärt, dass Labels leichter doppelt vergeben werden können als UUIDs. Dadurch ist labelbasiertes Automounting riskant, wenn mehrere Sicherungsfestplatten absichtlich denselben verständlichen Namen verwenden.
Beim Klonen eines Dateisystems kann auch dessen UUID dupliziert werden. Vergeben Sie eine eindeutige Dateisystemkennung, bevor Sie sich auf eine unbeaufsichtigte Rotation verlassen, und dokumentieren Sie, welche physische Festplatte zu jeder Kennung gehört.
Verstehen, warum Automounter ein Suffix hinzufügen
Prüfen Sie, ob eine Desktop-Sitzung, ein NAS-Dienst, ein UDisks-Hilfsprogramm oder ein Wechseldatenträger-Manager die Festplatte eingebunden hat, bevor fstab oder der Sicherungsdienst aktiv wurden.
Der Filesystem Hierarchy Standard erlaubt, Ziffern an Mount-Verzeichnisse für Wechseldatenträger anzuhängen, wenn mehr als ein Gerät einen ähnlichen Mount-Ort benötigt.
Die genaue Suffix-Regel hängt vom Automounter ab, doch das Diagnoseprinzip bleibt gleich: Der bevorzugte Pfad war nicht verfügbar oder mehrdeutig, als das Gerät erkannt wurde.
Prüfen, ob das bevorzugte Mount-Verzeichnis bereits belegt war
Überprüfen Sie das erwartete Verzeichnis, bevor Sie die Festplatte anschließen. Stellen Sie fest, ob es einen anderen Mount, verwaiste Dateien, die bei nicht angeschlossener Festplatte geschrieben wurden, einen Bind-Mount oder ein veraltetes Arbeitsverzeichnis eines Prozesses enthält.
Oracle weist in seinen Richtlinien für Wechseldatenträger darauf hin, dass Medien-Labels zur Benennung von Mount-Pfaden verwendet werden. Dadurch entsteht eine Kollision, wenn mehrere Medienobjekte denselben aus dem Label abgeleiteten Pfad bereitstellen.
Löschen Sie ein belegtes Verzeichnis nicht, bevor Sie geprüft haben, ob es Sicherungen enthält, die versehentlich in das Root-Dateisystem geschrieben wurden. Verschieben Sie bestätigte verwaiste Daten über einen kontrollierten Wiederherstellungsprozess.
Einen festen fstab-Mountpoint pro Rotationsfestplatte definieren
Wählen Sie eine stabile Richtlinie: Entweder erhält jede physische Festplatte ihr eigenes festes Verzeichnis, oder ein Rotationsskript bindet die aktuell ausgewählte UUID nach einer Identitätsprüfung an einem kontrollierten Sicherungspfad ein.
Red Hat dokumentiert das persistente Einbinden über fstab mit einer UUID und einem festen Mountpoint. Dadurch werden Erkennungsreihenfolge und Kollisionen durch verständliche Labels aus dem unbeaufsichtigten Pfad entfernt.
Erstellen Sie nicht mehrere aktive fstab-Einträge, die um dasselbe Zielverzeichnis konkurrieren. Ein Rotationsworkflow sollte bestätigen, dass die alte Festplatte ausgehängt wurde, bevor die nächste angeschlossen wird.
Den Start der Sicherung von einem verifizierten Mount abhängig machen
Prüfen Sie, ob der Zeitplan startet, bevor die USB-Erkennung und das Einbinden abgeschlossen sind. Fügen Sie eine Vorabprüfung für UUID, Mountpoint, Schreibbarkeit und eine erwartete Markierungsdatei hinzu.
Die systemd-Dokumentation von Debian erklärt, dass fstab-Einträge zu systemd-Mount-Abhängigkeiten werden. Dadurch können Sicherungsdienste auf einen bestimmten Mount warten statt auf ein beliebiges Verzeichnis.
Eine Prüfung, ob das Verzeichnis existiert, reicht nicht aus, da das leere Verzeichnis auch dann vorhanden ist, wenn die Festplatte fehlt. Validieren Sie die Identität des eingebundenen Dateisystems.
Die gesamte Rotation nach Neustarts und Festplattenwechseln testen
Führen Sie für jede Festplatte das saubere Aushängen, Trennen, Neustarten, erneute Anschließen, Validieren der Identität, Schreiben von Testdaten, einen Probelauf der Sicherung und eine Überprüfung durch Rücklesen durch. Dokumentieren Sie den erwarteten Pfad und die UUID.
Der ZimaSpace-Artikel über UUID-Mounts und stabile App-Pfade behandelt das übergeordnete Design mit festen Pfaden. Dieser Artikel konzentriert sich auf Kollisionen, die durch die Rotation mehrerer entfernbarer Sicherungsfestplatten entstehen.
Das Problem ist behoben, wenn jede Rotationsfestplatte nach wiederholten Neustart- und Wechseltests ihrem dokumentierten Pfad zugeordnet wird und die Sicherung den Start verweigert, sobald die erwartete UUID fehlt oder an einem anderen Ort eingebunden ist.
Support & Tipps
Mehr zum Lesen

Warum stellt eine Docker-Volume-Wiederherstellung zwar die Dateiinhalte wieder her, lässt aber erweiterte Attribute weg?
Eine Diagnose zur Wiederherstellung von Volumes mit einer Bestandsaufnahme der erweiterten Attribute, Tar- und Rsync-Optionen, Namespaces, Zielunterstützung, Berechtigungen, Labels, App-Metadaten und Tests.

Warum behält ein laufender Container sein altes Speicherlimit bei, nachdem die Compose-Datei geändert wurde?
Eine Diagnose der Speicherbegrenzung mit Erläuterungen zu aktiven cgroups, Neustart gegenüber Neuerstellung, Compose-Feldern, harten und weichen Limits, übergeordneten Bereichen, Swap sowie Laufzeit-Heaps.

Warum macht ein Neustart des Reverse-Proxys jede Sitzung für eine selbst gehostete App ungültig?
Eine Diagnose von Sitzungsverlusten mit Abdeckung des Neustartumfangs, der Cookie-Zuständigkeit, der Geheimnisrotation, cachebasierten Sitzungen, Sticky-Routing, Authentifizierungs-Gateways und der Wiederherstellung.

