(BTRFS-)System Backup - die unendliche Geschichte

[Martin Deppe]

Hallo alle,

ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet. Nun dachte ich, ich mache mir Backups etc. und repariere es, klappte bisher aber nicht.

Dann dachte ich, ich mache ein System Backup (das unter Yast) via Livesystem und chroot. Selbiges läuft (oder sollte ich sagen schleicht) jetzt seit über 40 Stunden und wird einfach nicht fertig. Ist das normal? Ich denke eigentlich nicht: Unter "/"
befinden sich gerade mal ca. 9 GB, mit allerdings knapp 13 Mio. Dateien unter "/.snapshot" und DA ist er immer noch nicht durch :-(

Hätte jemand eine Idee, wieso das so lange dauert oder vielleicht sogar, wie ich das System elegant wieder zum Starten bringe? Die Dateisysteme sind nämlich in Ordnung!

Übrigens habe ich "/" und "/home" als BTRFS auf zwei Platten verteilt (RAID1) und hatte eigentlich mit "/boot/efi" und den Swap-Partitionen das gleiche vor, leider geht das offenbar nicht:
# fdisk -l (von den relevanten Platten)
-------------------------------------------------------------------------------------
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt


# Start End Size Type Name
1 2048 321535 156M Microsoft basic primary
2 321536 4530175 2G Linux swap primary
3 4530176 88422399 40G Microsoft basic primary
4 88422400 1953523711 889.4G Microsoft basic primary
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt


# Start End Size Type Name
1 2048 321535 156M EFI System primary
2 321536 4530175 2G Linux swap primary
3 4530176 88422399 40G Microsoft basic primary
4 88422400 1953523711 889.4G Microsoft basic primary
-------------------------------------------------------------------------------------
# btrfs fi show
Label: none uuid: d740dd1d-edab-48bf-952b-16926cf0b568
Total devices 2 FS bytes used 36.11GiB
devid 1 size 889.35GiB used 42.04GiB path /dev/sde4
devid 2 size 889.35GiB used 42.03GiB path /dev/sdd4

Label: none uuid: 7840498f-e504-466c-8d55-fbec0a1c08e6
Total devices 2 FS bytes used 8.60GiB
devid 1 size 40.00GiB used 10.04GiB path /dev/sde3
devid 2 size 40.00GiB used 10.03GiB path /dev/sdd3

Btrfs v0.20-rc1+20130701
-------------------------------------------------------------------------------------

Danke euch

[Denis Wollenhaupt]

Post by Martin Deppe
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet ...

Hallo Martin

Das wird wahrscheinlich kein allzu hilfreicher Beitrag, aber ich denke,
man darf zur Zeit noch vor dem Produktiv-Einsatz von BTRFS warnen.

Mir ist nämlich so ziemlich das gleiche passiert, wie Dir:

Das ROOTFS war nach dem letzten Kernelupdate _read only_ !?!

Dateisystemchecks ergaben ein angeblich konsistentes FS ... ja, und nun?

Alle Reparaturversuche brachten keinerlei Fortschritt.

Ich habe dann also neu installiert. Und zwar mit dem guten alten ext4.

Alles läuft seither prima.
--
Mit herzlichen Grüßen,
Denis Wollenhaupt

---------------------------------------
Göttinger Labor für Genomananlyse

Georg-August-Universität Göttingen
Grisebachstr. 8 | D-37077 Göttingen
Tel: +49 (0) 551 - 20 19 834
http://appmibio.bio.uni-goettingen.de/
---------------------------------------

[Martin Deppe]

Post by Denis Wollenhaupt

Post by Martin Deppe
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet ...

Hallo Martin
Das wird wahrscheinlich kein allzu hilfreicher Beitrag, aber ich denke, man darf zur Zeit noch vor dem Produktiv-Einsatz von BTRFS warnen.
Das ROOTFS war nach dem letzten Kernelupdate _read only_ !?!
Dateisystemchecks ergaben ein angeblich konsistentes FS ... ja, und nun?
Alle Reparaturversuche brachten keinerlei Fortschritt.
Ich habe dann also neu installiert. Und zwar mit dem guten alten ext4.
Alles läuft seither prima.

Tja, so ähnlich plane ich es auch schon langsam, mehr und mehr.

Ich denke, das Dateisystem ist wohl tatsächlich in Ordnung, ich kann nur nicht 'booten'. Was mich nur äußerst merkwürdig stimmt ist, dass es offenbar knapp 13 Mio. Dateien unter "/.snapshot" gibt. Eine derart große Anzahl habe ich, meine ich, noch nie
innerhalb eines Dateisystems gesehen und weiterhin dass das Systembackup soooo lange braucht, bei so "wenig" Daten (9 GB, wie gesagt).

[Tobias Crefeld]

Am Thu, 29 May 2014 14:09:31 +0200

Post by Martin Deppe
Ich denke, das Dateisystem ist wohl tatsächlich in Ordnung, ich kann
nur nicht 'booten'. Was mich nur äußerst merkwürdig stimmt ist, dass
es offenbar knapp 13 Mio. Dateien unter "/.snapshot" gibt.

Wenn / als btrfs eingerichtet wird, werden zyklisch snapshots angelegt,
IIRC stündlich - da kommt schon einiges zusammen. Unter /.snapshot
liegen die Metadaten zur Verwaltung der snapshots. Es ist halt eine
Eigenheit von btrfs, alle Snapshots samt Metadaten im eigenen
Filesystem zu verwalten. An und für sich gehört aber die Fähigkeit,
sehr viele Dateien und/oder sehr große Volumen zu verwalten, zu den
Eigenschaften, weshalb man modernere Filesysteme wie btrfs überhaupt
entwickelt hat.

Anschauen kann man sich das mit Werkzeugen wie snapper. Ich nehme an,
dass man für Backups eines btrfs-root eigene Backup-Werkzeuge
verwendet, die auf snapshots gehen. Normalerweise macht man ja seine
Backups im laufenden Betrieb und ohne Reboot von Live-CD.


btrfs ist sicher nicht die erste Wahl, wenn es um einfache und stabile
Handhabung geht. Die meisten setzen da lieber auf ext4fs oder
Vorgänger. Bei RHEL bevorzugt man in jüngerer Zeit XFS.


Gruß,
Tobias.

[Christian Meseberg]

Hallo zusammen,

Martin Deppe meinte am Donnerstag, den 29.05.2014 um 14:09 Uhr
wegen:(BTRFS-)System Backup - die unendliche Geschichte

Post by Martin Deppe

Post by Denis Wollenhaupt

Post by Martin Deppe
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet ...

Hallo Martin
Das wird wahrscheinlich kein allzu hilfreicher Beitrag, aber ich denke, man darf zur Zeit noch vor dem Produktiv-Einsatz von BTRFS warnen.
Das ROOTFS war nach dem letzten Kernelupdate _read only_ !?!
Dateisystemchecks ergaben ein angeblich konsistentes FS ... ja, und nun?
Alle Reparaturversuche brachten keinerlei Fortschritt.
Ich habe dann also neu installiert. Und zwar mit dem guten alten ext4.
Alles läuft seither prima.

Tja, so ähnlich plane ich es auch schon langsam, mehr und mehr.
Ich denke, das Dateisystem ist wohl tatsächlich in Ordnung, ich
kann nur nicht 'booten'. Was mich nur äußerst merkwürdig stimmt ist,
dass es offenbar knapp 13 Mio. Dateien unter "/.snapshot" gibt. Eine
derart große Anzahl habe ich, meine ich, noch nie
innerhalb eines Dateisystems gesehen und weiterhin dass das
Systembackup soooo lange braucht, bei so "wenig" Daten (9 GB, wie gesagt).

ich hatte - als ich btrfs mall getestet habe - ./snapshot vom Backup ausgenommen. Ich hätte auch nicht gewusst, was ich damit hätte tun können. Machte für mich deshalb keinen Sinn. Als totaler Laie setze ich eher auf bewährtes ;)
--
Beste Grüße
Christian


