BTRFS-Dateisystem änderung ohne mounten?

[Traceman]

Hallo,

ich dismounte auf einem Server ein BTRFS-Dateisystem, dann wird es mit auf einen anderen Server als Komplettkopie (dd, nc) übertragen. Nun habe ich auf beiden Seiten die Prüfsumme über die identische Plattengröße (dd, md5sum) gebildet und sie sind verschieden?!!??!

Wird auch ohne das Mounten ein BTRFS-Dateisystem verändert? Das ganze habe ich nun auch schon 2x mal gemacht.
Muß ich eventl. nach dem Dismounten noch etwas warten?

Das 'btrfs check ...' hat auf der Kopie keine Fehler gefunden.

Hardy

[smutbert]

Also, wenn du ein nicht gemountetes Blockgerät mit dd, cp oder ähnlichen Tools kopierst und bevor du Original oder Kopie mountest die Prüfsummen vergleichst, sollten die schon gleich sein. Dabei ist es ja auch ganz egal ob da ein Dateisystem, Nullen, Zufallsdaten oder sonst etwas drauf ist.

Voraussetzung ist natürlich, dass du auch wirklich nur die kopierten Daten prüfst.
Wenn du nur eine Partition so auf eine baugleiche Platte kopierst, aber dann die ganze Platte prüfst, gibt es natürlich möglicherweise schon Unterschiede. Das nächste ist, dass auch zwei scheinbar gleiche Festplatten (gleiches Modell desselben Herstellers) in der Größe nicht genau übereinstimmen müssen.

Ob einem an der Stelle außer das automatische Mounten in einer grafischen Oberfläche auch bereits das blosse Erkennen des Dateisystems, wie es beispielsweise unter Gnome passiert, Probleme machen kann, bin ich mir jetzt nicht 100%ig sicher.

(Ich würde ja sowieso eher die Dateien kopieren, z.B. mit rsync oder scp oder das Dateisystem mit btrfs-send/receive klonen. btrfs prüft die Prüfsummen beim Lesen ja sowieso, Fehler würden also gemeldet.)

[Traceman]

Es sind Server ohne grafische Oberfläche. Die anderen Verfahren kommen nicht in frage, da das Subvolume die UUID behalten muß (Backup läuft über btrfs send / receive).
Die Größe der LVM-Volumes ist identisch, somit auch die Anzahl der Bytes für die Prüfsumme.

Es ist kein Automount o.ä. aktiv.

Ich habe die Platte 2x kopiert (hier allerding ein LVM-Snapshot) und dann war die Prüfsumme ok. Aber ich muß es mit 1x schaffen, meine möglichen Zeitfenster zum Serverumzug sind zu kurz.

Die Platten kann ich nicht umbauen, da die neuen größer sind und das LVM-Volume im nächsten Schritt vergrößert werden soll.
Hardy

[cosinus]

Warum versteifst du dich so sehr auf das Dateisystem? Das Dateisystem hat die Aufgabe, zuverlässig Dateien zu speichern. Tut es das nicht?

[Traceman]

Weil es Teil des Backups ist:

1. es wird jede Stunde ein readonly Snapshot erstellt
2. jeden Abend wird der 20 Uhr-Snapshot per send / receive auf das Backup-FS übertragen (mit Option -p bei send)

Und bei Punkt 2 ist das entscheidende, ich kann nicht einfach ein neues Dateisystem erstellen, weil dann das receive den Quell-Snapshot nicht mehr findet.

[schorsch_76]

btrfs "mag" [1] es nicht wenn es per dd kopiert wird.

[1] https://archive.kernel.org/oldwiki/btrf ... of_devices

EDIT:
Das Mittel der Wahl ist partclone

Do NOT

make a block-level copy of a Btrfs filesystem to another block device...
use LVM snapshots, or any other kind of block level snapshots...
turn a copy of a filesystem that is stored in a file into a block device with the loopback driver...

... and then try to mount either the original or the snapshot while both are visible to the same kernel.

Why?

If there are multiple block devices visible at the same time, and those block devices have the same filesystem UUID, then they're treated as part of the same filesystem.

If they are actually copies of each other (copied by dd or LVM snapshot, or any other method), then mounting either one of them could cause data corruption in one or both of them.

If you for example make an LVM snapshot of a btrfs filesystem, you can't mount either the LVM snapshot or the original, because the kernel will get confused, because it thinks it's mounting a Btrfs filesystem that consists of two disks, after which it runs into two devices which have the same device number.

