Waarom krijgt één gedraaide USB-back-upschijf na het opnieuw opstarten een mountpad met achtervoegsel?

Een gewisselde USB-back-upschijf kan een achtervoegsel aan het mountpad krijgen wanneer de voorkeursdirectory op basis van het label al in gebruik is, dubbel voorkomt of door een andere automounter is toegewezen.

Bij back-uprotatie worden vaak meerdere vergelijkbare schijven gebruikt, en beheerders kunnen bestandssystemen klonen of voor het gemak hetzelfde volumelabel opnieuw gebruiken. Na een herstart kunnen de detectievolgorde, desktopautomounting, verouderde mountdirectories, dubbele labels of een conflicterende fstab-vermelding ervoor zorgen dat een schijf verschijnt onder een pad zoals BACKUP_1 in plaats van BACKUP. De schijf kan gezond zijn, terwijl de back-uptaak nu naar de verkeerde directory verwijst. Controleer de identiteit voordat u bestanden verplaatst of paden aanpast.

Identificeer het bestandssysteem achter het onverwachte pad

Noteer voor elke aangesloten rotatieschijf het daadwerkelijke apparaat, de UUID van het bestandssysteem, het label, het serienummer of by-id-pad, de mountbron, het doel, het bestandssysteemtype en de opties.

Met de Linux-findmnt-opdracht koppelt u een doel aan de actieve bron, zodat u een misleidende mapnaam niet aanziet voor de bedoelde back-upschijf.

Als de directory met achtervoegsel bij de juiste UUID hoort, ligt het probleem bij de padtoewijzing. Als deze bij een andere schijf hoort, stop dan de back-up voordat er naar de verkeerde rotatieset wordt geschreven.

Controleer op dubbele bestandssysteemlabels of UUID's

Vergelijk de UUID, het label, de PARTUUID, het serienummer en de by-id-namen van alle rotatieschijven, inclusief schijven die momenteel offline zijn als daar gegevens over beschikbaar zijn.

ArchWiki legt uit dat labels gemakkelijker dubbel kunnen voorkomen dan UUID's, waardoor automounting op basis van alleen een label riskant is wanneer meerdere back-upschijven bewust dezelfde gebruiksvriendelijke naam delen.

Het klonen van een bestandssysteem kan ook de UUID klonen. Wijs een unieke bestandssysteemidentiteit toe voordat u op onbeheerde rotatie vertrouwt, en documenteer welke fysieke schijf bij elke ID hoort.

Begrijp waarom automounters een achtervoegsel toevoegen

Controleer of een desktopsessie, NAS-service, UDisks-helper of beheerder voor verwisselbare media de schijf heeft gemount voordat fstab of de back-upservice actief werd.

De Filesystem Hierarchy Standard staat toe dat cijfers worden toegevoegd aan mountdirectories voor verwisselbare media wanneer meerdere apparaten een vergelijkbare mountlocatie nodig hebben.

Het exacte beleid voor achtervoegsels verschilt per automounter, maar het diagnostische principe blijft hetzelfde: het voorkeurs­pad was niet beschikbaar of was onduidelijk toen het apparaat werd aangesloten.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer of de voorkeursmountdirectory al in gebruik was

Inspecteer de verwachte directory voordat u de schijf aansluit. Bepaal of deze een andere mount, losse bestanden die zijn geschreven toen de schijf niet aanwezig was, een bind mount of een verouderde werkdirectory van een proces bevat.

Oracle's richtlijnen voor verwisselbare media vermelden dat medialabels worden gebruikt om mountpaden te benoemen, wat een conflict veroorzaakt wanneer meerdere mediaobjecten dezelfde op een label gebaseerde padnaam gebruiken.

Verwijder een directory die in gebruik is niet voordat u hebt gecontroleerd of deze back-ups bevat die per ongeluk naar het rootbestandssysteem zijn geschreven. Verplaats bevestigde losse gegevens via een gecontroleerd herstelproces.

Definieer één vast fstab-mountpunt per rotatieschijf

Kies een stabiel beleid: elke fysieke schijf krijgt een eigen vaste directory, of een rotatiescript mount de momenteel geselecteerde UUID op één gecontroleerd back-uppad nadat de identiteit is geverifieerd.

Red Hat documenteert persistent mounten via fstab met een UUID en een vast mountpunt, zodat de detectievolgorde en botsingen tussen gebruiksvriendelijke labels geen rol meer spelen in het onbeheerde pad.

Maak niet meerdere actieve fstab-vermeldingen die met elkaar concurreren om dezelfde doel­directory. Een rotatieworkflow moet bevestigen dat de oude schijf is geünmount voordat de volgende wordt aangesloten.

Laat het starten van de back-up afhangen van de geverifieerde mount

Controleer of de planner start voordat USB-detectie en mounten zijn voltooid. Voeg een controle vooraf toe voor de UUID, het mountpunt, de schrijfbaarheid en een verwacht markerbestand.

De systemd-mountdocumentatie van Debian legt uit dat fstab-vermeldingen systemd-mountafhankelijkheden worden, zodat back-upservices kunnen wachten op een specifieke mount in plaats van op een willekeurige directory.

Alleen controleren of een directory bestaat is onvoldoende, omdat de lege directory ook bestaat wanneer de schijf ontbreekt. Valideer de identiteit van het gemounte bestandssysteem.

Test de volledige rotatie na herstarts en schijfwissels

Voer voor elke schijf een correcte unmount, loskoppeling, herstart, opnieuw aansluiten, identiteitsvalidatie, onschadelijke schrijftest, back-upsimulatie en controle achteraf uit. Noteer het verwachte pad en de UUID.

Het ZimaSpace-artikel over UUID-mounts en stabiele apppaden behandelt het bredere ontwerp met vaste paden; dit artikel richt zich op conflicten die ontstaan door meerdere verwisselbare back-upschijven te roteren.

Het probleem is opgelost wanneer elke rotatieschijf na herhaalde herstart- en wisseltests aan het gedocumenteerde pad wordt gekoppeld en de back-up niet start wanneer de verwachte UUID ontbreekt of elders is gemount.