Så konfigurerar du Btrfs Send och Receive för inkrementella säkerhetskopior på annan plats

Btrfs send och receive kan omvandla skrivskyddade subvolymögonblicksbilder till en effektiv replikeringskedja till en annan plats. Den första överföringen skickar en fullständig ögonblicksbild. Senare överföringar använder en tidigare replikerad ögonblicksbild som överordnad, så att endast de ändringar som behövs för att återskapa den nya ögonblicksbilden skickas över nätverket.

I ZimaOS ska du först bekräfta att både källan och destinationen på annan plats faktiskt är Btrfs-filsystem och att SSH-åtkomst är tillgänglig. ZimaSpaces aktuella guide för diskformat listar stöd för BTRFS med läsning och skrivning, och ZimaOS SSH-guide visar hur du aktiverar terminalåtkomst från utvecklarläget.

Förstå säkerhetskopieringskedjan innan du börjar

Btrfs send/receive är subvolymreplikering, inte ett generellt kommando för att kopiera kataloger. Källan måste vara en Btrfs-subvolym, och varje ögonblicksbild som används av btrfs send måste vara skrivskyddad. En skrivskyddad montering ersätter inte en skrivskyddad subvolymögonblicksbild.

Den officiella dokumentationen om btrfs send beskriver två lägen. En fullständig sändning innehåller hela ögonblicksbilden. En inkrementell sändning använder -p eller -c med ögonblicksbilder som finns i samma tillstånd på både avsändaren och mottagaren.

För en enkel kedja till en annan plats använder du en uttrycklig överordnad med -p:

snapshot-A  --full send-->  ögonblicksbild-A på annan plats
snapshot-B  --send -p A-->  ögonblicksbild-B på annan plats
snapshot-C  --send -p B-->  ögonblicksbild-C på annan plats

Ta inte bort eller ändra den aktuella överordnade ögonblicksbilden förrän nästa inkrementella överföring har slutförts och verifierats.

Verifiera att källan är en Btrfs-subvolym

Ersätt exempelsökvägarna med de faktiska monteringspunkterna på ditt system. Ögonblicksbildskatalogen bör ligga utanför den aktiva källsubvolymen, så att säkerhetskopieringsögonblicksbilder inte blir kapslade i de data som skyddas.

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

Det första kommandot bör rapportera btrfs. Det andra måste identifiera /mnt/pool/data som en subvolym. Om det bara är en vanlig katalog ska du stoppa här: btrfs send kan inte skicka en godtycklig katalog.

Kör samma filsystems kontroll på systemet på annan plats för mottagningsplatsen. btrfs receive måste skapa sin replikerade subvolym på ett Btrfs-filsystem.

Förbered SSH innan säkerhetskopieringsdata strömmas

En extern dataström är binära filsystemdata. SSH är en praktisk transport eftersom det tillhandahåller autentisering och kryptering under överföringen. Om du använder ZimaOS på någon av slutpunkterna aktiverar du SSH först och testar en vanlig inloggning innan du försöker med en Btrfs-dataström.

ssh backup@backup.example.net

För oövervakade jobb använder du SSH-autentisering med nyckel. Fjärrkontot måste också kunna köra btrfs receive interaktivt. Låt inte en fjärransluten sudo lösenordsfråga som läses från samma standardindata som Btrfs-dataströmmen. En strikt begränsad behörighetsregel för den nödvändiga mottagningsåtgärden är säkrare än bred lösenordsfri root-åtkomst.

Skapa målkatalogen under en interaktiv administrativ session:

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Skapa den första skrivskyddade ögonblicksbilden

Skapa en fast skrivskyddad ögonblicksbild av den aktiva källsubvolymen. Den -r flaggan är viktig eftersom Btrfs-inkrementell överföring bygger på ögonblicksbilder som inte kan ändras under överföringen.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

Bekräfta egenskapen innan du skickar:

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

Det förväntade resultatet är ro=true.

Skicka den första fullständiga ögonblicksbilden till en extern plats

Den första överföringen har ingen förälder och är därför en fullständig överföring. I ett Bash-kompatibelt skal aktiverar du pipefail gör att ett fel på någon sida av pipelinen syns för det anropande skalet.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Om sudo -n misslyckas på fjärrvärden ska du åtgärda den fjärranslutna behörighetskonfigurationen innan du försöker igen. Ersätt den inte med en lösenordsfråga inuti dataströmspipelinen.

Den officiella dokumentationen för btrfs receive anger att en subvolym som har tagits emot utan fel blir skrivskyddad. Den varnar också för att mottagningssökvägen inte ska ändras medan en dataström tillämpas.