Schade, dass XMMS gerade nichts spielt :(

[Manfred Kreisl]

Hallo Martin,

Post by Martin Deppe
Hallo alle,
ich habe mir vor kurzem mein System (openSuSE 13.1, rootfs=BTRFS und homefs=BTRFS) durch einen Kernel-Update so zerschossen, dass es nicht mehr startet. Nun dachte ich, ich mache mir Backups etc. und repariere es, klappte bisher aber nicht.

Na toll, nur gut dass ich vor knapp vier Wochen mich ebenfalls für BTRFS
auf dem Notebook entschieden habe (wegen der Snapshots)

Post by Martin Deppe
Dann dachte ich, ich mache ein System Backup (das unter Yast) via Livesystem und chroot. Selbiges läuft (oder sollte ich sagen schleicht) jetzt seit über 40 Stunden und wird einfach nicht fertig. Ist das normal? Ich denke eigentlich nicht: Unter "/"
befinden sich gerade mal ca. 9 GB, mit allerdings knapp 13 Mio. Dateien unter "/.snapshot" und DA ist er immer noch nicht durch :-(

Ja, diese .snapshot Verzeichnisse sind schon echt saublöde. Da hat wie
ich finde Debian/Ubuntu einen wesentlich besseren Ansatz dafür gemacht
(ich hab das auf meiner XBMC/Xbian Distri für den Raspberry so, ne echt
coole Sache und läuft bisher völlig problemlos) aber das hilft dir
natürlich jetzt auch nicht. Ich für meinen Teil sichere jeden Tag via
rsnapshot, wobei ich natürlich die .snapshot Verzeichnisse ausklammere,
auf ein anderes System. Auf die Snapshots kann man im Falle eines
FS-GAUs eh Verzichten, wie ich meine.

Post by Martin Deppe
Hätte jemand eine Idee, wieso das so lange dauert oder vielleicht sogar, wie ich das System elegant wieder zum Starten bringe? Die Dateisysteme sind nämlich in Ordnung!

Leider schreibst Du nicht, wie sich das äußert, dass dein System nicht
mehr startet.

Post by Martin Deppe
# fdisk -l (von den relevanten Platten)
-------------------------------------------------------------------------------------
# btrfs fi show
Label: none uuid: d740dd1d-edab-48bf-952b-16926cf0b568
Total devices 2 FS bytes used 36.11GiB
devid 1 size 889.35GiB used 42.04GiB path /dev/sde4
devid 2 size 889.35GiB used 42.03GiB path /dev/sdd4
Label: none uuid: 7840498f-e504-466c-8d55-fbec0a1c08e6
Total devices 2 FS bytes used 8.60GiB
devid 1 size 40.00GiB used 10.04GiB path /dev/sde3
devid 2 size 40.00GiB used 10.03GiB path /dev/sdd3
Btrfs v0.20-rc1+20130701
-------------------------------------------------------------------------------------

Seltsam, bei mir ist Btrfs v3.12+20131125, ebenfalls openSUSE 13.1 64Bit
Wie du schreibst, sind die beiden FS soweit in Ordnung. Da würde ich
halt "ganz einfach" den Snapshot vor dem Kernelupdate verwenden und
damit die FS wieder herstellen, dafür sind die Snapshots ja eigentlich
ja auch da

Gruß Manfred

[Manfred Kreisl]

Post by Manfred Kreisl

Post by Martin Deppe
Btrfs v0.20-rc1+20130701
-------------------------------------------------------------------------------------

Seltsam, bei mir ist Btrfs v3.12+20131125, ebenfalls openSUSE 13.1 64Bit
Wie du schreibst, sind die beiden FS soweit in Ordnung. Da würde ich
halt "ganz einfach" den Snapshot vor dem Kernelupdate verwenden und
damit die FS wieder herstellen, dafür sind die Snapshots ja eigentlich
ja auch da

Guck dir mal die Seite hier an:
http://doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/cha.snapper.html

insbesondere Procedure 4.2. Undoing changes using the snapper command

Ein noch konsistentes FS vorausgesetzt, kann man - zumindest theoretisch
- mit einem Befehl - das FS wieder zum jeden beliebigen
(Snapshot)Zeitpunkt restaurieren

Gruß Manfred

[Martin Deppe]

Post by Manfred Kreisl

Post by Manfred Kreisl

Post by Martin Deppe
Btrfs v0.20-rc1+20130701
-------------------------------------------------------------------------------------

Seltsam, bei mir ist Btrfs v3.12+20131125, ebenfalls openSUSE 13.1 64Bit
Wie du schreibst, sind die beiden FS soweit in Ordnung. Da würde ich
halt "ganz einfach" den Snapshot vor dem Kernelupdate verwenden und
damit die FS wieder herstellen, dafür sind die Snapshots ja eigentlich
ja auch da

http://doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/cha.snapper.html
insbesondere Procedure 4.2. Undoing changes using the snapper command
Ein noch konsistentes FS vorausgesetzt, kann man - zumindest theoretisch - mit einem Befehl - das FS wieder zum jeden beliebigen (Snapshot)Zeitpunkt restaurieren
Gruß Manfred

Ich danke euch (Tobias, Christian und Manfred) für eure Antworten, ich werde mir insbesondere mal anschauen, auf den Snapshot vor dem Kernelupdate zurückzusetzen. Wäre schön, wenn es funktioniert :-)

Gruß
Martin