Btrfs Send en Receive configureren voor incrementele back-ups op afstand

Met Btrfs send en receive kun je alleen-lezen subvolumesnapshots omzetten in een efficiënte externe replicatieketen. De eerste overdracht verzendt een volledige snapshot. Latere overdrachten gebruiken een eerder gerepliceerde snapshot als bovenliggend subvolume, zodat alleen de wijzigingen die nodig zijn om de nieuwe snapshot te reconstrueren via het netwerk worden verzonden.

Controleer op ZimaOS eerst of zowel de bron als de externe bestemming daadwerkelijk Btrfs-bestandssystemen zijn en of SSH-toegang beschikbaar is. De actuele handleiding voor schijfformattering van ZimaSpace vermeldt ondersteuning voor BTRFS-lezen en -schrijven, en de ZimaOS-SSH-handleiding laat zien hoe je terminaltoegang vanuit de ontwikkelaarsmodus inschakelt.

Begrijp de back-upketen voordat je begint

Btrfs send/receive is replicatie van subvolumes, geen algemene opdracht voor het kopiëren van mappen. De bron moet een Btrfs-subvolume zijn, en elke snapshot die wordt gebruikt door btrfs send moet alleen-lezen zijn. Een alleen-lezen aangekoppeld bestandssysteem is geen vervanging voor een alleen-lezen subvolumesnapshot.

De officiële btrfs-send-documentatie beschrijft twee modi. Een volledige overdracht bevat de volledige snapshot. Een incrementele overdracht gebruikt -p of -c met snapshots die op de verzender en ontvanger in dezelfde staat beschikbaar zijn.

Gebruik voor een eenvoudige externe keten één expliciet bovenliggend subvolume met -p:

snapshot-A  --volledige overdracht-->  extern snapshot-A
snapshot-B  --send -p A-->  extern snapshot-B
snapshot-C  --send -p B-->  extern snapshot-C

Verwijder of wijzig het huidige bovenliggende subvolume niet voordat de volgende incrementele overdracht is voltooid en gecontroleerd.

Controleer of de bron een Btrfs-subvolume is

Vervang de voorbeeldpaden door de echte aankoppelpunten op je systeem. De snapshotmap moet zich buiten het actieve bron-subvolume bevinden, zodat back-upsnapshots niet genest raken in de gegevens die worden beschermd.

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

De eerste opdracht moet rapporteren btrfs. De tweede moet met succes identificeren /mnt/pool/data als subvolume. Als het alleen een normale map is, stop dan hier: btrfs send kan geen willekeurige map verzenden.

Voer dezelfde bestandssysteemcontrole uit op het externe systeem voor de ontvanglocatie. btrfs receive moet zijn gerepliceerde subvolume aanmaken op een Btrfs-bestandssysteem.

Bereid SSH voor voordat u back-upgegevens streamt

Een send-stream naar een externe locatie bestaat uit binaire bestandssysteemgegevens. SSH is een praktisch transportmiddel omdat het authenticatie en versleuteling tijdens het transport biedt. Als u ZimaOS op een van beide eindpunten gebruikt, schakel SSH dan eerst in en test een normale aanmelding voordat u een Btrfs-stream probeert.

ssh backup@backup.example.net

Gebruik voor onbeheerde taken SSH-authenticatie met sleutels. Het externe account moet ook btrfs receive niet-interactief. Laat een externe sudo wachtwoordprompt die afkomstig is van dezelfde standaardinvoer die de Btrfs-stream bevat. Een strikt beperkte rechtenregel voor de vereiste receive-bewerking is veiliger dan brede wachtwoordloze root-toegang.

Maak de doelmap aan tijdens een interactieve beheersessie:

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

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Maak de eerste alleen-lezen snapshot

Maak een vaste alleen-lezen snapshot van het live-bronsubvolume. De -r Deze vlag is belangrijk omdat Btrfs incrementele send-bewerkingen afhankelijk zijn van snapshots die tijdens de send-bewerking niet mogen veranderen.

sudo mkdir -p /mnt/pool/.snapshots

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

Bevestig de eigenschap voordat u de overdracht start:

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

Het verwachte resultaat is ro=true.

Verstuur de eerste volledige snapshot naar een externe locatie

De eerste overdracht heeft geen ouder, dus dit is een volledige send. Schakel in een Bash-compatibele shell pipefail zorgt ervoor dat een fout aan beide kanten van de pipeline zichtbaar wordt voor de aanroepende shell.

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'

Als sudo -n Als dit op de externe host mislukt, verhelp dan eerst de configuratie van de externe rechten voordat u het opnieuw probeert. Vervang dit niet door een wachtwoordprompt binnen de streaming-pipeline.

De officiële documentatie over btrfs receive vermeldt dat een succesvol ontvangen subvolume alleen-lezen wordt. De documentatie waarschuwt ook dat gebruikers het ontvangstpad niet mogen wijzigen terwijl een stream wordt toegepast.

