Migratiegids voor Borg Backup: een repository naar nieuwe opslag verplaatsen

De veilige aanpak is om schrijvers te pauzeren, met een voor de versie geschikte methode te kopiëren of over te zetten, de bestemming te verifiëren en de omschakeling met terugval als een reeks waarneembare controlepunten te behandelen, niet als één opdracht.

Bij een BorgBackup-repository op lokale opslag, een NAS of via SSH toegankelijke opslag is het praktische risico dat je een Borg-repository moet verplaatsen zonder een gesplitste of stilletjes onvolledige kopie te maken. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende controle, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload slaagt of het bewijsmateriaal een escalatiegrens bereikt.

Leg het repositorycontract vast voordat je kopieert

Sla de Borg-versie, repository-URL, repository-ID, versleutelingsmodus, sleutellocatie, procedure voor wachtwoordherstel, archieflijst, grootte, vrije ruimte, instellingen voor alleen toevoegen en elke client of automatiseringstaak die kan schrijven op. De repository kan niet alleen vanuit een lokale cache worden hersteld en voor versleutelde repositories kan sleutelmateriaal nodig zijn dat buiten de bestemming is opgeslagen.

Het ZimaSpace-artikel over een handleiding voor herstel na verlies van de Borg-cache maakt onderscheid tussen opnieuw op te bouwen cachestatus en ontbrekende sleutels of beschadiging van de repository. Voer die controle vóór de migratie uit, zodat een sleutelprobleem niet pas wordt ontdekt nadat de oude opslag is verdwenen.

Kies of dit een byte-voor-byteverplaatsing van dezelfde repository is of een overdracht naar een nieuw geïnitialiseerde repository. De Borg-versie en -indeling bepalen welke methoden beschikbaar zijn; combineer geen opdrachtvoorbeelden van Borg 1 en Borg 2 en ga er niet vanuit dat de repository-identiteit moet veranderen.

Pauzeer schrijvers en maak een consistent bronpunt

Schakel timers, cron-taken, containers en externe clients uit en controleer vervolgens of er geen Borg-proces of repositoryvergrendeling actief is. Voer borg list en een passende borg check uit voordat je kopieert. Als de bron de controle niet doorstaat, bewaar deze dan en onderzoek die toestand in plaats van onzekerheid naar de bestemming te klonen.

Een discussie op Super User wijst op het risico van een live repository kopiëren met rsync terwijl een gededupliceerde Borg-repository verandert. De veilige regel is om een gepauzeerde repository te kopiëren, of een bestandssysteemsnapshot te gebruiken die is gemaakt nadat alle Borg-schrijvers zijn gestopt, zodat indexen, segmenten, nonce-status en gegevens bij één moment horen.

Houd back-upschema's uitgeschakeld totdat de validatie van de bestemming is voltooid. Als de downtime te lang is, maak dan een eerste kopie terwijl de repository inactief is, stop de schrijvers en voer vervolgens een laatste synchronisatie uit; laat de bron en bestemming tijdens de omschakeling nooit onafhankelijke back-ups accepteren.

Kopieer met de methode die je Borg-versie ondersteunt

Bewaar bij een verplaatsing van dezelfde repository alle bestanden, machtigingen, gedrag van sparse bestanden en eigenaarschap met een geschikte lokale of externe kopieertool en controleer het foutenlogboek. Kopieer de repositoryroot als geheel, niet geselecteerde archieven of ogenschijnlijk grote gegevensmappen. Laat de bron na de laatste synchronisatie ongemoeid.

Gebruik voor een nieuwe repository of een migratie van de indeling de overdrachtsmogelijkheid alleen wanneer deze wordt ondersteund door de geïnstalleerde Borg-versies en het versleutelingsplan. Een antwoord op Server Fault beschrijft Borg-repositoryoverdracht als de repository-naar-repositoryrichting die bij Borg 2 hoort; deze is niet uitwisselbaar met een bestandssysteemkopie van Borg 1.

Stel de bestemming na het kopiëren eerst alleen-lezen beschikbaar aan clients. Als de repository-ID, sleuteltoegang, machtigingen of indeling onverwacht zijn, stop dan en corrigeer de bestemming; initialiseer niet over gekopieerde gegevens heen en voer geen reparatie uit om herkenning af te dwingen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifieer archieven, schakel clients om en behoud terugval

Voer op de bestemming Borg list, info en de passende controles van repository en archief uit. Pak canarybestanden uit een recent archief en een ouder archief uit naar een afzonderlijke map en vergelijk vervolgens inhoud, metagegevens en machtigingen. Test met hetzelfde Borg-binary en externe pad die de automatisering zal gebruiken.

Werk één client bij naar de nieuwe URL, wis of bouw alleen de cachestatus opnieuw op die Borg als noodzakelijk aanwijst en maak een klein testarchief. Herstel vanuit dat archief en bevestig dat planning voor opschonen of compacten uitgeschakeld blijft totdat alle clients de nieuwe locatie gebruiken.

De omschakeling is geslaagd wanneer de archiefinventaris overeenkomt, de controles slagen, twee herstelacties bruikbaar zijn en een nieuwe back-up slaagt na opnieuw opstarten of het herstarten van de planner. Houd de bron gedurende ten minste één normale cyclus alleen-lezen; verwijder deze pas nadat de terugvaltijd is verstreken, of escaleer als de controles tussen bron en bestemming verschillen.