Is there no way out of this?

While it's technically possible to have block device copies around as long as you don't try to use mount, you have to be extremely careful with this. In most distributions udev runs btrfs device scan automatically when a block device is discovered. Also, programs like os-prober exist which will try to look into filesystems when you might not expect it. So, don't leave anything to chance when trying this.

Remedies:

Make sure your kernel has the "btrfs: harden agaist duplicate fsid" commit.
Some options you have to hide filesystem copies are:
Copying a filesystem into a file, which is harmless in itself, because the file will not be visible as a block device.
Remove one copy from the system (physically, or by deletion of the block device or FS) before mounting the other copy
When using LVM, lvchange -a n <vg>/<lv> can be used to make the block device disappear temporarily. But beware of the fact that it can be auto-activated again.
btrfstune -u can change the fsid (filesystem UUID?)

[Traceman]

Wer sagt denn das das ein Server ist?
Ich habe bereits geschbieben, daß es mit dd und nc kopiert worde. Wozu soll ich nc local einsetzen?
also so habe ich es gemacht:

1. Server: dd if=... | nc x.x.x.x 123
2. Server: nc -l -p 123 | dd of=...

Wie sollen da auf einem Server gleiche uuids auftauchen???

Außerdem will ich da genau die gleiche uuid!

[Traceman]

Die einfache Frage an die Exterten, ich dachte in diesem Formum gibt es welche, was:
Hat btrfs Hintergrundprozesse, die ein Dateisystem ohne mount verändern, wenn ein neues btrfs-Dateisystem auftaucht.

[GregorS]

Wer sagt denn das das ein Server ist?

Du:

...
1. Server: dd if=... | nc x.x.x.x 123
2. Server: nc -l -p 123 | dd of=...
...

Gregor

[bluestar]

Klonst du du eine gesamte Platte oder eine Partition?

In beiden Fällen die Fragen:
- Haben Festplatte bzw. Partition auf beiden Systemen die exakt (Byte genau) gleiche Größe?

Falls die Größen variieren kannst du die Prüfsummenmethode in einfacher Art vergessen.

[bluestar]

Hat btrfs Hintergrundprozesse, die ein Dateisystem ohne mount verändern, wenn ein neues btrfs-Dateisystem auftaucht.

Nein!

[Traceman]

@smutbert: vielen Dank für diese Hinweise, daß diese nicht in Frage kommen hatte ich nicht geschrieben.

@GregorS: ??? Was ist mit 1. (erster) und 2. (zweiter) Server? Im Eröffnungstext steht "... einem Server ... auf einen anderen Server ..."

@bluestar: Das ist eine klare Antwort, ist das Deine Meinung oder weist Du es genau?

Hardy

[schorsch_76]

Las mich das zusammenfassen: Du schreibst oben von einem Server von dem du Snapshots machst und möchtest ein dd image machen. Wenn sich die Disk verändert ist sie gemountet. Sicher das root nicht auf diesem Image ist?

[DaCoda]

Eigentlich hast du keinen Fehler gemacht. Zumindest von dem was du berichtet hast.
Das mit den UUIDs sollte ja egal sein, wenn das ein anderer Rechner ist.

Mit sudo lsof | grep ... kannst du sehen, ob was drauf zugreift trotz unmount.

Das Image verwenden obwohl der Hash anders ist, würde ich auf keinen Fall. Außerdem kannst du crc32 nehmen. Md5 ist in deinem Fall Stromverschwendung.

[smutbert]

Ich habe die Platte 2x kopiert (hier allerding ein LVM-Snapshot) und dann war die Prüfsumme ok. Aber ich muß es mit 1x schaffen, meine möglichen Zeitfenster zum Serverumzug sind zu kurz.

Das deutet für mich darauf hin, dass beim ersten Mal die Daten bei der Übertragung korrumpiert worden sein könnten. Du hast nicht zufällig über die erste (korrumpierte) Kopie ein scrub laufen lassen um die Daten zu prüfen?

(Das ist etwas was mir an deinem Vorgehen nicht ganz gefällt: btrfs bietet eine Überprüfung der gelesenen Daten und du kopierst das Dateisystem daran vorbei. Hilft natürlich auch nichts, wenn die Fehler bei der Übertragung auftreten und so wie du das schilderst habe ich sowieso keine bessere Idee, außer dich nicht auf subvolume-IDs zu verlassen.)