Verifiera den mottagna ögonblicksbilden innan den används som förälder

Anta inte att en avslutad SSH-session innebär att säkerhetskopieringskedjan är felfri. Kontrollera båda ögonblicksbilderna:

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

På avsändaren, notera ögonblicksbilden UUID. På mottagaren ska den replikerade subvolymen visa denna källidentifierare som sitt Mottaget UUID. Bekräfta också att den mottagna subvolymen är skrivskyddad.

Först efter den här kontrollen bör data-20260831-1000 bli förälder till nästa inkrementella säkerhetskopia.

Skapa och skicka nästa inkrementella ögonblicksbild

När livedatan har ändrats skapar du en ny skrivskyddad ögonblicksbild:

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

Skicka sedan endast ändringarna från den föregående ögonblicksbilden:

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Detta fungerar eftersom föräldraögonblicksbilden från den första sändningen fortfarande finns i identiskt skick på båda systemen. När den nya ögonblicksbilden har tagits emot och verifierats, data-20260901-0200 kan bli förälder för nästa körning.

Håll föräldraögonblicksbilderna identiska

Det vanligaste sättet att bryta en inkrementell kedja är att ändra skrivskyddsläget eller innehållet i en ögonblicksbild som används som förälder. Btrfs spårar mottagna ögonblicksbilder med ett mottaget UUID specifikt så att avsändaren och mottagaren kan identifiera motsvarande historik.

Den officiella Btrfs-vägledningen om flaggor för under volymer och mottagna UUID:er varnar för att en ändring av en mottagen ögonblicksbild från skrivskyddad till skrivbar bryter mot de antaganden som används av inkrementell sändning.

Därför ska du inte göra den mottagna ögonblicksbilden på den externa platsen skrivbar bara för att bläddra bland, återställa eller redigera filer. Om du behöver en skrivbar återställningskopia skapar du en separat ögonblicksbild från den skyddade mottagna ögonblicksbilden:

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

Den nya återställningsögonblicksbilden är skrivbar som standard, medan den ursprungliga mottagna ögonblicksbilden förblir intakt för framtida inkrementella sändningar.

Använd en säker regel för lagring av ögonblicksbilder

Du behöver inte behålla varje gammal ögonblicksbild för alltid, men du måste behålla den förälder som krävs för nästa sändning på båda systemen. En enkel rotationsregel är:

1. Skapa den nya skrivskyddade källögonblicksbilden.
2. Skicka den med den föregående lyckade ögonblicksbilden som -p.
3. Verifiera den nya mottagna ögonblicksbilden på den externa platsen.
4. Befordra den nya ögonblicksbilden till att bli nästa förälder.
5. Först därefter tar du bort äldre återställningspunkter enligt din lagringspolicy.

Att behålla flera historiska ögonblicksbilder kan ge användbara återställningspunkter, men kom ihåg att en ögonblicksbild på samma filsystem inte är en oberoende säkerhetskopia. Den externa repliken är värdefull eftersom den placerar en annan kopia på ett separat system och en separat plats. ZimaSpaces guide för 3-2-1-säkerhetskopiering förklarar varför en extern kopia skyddar mot fel som lokal redundans inte kan hantera.

Hantera kapslade Btrfs-under volymer separat

Btrfs-ögonblicksbilder är inte rekursiva över kapslade under volymer. Om /mnt/pool/data innehåller en annan under volym, innehåller den överordnade ögonblicksbilden en under volymstub i stället för en fullständig ögonblicksbild av de kapslade data.

Lista under volymer innan du slutför säkerhetskopieringsplanen:

sudo btrfs subvolume list /mnt/pool

Om viktiga programdata finns i kapslade under volymer skapar och replikerar du en separat kedja av skrivskyddade ögonblicksbilder för varje sådan volym.

Veta när du ska använda -p och när du ska använda -c

För en linjär säkerhetskopieringshistorik, -p är det enklaste och lättaste alternativet att granska. -c alternativet kan lägga till en eller flera klonkällor som låter Btrfs återanvända matchande extentar från ytterligare ögonblicksbilder, men dessa klonkällor måste också finnas i exakt samma skick på båda sidor.

Om du inte kan bevisa att en klonkällas innehåll är oförändrat och finns på båda systemen ska du inte använda den. En enkel kedja med en överordnad ögonblicksbild är vanligtvis säkrare för ett säkerhetskopieringsjobb till en extern plats.

Valfritt: Använd protokoll 2 för komprimerade extentar

