Migreringsguide för Borg Backup för att flytta ett arkiv till ny lagring
Det säkra tillvägagångssättet är att pausa skrivningar, kopiera eller överföra med en versionsanpassad metod, verifiera målet och genomföra övergången med återställning som en serie observerbara kontrollpunkter, inte som ett enda kommando.
I ett BorgBackup-arkiv på lokal lagring, en NAS eller lagring som nås via SSH är den praktiska risken att behöva flytta ett Borg-arkiv utan att skapa en splittrad eller tyst ofullständig kopia. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar någon annan variabel och stoppa när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.
Dokumentera arkivets förutsättningar före kopieringen
Spara Borg-versionen, arkiv-URL:en, arkiv-ID:t, krypteringsläget, nyckelns plats, processen för återställning av lösenfrasen, arkivlistan, storleken, det lediga utrymmet, inställningarna för endast tillägg samt varje klient eller automatiseringsjobb som kan skriva. Arkivet kan inte återställas från en lokal cache ensam, och krypterade arkiv kan vara beroende av nyckelmaterial som lagras utanför målet.
ZimaSpace-artikeln om en guide för återställning efter förlorad Borg-cache skiljer mellan cachetillstånd som kan byggas om och saknade nycklar eller arkivskador. Gör den kontrollen före migreringen så att ett nyckelproblem inte upptäcks först efter att den gamla lagringen är borta.
Bestäm om detta är en byte-för-byte-flytt av samma arkiv eller en överföring till ett nyinitierat arkiv. Borg-versionen och formatet avgör vilka metoder som finns; blanda inte kommandoexempel för Borg 1 och Borg 2 och anta inte att arkivets identitet bör ändras.
Pausa skrivningar och skapa en konsekvent källpunkt
Inaktivera timers, cron-jobb, containrar och fjärrklienter och bekräfta sedan att ingen Borg-process eller arkivlåsning är aktiv. Kör borg list och en lämplig borg check före kopieringen. Om källan inte klarar kontrollen ska du bevara den och diagnostisera tillståndet i stället för att klona osäkerheten till målet.
En diskussion på Super User belyser risken med att använda kopiering av ett aktivt arkiv med rsync medan ett deduplicerat Borg-arkiv ändras. Den säkra regeln är att kopiera ett pausat arkiv eller använda en filsystemsnapshot som tas efter att alla Borg-skrivningar har stoppats, så att index, segment, nonce-tillstånd och data hör till samma tidpunkt.
Håll säkerhetskopieringsscheman avstängda tills valideringen av målet är klar. Om avbrottet blir för långt kan du göra en första kopia medan arkivet är inaktivt, stoppa skrivningarna och sedan köra en slutlig synkronisering; låt aldrig källa och mål ta emot oberoende säkerhetskopior under övergången.
Kopiera med den metod som din Borg-version stöder
Vid en flytt av samma arkiv ska du bevara alla filer, behörigheter, stöd för glesa filer och ägarskap med ett lämpligt lokalt eller fjärrbaserat kopieringsverktyg och granska dess fellogg. Kopiera arkivroten som en enhet, inte utvalda arkiv eller till synes stora datakataloger. Låt källan vara orörd efter den slutliga synkroniseringen.
Vid ett nytt arkiv eller en formatmigrering ska du använda överföringsfunktionen endast när den stöds av de installerade Borg-versionerna och krypteringsplanen. Ett svar på Server Fault beskriver överföring mellan Borg-arkiv som den arkiv-till-arkiv-riktning som hör samman med Borg 2, vilket inte kan bytas ut mot en filsystemskopia för Borg 1.
Efter kopieringen ska du först montera eller exponera målet skrivskyddat för klienterna. Om arkiv-ID, nyckelåtkomst, behörigheter eller format är oväntade ska du stoppa och korrigera målet; initiera inte över kopierade data och kör inte reparation för att tvinga fram igenkänning.
Verifiera arkiv, växla klienter och behåll återställningsmöjligheten
Kör Borg list, info samt lämpliga arkiv- och arkivkontroller på målet. Extrahera testfiler från ett nyligt arkiv och ett äldre arkiv till en separat katalog och jämför sedan innehåll, metadata och behörigheter. Testa med samma Borg-binär och fjärrsökväg som automatiseringen kommer att använda.
Uppdatera en klient till den nya URL:en, rensa eller bygg endast om det cachetillstånd som Borg anger behövs och skapa ett litet testarkiv. Återställ från det arkivet och bekräfta att schemaläggningen för rensning eller komprimering fortfarande är inaktiverad tills alla klienter använder den nya platsen.
Övergången är godkänd när arkivinnehållet stämmer, kontrollerna godkänns, två återställningar fungerar och en ny säkerhetskopia lyckas efter omstart eller omstart av schemaläggaren. Behåll källan skrivskyddad under minst en normal cykel och radera den först när tiden för återställning har löpt ut, eller eskalera om kontrollerna skiljer sig mellan källa och mål.
Rekommenderade produkter
Support och tips
Mer att läsa
Arbetsflöde för underhåll av Restic-arkiv: kontrollera, rensa, komprimera och testa återställning
Restic har inget separat kompaktkommando: prune utför ompaketering. Skydda lås och ledigt utrymme, kontrollera igen efteråt och avsluta med en isolerad återställning.
Guide för återställning av Time Machine-NAS vid trasig eller övergiven säkerhetskopieringshistorik
Behåll det gamla paketet. Separera NAS-åtkomst, destinationsidentitet, bildskador och övergiven historik innan du väljer reparation eller en ny kedja.
Checklista för granskning av snapshot-bevaring för en hem-NAS
En användbar granskning av lagringsprinciper kopplar varje ögonblicksbildsnivå till ett återställningsbehov, en ansvarig, en kapacitetsbudget och en replikeringsgräns innan historik raderas.