[jph]

ich dismounte auf einem Server ein BTRFS-Dateisystem, dann wird es mit auf einen anderen Server als Komplettkopie (dd, nc) übertragen. Nun habe ich auf beiden Seiten die Prüfsumme über die identische Plattengröße (dd, md5sum) gebildet und sie sind verschieden?!!??!

Dass dd der falsche Weg ist, um ein btrfs-Dateisystem zu übertragen, wurde dir bereits genannt. Bitte lass da unter allen Umständen die Finger von.

Wenn du btrfs-Dateisysteme übertragen willst, dann schau dir btrbk an. Das ist nichts anderes als ein Wrapper um btrfs-send/btrfs-receive, der aber insbesondere dieses Problem löst:

Und bei Punkt 2 ist das entscheidende, ich kann nicht einfach ein neues Dateisystem erstellen, weil dann das receive den Quell-Snapshot nicht mehr findet.

Ich schicke damit wöchentlich mein Backup-Subvolume per DSL auf einen Raspberry Pi, der sich anderswo befindet. Dieser Prozess wird gelegentlich von der nächtlichen DSL-Zwangstrennung unterbrochen. btrbk kommt damit problemlos klar.

[Traceman]

Dass dd der falsche Weg ist, um ein btrfs-Dateisystem zu übertragen, wurde dir bereits genannt.

Nein, das wurde noch nicht gesagt. Die Aussagen zum dd bezogen sich auf einen Server. Da ist klar das die UUID nicht mehrfach auftauchen sollte. Hier geht es aber um ein paar TB von Zufallszahlen von einem Server zum anderen über eine 10Gbit Glasfaser.

Die Netzwerkverbindung habe ich jetzt mal einen ganzen Tag getestet und es ist nicht ein Bit falsch übertagen worden.
Ich werde bei der nächten Übertragung mal die Prüfsumme nicht über alles, sondern kleinere überschaubare Blöcke bilden. Vielleicht muß ich nicht so viel 2x übertragen.

Aber ein großes Dankeschön an alle die mit überlegt haben ...

Hardy

[wanne]

@Traceman
Nochmal um die Entscheidene Information aus schorsch_76s beitrag zu verdeutlichen
* Grub mounted Dateisysteme bei jedem Update
* Systemd mounted jedes neu erkannte Dateisystem.
Beide umounten die direkt wieder. Aber ein einfacher mount verändert zumindest XFS/ext3/ext4 selbst wenn er ro ist. Tippe dass das bei btrfs ähnlich ist.
IMHO beides ein Unding. Habe mich da schon mit Pöttering drüber gestritten. Aber heute soll ja immer alles automatisch funktionieren...

Die Netzwerkverbindung habe ich jetzt mal einen ganzen Tag getestet und es ist nicht ein Bit falsch übertagen worden.

Das würde ich mal stark bezweifeln. Aber tcp hat checksummen und überträgt erneut, wenn es Fehler gibt. Ethernet und TLS haben nochmal welche. Als Endanwender ist es ziemlich schwer, derartige Fehler überhaupt mit zu bekommen. Eine erneute Checksumme ist deswegen eher überflüssig, wenn man https oder ähnliches macht.

Wie schon mehrfach angemerkt gibt es keinen Grund btrfs send/receive nicht zu verwenden. Dein verlangen, dass UUIDs zweier Dateisysteme gleich sein sollen klingt eher so, als ob du dir sonst irgend wie das Dateisystem kaputt schießt. Es gibt aber eigentlich auch keinen Grund nicht zwei mal die gleiche UUID zu haben, wenn man die Systeme sauber getrennt hält. – Auch wenn die btrfs Entwickler das nicht mögen. Aber 2 Server heißt eben nicht unbedingt, dass die getrennt sind. Wie du gemerkt hast, kann man Dateisysteme oder Snapshots übers Netzwerk übertragen oder schlicht Datenträger hin und her tragen. Genau deswegen haben die btrfs Leute ursprünglich die UUIDS eingeführt. Um Dateisysteme wieder erkennen zu können.

Ich würde mal in den Kernel Log (dmsg) gucken. Eventuell meckert ja die Festplatte, dass sie kaputt ist. Da siehst du eventuell auch, ob dein Dateisystem gemountet wird oder sonst was nicht stimmt.