@Der Spaßmacher Jein. Das ist wieder n Punkt, wo man Btrfs' Immaturität erkennt. "btrfs receive" setzt das Subvolume zwar auf read-only, aber erst NACH dem vollständigen Empfang. Heißt während der Transfer noch im Gange ist, kann jeder, der Schreibzugriff auf eine Datei in dem Subvolume hat, diese auch beschreiben. Wer es also drauf anlegt, kann die Backups inkonsistent machen. Das wird besonders dann ein Problem, wenn man berücksichtigt wie "btrfs send" arbeitet. Bei inkrementellen Backups werden die zu sendenden Daten nämlich basierend auf einem anderen Quellsnapshot auf dem GLEICHEN Datenträger ermittelt.
Stell dir vor du hast in deinem Topvolume ein Subvolume "@home" mit deinem "/home" drin und hast das Topvolume nach "/.toplevel" gemountet, damit du Zugriff drauf hast. Davon möchtest du einen Snapshot machen und diesen dann an einen externen Datenträger, welcher nach "/mnt/external" gemountet ist, senden:
Code:
% btrfs subvolume snapshot /.toplevel/@ /.toplevel/@home_2020-05-01T00:53:32Z
% btrfs send /.toplevel/@home_2020-05-01T00:53:32Z | btrfs receive /mnt/external
Es ist wichtig zu wissen, dass der Name eines Subvolumes zum Subvolume gehört. Umbenennen ist also nicht drin, wenn das Ding read-only ist und würde auch inkrementelle Backups kaputt machen (man muss also wieder ein neues initiales Backup erstellen). Dementsprechend muss bei "btrfs receive" auch nur das Verzeichnis angegeben werden. Das entgültige Backup ist also in "/mnt/external/@home_2020-05-01T00:53:32Z" zu finden.
Jetzt hat allerdings irgendwer oder irgendwas während dem Transfer des Subvolumes die Datei "/mnt/external/@home_2020-05-01T00:53:32Z/username/Präsentation.odp" gelöscht. Die fehlt also im Backup. Das ist beschissen. Viel beschissener ist, dass sie auch so schnell nicht wieder im Backup auftauchen wird. Wenn wir jetzt nämlich eine dreiviertel Stunde später ein weiteres inkrementelles Backup erstellen...
Code:
% btrfs subvolume snapshot /.toplevel/@ /.toplevel/@home_2020-05-01T01:39:32Z
% btrfs send -p /.toplevel/@home_2020-05-01T00:53:32Z /.toplevel/@home_2020-05-01T01:39:32Z | btrfs receive /mnt/external
...geben wir die Basis des inkrementellen Backups mit "-p" an. Und zwar NUR beim "btrfs send", nicht beim "btrfs receive". Das "btrfs receive" macht dann ein Snapshot von dem Subvolume, welches bereits in "/mnt/external" liegt und den gleichen Namen hat wie das, welches in "-p" mitgegeben ist und patcht dann nur den Diff, den es von "btrfs send" bekommt, drüber. Die Datei wird also erst dann wieder im Backup auftauchen, wenn sie auf dem sendenden Datenträger vollständig neu geschrieben wurde. Ansonsten fehlt sie für immer.
Ich bin ehrlich: Ich mag Btrfs. Aber für mich ist es nur eine Übergangslösung, bis es eine andere Möglichkeit gibt inkrementelle und konsistente Backups zu machen. Möglichkeiten wie "rsync" funktionieren nämlich nicht mit sich dauernd ändernden Daten, wie Datenbanksysteme oder VMs. Und zudem müssen sie die Daten per Prüfsumme etc. vergleichen, was zwangsläufig langsamer ist. Btrfs macht dir neue inkrementelle Backups in 200ms.