Controleer de ontvangen snapshot voordat u deze als ouder gebruikt

Ga er niet van uit dat het beëindigen van een SSH-sessie betekent dat de back-upketen gezond is. Inspecteer beide snapshots:

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'

Noteer op de verzender de snapshot UUIDOp de ontvanger moet het gerepliceerde subvolume die bron-ID als zijn Ontvangen UUIDControleer ook dat het ontvangen subvolume alleen-lezen is.

Pas na deze controle moet data-20260831-1000 de ouder worden voor de volgende incrementele back-up.

Maak en verstuur de volgende incrementele momentopname

Nadat de livegegevens zijn gewijzigd, maak je een nieuwe alleen-lezenmomentopname:

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

Verstuur vervolgens alleen het verschil met de vorige momentopname:

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'

Dit werkt omdat de bovenliggende momentopname van de eerste verzending nog steeds in overeenkomende vorm op beide systemen bestaat. Nadat de nieuwe momentopname succesvol is ontvangen en gecontroleerd, data-20260901-0200 kan de bovenliggende momentopname voor de volgende uitvoering worden.

Houd de bovenliggende momentopnamen identiek

De meest voorkomende manier om een incrementele keten te verbreken, is het wijzigen van de alleen-lezenstatus of inhoud van een momentopname die als bovenliggende momentopname wordt gebruikt. Btrfs houdt ontvangen momentopnamen bij met een ontvangen UUID, zodat de verzender en ontvanger de bijbehorende geschiedenis kunnen identificeren.

De officiële Btrfs-documentatie over subvolumevlaggen en ontvangen UUID's waarschuwt dat het wijzigen van een ontvangen momentopname van alleen-lezen naar lezen-schrijven de aannames verbreekt die voor incrementele verzending worden gebruikt.

Maak daarom de offsite-ontvangstmomentopname niet schrijfbaar alleen om bestanden te bekijken, te herstellen of te bewerken. Als je een schrijfbare herstelkopie nodig hebt, maak dan een afzonderlijke momentopname van de beveiligde ontvangstmomentopname:

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

De nieuwe herstelmomentopname is standaard schrijfbaar, terwijl de oorspronkelijke ontvangstmomentopname intact blijft voor toekomstige incrementele verzendingen.

Gebruik een veilige bewaarbeleidsregel voor momentopnamen

Je hoeft niet elke oude momentopname voor altijd te bewaren, maar je moet op beide systemen de bovenliggende momentopname bewaren die nodig is voor de volgende verzending. Een eenvoudige rotatieregel is:

1. Maak de nieuwe alleen-lezenbronmomentopname.
2. Verstuur deze met de vorige succesvolle momentopname als -p.
3. Controleer de nieuwe offsite-ontvangstmomentopname.
4. Maak van de nieuwe momentopname de volgende bovenliggende momentopname.
5. Verwijder pas daarna oudere herstelpunten volgens je bewaarbeleid.

Door meerdere historische momentopnamen te bewaren, beschik je over nuttige herstelpunten, maar onthoud dat een momentopname op hetzelfde bestandssysteem geen onafhankelijke back-up is. De offsite-replica is waardevol omdat die een extra kopie op een afzonderlijk systeem en op een andere locatie plaatst. In de 3-2-1-back-upgids van ZimaSpace wordt uitgelegd waarom een offsitekopie bescherming biedt tegen storingen die lokale redundantie niet kan opvangen.

Behandel geneste Btrfs-subvolumes afzonderlijk

Btrfs-snapshots zijn niet recursief over geneste subvolumes heen. Als /mnt/pool/data een ander subvolume bevat, bevat de bovenliggende snapshot een stub van een subvolume in plaats van een volledige snapshot van de geneste gegevens.

Maak een lijst van de subvolumes voordat je het back-upplan definitief maakt:

sudo btrfs subvolume list /mnt/pool

Als belangrijke applicatiegegevens in geneste subvolumes staan, maak dan voor elk subvolume een afzonderlijke keten van alleen-lezen-snapshots en repliceer die.

Weet wanneer je -p en wanneer je -c gebruikt

Voor een lineaire back-upgeschiedenis -p is de eenvoudigste optie om te controleren en te auditen. De -c Met de optie kunnen een of meer bronnen voor klonen worden toegevoegd, zodat Btrfs overeenkomende extents uit extra snapshots kan hergebruiken, maar die bronnen voor klonen moeten aan beide kanten exact in dezelfde staat bestaan.

Als je niet kunt aantonen dat een bron voor klonen ongewijzigd is en op beide systemen aanwezig is, gebruik deze dan niet. Een eenvoudige keten met één bovenliggende snapshot is doorgaans veiliger voor een back-uptaak op afstand.

Optioneel: gebruik protocol 2 voor gecomprimeerde extents

