Waarom meldt Restic of Borg dat een repository ontbreekt of is verplaatst nadat het koppelpunt is gewijzigd?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Restic of Borg kan lijken te zijn vergeten waar een repository staat wanneer het geconfigureerde pad nu naar een lege map, een ander bestandssysteem of een verplaatste repository-identiteit verwijst.

De repositorygegevens kunnen nog steeds intact zijn op de back-upschijf, maar de taak kan de lege mountmap openen voordat de schijf beschikbaar is, een gewijzigd containerpad gebruiken, een verouderde omgevingsvariabele lezen of een Borg-repository weigeren waarvan de ID op een nieuwe locatie verschijnt. Controleer de aangekoppelde bron en de repository-identiteit voordat je iets initialiseert. Als je een init-opdracht uitvoert op het verkeerde lege pad, kan er een tweede repository worden aangemaakt en wordt de oorspronkelijke fout moeilijker te achterhalen.

Controleer wat er op het geconfigureerde repositorypad is aangekoppeld

Noteer het repositorypad dat door de geplande taak wordt gebruikt en vergelijk het pad vóór en nadat de back-upschijf wordt aangekoppeld. Leg de bron van het bestandssysteem, de UUID, het koppelpunt en de beschikbare capaciteit vast.

Het Linux-hulpprogramma findmnt bepaalt welke actieve mount achter een doelpad zit. Daarmee is het de juiste eerste controle wanneer een vertrouwde map in werkelijkheid de niet-aangekoppelde map op de host is.

Als het pad bij het rootbestandssysteem hoort in plaats van bij de back-upschijf, stop dan de back-upservice voordat deze een nieuwe repository of back-upset in die lege map schrijft.

Controleer de exacte locatie van de Restic-repository

Vergelijk het pad dat aan -r, --repository-file of RESTIC_REPOSITORY wordt doorgegeven met het huidige koppelpunt. Controleer wrapper-scripts, NAS-velden, referentiebestanden en omgevingen van geplande taken.

Restic definieert een lokale repository als een specifieke map met daarin de configuratie, gegevens, index, sleutels, vergrendelingen en snapshots. Als het koppelpunt verandert, verandert dus ook de locatie die de opdracht probeert te openen.

Voer niet zomaar restic init uit omdat het nieuwe pad meldt dat er geen repository bestaat. Zoek eerst de configuratie- en gegevensmappen van de oorspronkelijke repository op de aangekoppelde schijf.

Ga bewust om met de waarschuwing over een verplaatste Borg-repository

Noteer de Borg-repository-URL, repository-ID, vorige locatie, huidige locatie, cachepad en beveiligingsmap. Bevestig dat dezelfde repository opzettelijk is verplaatst.

In de FAQ van Borg staat dat het programma na het verplaatsen van een repository om goedkeuring vraagt, omdat dezelfde repository-ID op een nieuw pad ook kan wijzen op een onveilige vervanging.

Sta het verplaatsen alleen toe nadat je de repository-ID en de opslaginhoud hebt vergeleken. Onderdruk de waarschuwing niet globaal wanneer meerdere verwijderbare repositories onder wisselende paden kunnen worden aangesloten.

-15% OFF
Single board computer zimaboard2

Vervang paden op basis van apparaatvolgorde door een permanente opslagidentiteit

Controleer of de mountconfiguratie verwijst naar /dev/sdX, een dubbele labelnaam, een bestandssysteem-UUID, een partitie-UUID of een apparaat-ID. Vergelijk alle schijven die je afwisselend gebruikt op dubbele identificatiegegevens.

ArchWiki vermeldt dat UUID's naamconflicten beperken vergeleken met labels en door de kernel toegewezen apparaatnamen, die door de detectievolgorde kunnen veranderen.

Een stabiele identificatie moet nog steeds naar de bedoelde vaste map verwijzen. Een UUID voorkomt verschuiving door de schijfvolgorde, maar werkt een back-uptaak niet bij als die nog steeds het oude pad bevat.

Controleer de vertaling van container- en bind-mountpaden

Vergelijk bij een container met Restic, Borg of een back-upinterface het mountpunt op de host met de bron van de bind-mount en het repositorypad in de container. Controleer de actieve container en niet alleen het opgeslagen compose-bestand.

Docker documenteert dat bind-mounts afhankelijk zijn van het exacte hostpad. Als je een schijf van /mnt/backup-a naar /media/backup-a verplaatst, kan de container daardoor naar een lege map blijven verwijzen.

Houd het stabiele hardwarepad op de host aan en gebruik één stabiel containerpad. Sla hostspecifieke paden van verwijderbare media niet rechtstreeks op in de repositoryconfiguratie wanneer een vaste koppeling beschikbaar is.

Laat de back-upservice wachten op het koppelpunt

Vergelijk de tijdstippen van het opstarten en de services. Controleer of het koppelen is voltooid voordat de back-upplanner, container, repository-interface of onderhoudstaak toegang probeert te krijgen.

De richtlijnen van Red Hat voor permanente mounts adviseren een vaste mount in fstab, die vervolgens kan worden gecombineerd met serviceafhankelijkheden en controles vóór het starten.

De opstartoptie nofail kan geschikt zijn voor een verwijderbare back-upschijf, maar de back-upservice moet nog steeds weigeren te starten wanneer het vereiste bestandssysteem ontbreekt.

Maak opnieuw verbinding met de bestaande repository voordat je een back-up uitvoert

Stop geplande taken, koppel het bedoelde bestandssysteem op het vaste pad, controleer de repositorystructuur, open de repository alleen-lezen of geef de snapshots weer en voer een kleine repositorycontrole uit voordat je schrijfbewerkingen inschakelt.

Het ZimaSpace-artikel over stabiele app-paden op basis van UUID's behandelt de algemene mountketen; dit artikel richt zich op repository-identiteit en de veiligheid van back-uptools nadat paden zijn gewijzigd.

Het probleem is opgelost wanneer dezelfde repository-ID en snapshotgeschiedenis op het bedoelde pad openen na herhaalde tests met opnieuw opstarten en het wisselen van schijven, zonder dat er een nieuwe repository in de lege mountmap is aangemaakt.

Veelgestelde vragen

Kan een Restic-repository naar een ander koppelpunt worden verplaatst?

Ja, zolang de volledige repository intact wordt verplaatst en elke taak nu naar de nieuwe locatie verwijst. Restic identificeert de repository aan de hand van het pad of de backend die aan de opdracht wordt doorgegeven.

Waarom waarschuwt Borg wanneer de repositorygegevens ongewijzigd zijn?

Borg registreert de repository-identiteit en de vorige locatie als beveiligingsmaatregel. Wanneer dezelfde ID op een ander pad verschijnt, is daarvoor bewuste goedkeuring nodig.

Moet ik op het nieuwe pad een repository initialiseren?

Nee, niet voordat je hebt bewezen dat de oude repository ontbreekt. Door een lege mountmap te initialiseren, maak je een afzonderlijke repository aan in plaats van opnieuw verbinding te maken met de oorspronkelijke.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.