Restic eller Borg kan verka ha glömt ett arkiv när den konfigurerade sökvägen nu pekar på en tom katalog, ett annat filsystem eller ett flyttat arkiv.
Arkivdata kan fortfarande vara intakt på backupdisken, men jobbet kan öppna den tomma monteringskatalogen innan disken är tillgänglig, använda en ändrad containersökväg, läsa en föråldrad miljövariabel eller vägra ett Borg-arkiv vars ID visas på en ny plats. Kontrollera den monterade källan och arkivets identitet innan du initierar något. Om du kör ett initieringskommando mot fel tom sökväg kan du skapa ett andra arkiv och försvåra felsökningen av det ursprungliga felet.
Bekräfta vad som är monterat på den konfigurerade arkivsökvägen
Notera arkivsökvägen som används av det schemalagda jobbet och jämför sökvägen före och efter att backupdisken monteras. Samla in information om filsystemets källa, UUID, monteringspunkt och tillgängligt utrymme.
Linux-verktyget findmnt löser den aktiva monteringen bakom en målsökväg och är därför den rätta första kontrollen när en välbekant katalog i själva verket kan vara värdmaskinens omonterade mapp.
Om sökvägen tillhör rotfilsystemet i stället för backupdisken ska du stoppa backuptjänsten innan den skriver ett nytt arkiv eller en ny backupuppsättning i den tomma katalogen.
Verifiera den exakta platsen för Restic-arkivet
Jämför sökvägen som anges med -r, --repository-file eller RESTIC_REPOSITORY med den aktuella monteringspunkten. Kontrollera omslutande skript, NAS-fält, autentiseringsfiler och miljöerna för schemalagda uppgifter.
Restic definierar ett lokalt arkiv som en specifik katalog som innehåller konfiguration, data, index, nycklar, lås och ögonblicksbilder. När monteringspunkten ändras ändras därför platsen som kommandot försöker öppna.
Kör inte restic init bara för att den nya sökvägen rapporterar att inget arkiv finns. Leta först efter det ursprungliga arkivets konfigurations- och datakataloger på den monterade disken.
Hantera Borgs varning om ett flyttat arkiv medvetet
Notera Borg-arkivets URL, arkiv-ID, tidigare plats, nuvarande plats, cache-sökväg och säkerhetskatalog. Bekräfta att samma arkiv faktiskt har flyttats avsiktligt.
Borgs FAQ förklarar att programmet begär godkännande efter att ett arkiv har flyttats, eftersom samma arkiv-ID på en ny sökväg också kan tyda på ett osäkert utbyte.
Godkänn en flytt endast efter att du har jämfört arkiv-ID:t och lagringsinnehållet. Inaktivera inte varningen globalt när flera flyttbara arkiv kan anslutas via sökvägar som ändras.
Ersätt enhetsordningsbaserade sökvägar med beständig lagringsidentitet
Kontrollera om monteringskonfigurationen hänvisar till /dev/sdX, en duplicerad etikett, filsystems-UUID, partitions-UUID eller enhets-ID. Jämför alla roterande diskar för att hitta duplicerade identifierare.
ArchWiki noterar att UUID minskar risken för namnkonflikter jämfört med etiketter och kärntilldelade enhetsnamn som kan ändras beroende på upptäcktsordningen.
En stabil identifierare måste fortfarande kopplas till den avsedda fasta monteringskatalogen. UUID förhindrar att diskordningen skiftar, men uppdaterar inte ett backupjobb som fortfarande innehåller den tidigare sökvägen.
Kontrollera översättning av container- och bind-mount-sökvägar
För en containeriserad Restic-, Borg- eller backupadministration ska du jämföra värdmaskinens monteringspunkt med bind-mount-källan och arkivsökvägen inne i containern. Kontrollera den körande containern i stället för att endast granska den sparade compose-filen.
Docker dokumenterar att bind mounts är beroende av den exakta sökvägen på värdmaskinen. Om en disk flyttas från /mnt/backup-a till /media/backup-a kan containern därför fortfarande vara kopplad till en tom katalog.
Behåll den stabila maskinvarusökvägen på värdmaskinen och exponera en stabil containersökväg. Lägg inte värdspecifika sökvägar för flyttbara medier direkt i arkivkonfigurationen när en fast mappning är tillgänglig.
Se till att backuptjänsten väntar på monteringen
Jämför tidsstämplar för uppstart och tjänster. Bekräfta att monteringen slutfördes innan backupschemaläggaren, containern, arkivadministrationen eller underhållsuppgiften försökte komma åt arkivet.
Red Hats vägledning om beständiga monteringar rekommenderar att en fast montering definieras i fstab, som sedan kan kombineras med tjänsteberoenden och validering före start.
Startalternativet nofail kan vara lämpligt för en flyttbar backupdisk, men backuptjänsten måste ändå vägra starta när det nödvändiga filsystemet saknas.
Återanslut det befintliga arkivet innan du kör en backup
Stoppa schemaläggningar, montera det avsedda filsystemet på den fasta sökvägen, verifiera arkivstrukturen, öppna arkivet skrivskyddat eller lista ögonblicksbilder och genomför en mindre arkivkontroll innan du aktiverar skrivningar.
ZimaSpace-artikeln om stabila programsökvägar baserade på UUID beskriver den allmänna monteringskedjan. Den här artikeln fokuserar på arkividentitet och säker användning av backupverktyg efter att sökvägarna har ändrats.
Problemet är löst när samma arkiv-ID och ögonblicksbildshistorik öppnas på den avsedda sökvägen efter upprepade tester med omstarter och diskrotation, utan att något nytt arkiv har skapats i den tomma monteringskatalogen.
Vanliga frågor
Kan ett Restic-arkiv flyttas till en annan monteringspunkt?
Ja, förutsatt att hela arkivet flyttas intakt och att alla jobb nu hänvisar till den nya platsen. Restic identifierar arkivet via den sökväg eller backend som anges till kommandot.
Varför varnar Borg när arkivdata är oförändrad?
Borg registrerar arkivets identitet och tidigare plats som en säkerhetsåtgärd. När samma ID visas på en annan sökväg krävs ett medvetet godkännande.
Bör jag initiera ett arkiv på den nya sökvägen?
Nej, inte förrän du har bevisat att det gamla arkivet saknas. Om du initierar den tomma monteringspunkten skapas ett separat arkiv i stället för att det ursprungliga återansluts.
Support och tips
Mer att läsa

Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.

Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.

Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.

