btrfs-Empfang schlägt bei inkrementellen Streams fehl: „Datei existiert“

btrfs-Empfang schlägt bei inkrementellen Streams fehl: „Datei existiert“

Für ein BTRFS-Untervolume habe ich ein einfaches inkrementelles Backup aus zwei Phasen erstellt:

btrfs send old/@ > base.btrfs
btrfs send new/@ -p old/@ > update.btrfs

Bei den beiden Quelluntervolumes handelt es sich um Snapshots, die zu unterschiedlichen Zeiten vom selben aktiv gemounteten Untervolume erfasst wurden.

Auf dem Ziel versuche ich Folgendes wiederherzustellen:

btrfs receive ./ < base.btrfs
btrfs receive ./ < update.btrfs

Es wird erwartet, dass der vorherige Befehl einen wiederhergestellten Snapshot der ersten Sicherungsphase erstellt und dass der letztere die weitere inkrementelle Phase anwendet.

Der vorherige Befehl ist erfolgreich, der letztere schlägt jedoch fehl:

ERROR: creating snapshot ./@ -> @ failed: File exists

Da es offensichtlich ist, dass ich den letzten Schritt nicht sinnvoll auf ein Ziel anwenden kann, das nicht existiert, wundere ich mich darüber, warum der Prozess diese Prüfung durchführt und was für eine erfolgreiche Anwendung des Updates erforderlich ist.

Wie kann ich die Aktualisierungsphase auf das Ziel anwenden, das durch Wiederherstellen der Anfangsphase generiert wurde?

Antwort1

Sie können (wie auf der sendenden Seite) nicht mehrere Untervolumes mit demselben Namen haben.

Sie können mvden Basis-Snapshot/das Basis-Subvolume auf dem Zielsystem wie folgt anzeigen:

mv @ @.old
btrfs receive ./ < update.btrfs

Antwort2

Ich habe seit dem Posten der Frage genug gelernt, um sie beantworten zu können.

Die Antwort besteht aus zwei Teilen.

Erstens receiveerstellt der Unterbefehl immer einen neuen Eintrag im Zielverzeichnis mit demselben Namen wie das ursprüngliche Untervolume, unabhängig davon, ob das neue Untervolume aus einem untergeordneten oder übergeordneten Stream erstellt wird. Daher muss das Zielverzeichnis leer sein, zumindest wenn der Name mit dem des ursprünglichen Untervolumes identisch ist. Eine einfache Technik wäre, für das übergeordnete und jedes untergeordnete Untervolume jeweils ein neues leeres Verzeichnis zu erstellen.

Zweitens: Obwohl der Aufruf des Unterbefehls auf einem untergeordneten Datenträger keinen Verweis auf einen übergeordneten Datenträger enthält, kann er die erforderlichen Daten des übergeordneten Datenträgers verwenden, sofern dieser auf einem Untervolume in derselben Partition wiederhergestellt wurde. Das heißt, der receiveUnterbefehl hat die gewünschte Wirkung auf den untergeordneten Datenträger, sofern er zuvor auf derselben Partition für den übergeordneten Datenträger aufgerufen wurde.

Sobald die übergeordneten Elemente und die untergeordneten Elemente wiederhergestellt wurden, können alle übergeordneten Elemente gelöscht werden, ohne den untergeordneten Elementen zu schaden.

Folglich wäre das Folgende eine wirksame Befehlssequenz für das ursprüngliche Ziel:

mkdir _tmp
btrfs receive _tmp/ < base.btrfs
btrfs receive ./ < update.btrfs
btrfs subvolume delete _tmp/@
rmdir _tmp

Der gesamte Inhalt des untergeordneten Streams wäre dann über verfügbar ./@.

Natürlich wären weitere Befehle erforderlich, wenn der für die Erhaltung vorgesehene untergeordnete Datenstrom mehrere Vorgänger hätte (z. B. base.btrfseinen eigenen übergeordneten Datenstrom).

verwandte Informationen