Op voldoende recente versies van Linux en btrfs-progs kan Btrfs-sendprotocol 2 gecomprimeerde extents efficiënter verzenden met --compressed-data. In de officiële documentatie over send staat dat protocol 2 op zowel de verzender als de ontvanger btrfs-progs 6.0 of hoger vereist, en op de verzender Linux 6.0 of hoger.

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'

Schakel dit niet alleen in omdat de optie bestaat. Controleer eerst de versies op beide eindpunten en gebruik het standaardprotocol wanneer compatibiliteit belangrijker is dan optimalisatie.

Veelvoorkomende fouten bij incrementele send- en receive-bewerkingen oplossen

De send-opdracht meldt dat de snapshot niet alleen-lezen is

Maak de snapshot opnieuw met btrfs subvolume snapshot -r. Alleen een schrijfbare snapshot via een alleen-lezen-koppeling mounten voldoet niet aan de vereiste voor send.

De incrementele send kan de bovenliggende snapshot niet vinden of gebruiken

Controleer of de exacte bovenliggende snapshot nog op de verzender bestaat en of de bijbehorende ontvangen snapshot nog op de ontvanger bestaat. Als een van beide bovenliggende snapshots is verwijderd, gewijzigd of schrijfbaar is gemaakt, herstel dan een overeenkomende bovenliggende snapshot als je die hebt. Maak anders een nieuwe alleen-lezen-snapshot en start een nieuwe volledige seed.

btrfs receive meldt dat het doel-subvolume al bestaat

btrfs receive zal een bestaand subvolume met dezelfde binnenkomende naam niet overschrijven. Inspecteer het bestaande subvolume eerst. Als het om een mislukte of onvolledige ontvangst gaat en u hebt bevestigd dat het veilig kan worden verwijderd, verwijdert u dat onvolledige subvolume voordat u dezelfde overdracht opnieuw probeert.

De bovenliggende snapshot op de ontvangende zijde is gewijzigd nadat deze was aangekomen

Gebruik die gewijzigde snapshot niet als basis voor een nieuwe incrementele stream. Als er geen ongewijzigde, overeenkomende ontvangende bovenliggende snapshot is, start u een nieuwe volledige back-upketen.

Bestanden in een geneste directory ontbreken in de snapshot

Controleer of die directory zelf een Btrfs-subvolume is. Geneste subvolumes worden niet recursief opgenomen in de bovenliggende snapshot en hebben hun eigen send/receive-keten nodig.

De WAN- of SSH-verbinding valt tijdens een overdracht weg

Beschouw de ontvangst als mislukt tenzij deze succesvol is voltooid en het resulterende subvolume correct is geverifieerd. De gedocumenteerde opdrachtinterface voor Btrfs send/receive biedt geen optie om een stream te hervatten. Overweeg bij onbetrouwbare verbindingen over lange afstand de send-stream naar een stagingbestand te schrijven, dat bestand met een hervatbaar transport over te dragen en het voltooide, vertrouwde bestand vervolgens door te geven aan btrfs receive.

Bescherm de ontvangstzijde tegen niet-vertrouwde streams

Btrfs receive past bestandssysteembewerkingen toe vanuit de binnenkomende stream. De officiële documentatie voor receive raadt af om send-streams van niet-vertrouwde bronnen te accepteren en adviseert het ontvangstpad te beschermen tegen gelijktijdige schrijfbewerkingen terwijl een stream wordt toegepast.

Gebruik SSH-hostverificatie, sleutelgebaseerde authenticatie, een speciaal back-upaccount en de kleinst praktisch haalbare set bevoegdheden. Houd de ontvangstdirectory buiten normale schrijfdoelen van gebruikers zolang er een back-up wordt uitgevoerd.

Gebruik deze checklist voor elke incrementele run

• Bevestig dat beide eindpunten Btrfs gebruiken.
• Maak de nieuwe bronsnapshot met -r.
• Houd de vorige succesvolle bovenliggende snapshot op beide systemen ongewijzigd.
• Verzend met btrfs send -p OLD NEW.
• Ontvang via een geauthenticeerde en versleutelde SSH-verbinding.
• Controleer of de bewerking is geslaagd en vergelijk de UUID van de bron met de ontvangen UUID van de ontvanger.
• Houd de ontvangen back-upsnapshot alleen-lezen.
• Maak een afzonderlijke beschrijfbare snapshot wanneer u gegevens moet terugzetten of testen.
• Roteer oude snapshots pas nadat de nieuwe bovenliggende snapshot is geverifieerd.
• Maak back-ups van geneste subvolumes met afzonderlijke ketens.

Zodra één volledige seed en één incrementele run handmatig succesvol zijn uitgevoerd, automatiseert u dezelfde reeks met logging en expliciete controles van de exitstatus. Het belangrijkste onderdeel is niet de planner, maar het behouden van een ongewijzigde, geverifieerde bovenliggende snapshot aan beide kanten van elke incrementele stap.