På tillräckligt nya versioner av Linux och btrfs-progs kan Btrfs sändningsprotokoll 2 överföra komprimerade extentar effektivare med --compressed-data. Den officiella dokumentationen för sändning anger att protokoll 2 kräver btrfs-progs 6.0 eller senare på både sändare och mottagare samt Linux 6.0 eller senare på sändaren.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Aktivera inte detta enbart för att alternativet finns. Kontrollera först versionerna på båda slutpunkterna och använd standardprotokollet när kompatibilitet är viktigare än optimering.

Felsök vanliga fel vid inkrementell sändning och mottagning

Sändningskommandot anger att ögonblicksbilden inte är skrivskyddad

Återskapa ögonblicksbilden med btrfs subvolume snapshot -r. Att bara montera en skrivbar ögonblicksbild via en skrivskyddad montering uppfyller inte sändningskravet.

Den inkrementella sändningen kan inte hitta eller använda sin överordnade ögonblicksbild

Kontrollera att den exakta överordnade ögonblicksbilden fortfarande finns på sändaren och att dess motsvarande mottagna ögonblicksbild fortfarande finns på mottagaren. Om någon av de överordnade ögonblicksbilderna har raderats, ändrats eller gjorts skrivbar, återställ en matchande överordnad ögonblicksbild om du har en. Annars skapar du en ny skrivskyddad ögonblicksbild och startar en ny fullständig seedning.

btrfs receive anger att destinationsubvolymen redan finns

btrfs receive kommer inte att skriva över en befintlig subvolym med samma inkommande namn. Inspektera den befintliga subvolymen först. Om det är en misslyckad eller ofullständig mottagning och du har bekräftat att den är säker att ta bort, raderar du den ofullständiga subvolymen innan du försöker överföra samma data igen.

Mottagningsöverordningen ändrades efter att den anlände

Använd inte den ändrade ögonblicksbilden som grund för en ny inkrementell ström. Om det inte finns någon oförändrad matchande mottagningsöverordnad ögonblicksbild, startar du en ny fullständig säkerhetskopieringskedja.

Filer i en kapslad katalog saknas i ögonblicksbilden

Kontrollera om katalogen i sig är en Btrfs-subvolym. Kapslade subvolymer inkluderas inte rekursivt i den överordnade ögonblicksbilden och behöver en egen send/receive-kedja.

WAN- eller SSH-anslutningen bryts under en överföring

Behandla mottagningen som misslyckad om den inte slutfördes korrekt och den resulterande subvolymen inte verifieras korrekt. Det dokumenterade kommandogränssnittet för Btrfs send/receive har inget alternativ för att återuppta en ström. För opålitliga länkar över långa avstånd kan du överväga att skriva send-strömmen till en staging-fil, överföra filen med en återupptagbar transport och sedan mata den färdiga, betrodda filen till btrfs receive.

Skydda mottagningssidan mot opålitliga strömmar

Btrfs receive tillämpar filsystemsoperationer från den inkommande dataströmmen. Den officiella dokumentationen för receive avråder från att acceptera send-strömmar från opålitliga källor och rekommenderar att mottagningssökvägen skyddas mot samtidiga skrivningar medan en ström tillämpas.

Använd verifiering av SSH-värdar, nyckelbaserad autentisering, ett dedikerat säkerhetskopieringskonto och så snäva praktiska behörigheter som möjligt. Håll mottagningskatalogen borta från vanliga användares skrivvägar medan en säkerhetskopiering pågår.

Använd den här checklistan för varje inkrementell körning

• Bekräfta att båda slutpunkterna använder Btrfs.
• Skapa den nya källögonblicksbilden med -r.
• Behåll den tidigare lyckade överordnade ögonblicksbilden oförändrad på båda systemen.
• Skicka med btrfs send -p OLD NEW.
• Ta emot via en autentiserad och krypterad SSH-anslutning.
• Verifiera att körningen lyckades och jämför källans UUID med mottagarens Received UUID.
• Behåll den mottagna säkerhetskopieögonblicksbilden skrivskyddad.
• Skapa en separat skrivbar ögonblicksbild när du behöver återställa eller testa data.
• Rotera gamla ögonblicksbilder först efter att den nya överordnade ögonblicksbilden har verifierats.
• Säkerhetskopiera kapslade subvolymer med separata kedjor.

När en fullständig seedkörning och en inkrementell körning båda har lyckats manuellt, automatiserar du samma sekvens med loggning och uttryckliga kontroller av exit-status. Det viktiga är inte schemaläggaren, utan att bevara en oförändrad, verifierad överordnad ögonblicksbild i båda ändar av varje inkrementellt steg.