[Gelöst] Einige Fragen zum ZFS und Btrfs Dateisystem unter Debian

[ralli]

Einige werden sich Fragen, warum ZFS? Ist das nicht wie "mit Kanonen auf Spatzen schießen"? Nun, dazu habe ich folgenden interessanten Beitrag über Silent Data Corruption gefunden:

https://www.it-administrator.de/themen/ ... 11409.html

Gruß ralli

[MSfree]

Nun, dazu habe ich folgenden interessanten Beitrag über Silent Data Corruption gefunden:

Prüfsummen gibt es aber nicht nur in ZFS.

Z.B. btrfs kann das auch, und es ist Bestandteile des Linuxkernels.

[ralli]

Nun, dazu habe ich folgenden interessanten Beitrag über Silent Data Corruption gefunden:

Prüfsummen gibt es aber nicht nur in ZFS.

Z.B. btrfs kann das auch, und es ist Bestandteile des Linuxkernels.

Ja danke für den Hinweis, ich wußte das aber schon. Trotzdem irgendwie komisch, das Oracle, das ja durch den Kauf von Sun in den Besitz von ZFS kam, nicht nur ZFS weiter entwickelte, sondern BTRFS ins Leben ruf. Nach einigen Anlaufschwierigkeiten gesellten sich später ja noch einige andere Firmen hinzu wie IBM, RedHat um nur einige zu nennen. Der Grund weshalb ich ZFS ausprobierte, waren weniger die Snapshots, sondern COW (Copy On Write) und einige andere Merkmale. Da ich jetzt die Grundlagen von ZFS beherrsche, knöpfe ich mir jetzt BTRFS vor, ein Debian Testing mit Gnome ist bereits mit BTRFS installiert. Mal sehen, wo Unterschiede sind. ZFS gilt ja als produktiv, BTRFS auch, allerdings gibt es bei BTRFS wohl noch bei einigen neu hinzugekommenen Funktionen Probleme. Insgesammt sollte man Schleichende Datenkorruption nicht auf die leichte Schulter nehmen. Selber hatte ich in den vergangenen Jahren noch nie irgendeinen Datenverlust, eher durch eigene Nachlässigkeit....

Was mir noch nicht ganz klar ist, ob für für BTRFS im Installer die Option beim Installieren bevorzugt werden sollte, wo Home auf eine eigene Partition eingerichtet wird.

Gruß ralli

[MSfree]

...sondern BTRFS ins Leben ruf.

Was der Lizenz von ZFS geschuldet ist, die wohl nicht mit der GPL vereinbar ist, was die Integration in den Kernel verhindert.

Insgesammt sollte man Schleichende Datenkorruption nicht auf die leichte Schulter nehmen. Selber hatte ich in den vergangenen Jahren noch nie irgendeinen Datenverlust, eher durch eigene Nachlässigkeit....

Das ist auch meine Erfahrung, Verlust war immer eigene Dummheit, aber man hat ja ein Backup gegen Eseleien. Letztlich helfen auch Prüfsummen nicht gegen schleichenden Datenverlust. Man erkennt ihn nur schneller, bevor noch mehr kaputt geht. Das, was bereits hinüber ist, ist dann nur noch aus dem hoffentlich vorhandenen (zweiten) Backup restaurierbar.

Was mir noch nicht ganz klar ist, ob für für BTRFS im Installer die Option beim Installieren bevorzugt werden sollte, wo Home auf eine eigene Partition eingerichtet wird.

Du meinst, daß der Debianinstaller btrfs statt ext4 vorschlagen sollte? Oder geht es dir nur um eine separate /home-Partition?

Ich bin ohnehin keine Fraund von Partitionismus. Meine Vorgehensweise ist eine Partition pro Platte/SSD oder RAID.

Ich fand btrfs unter Buster noch ziemlich experimentell. Unter Bullseye sind da schon deutlich weniger Kinderkrakheiten vorhanden, Ich würde btrfs meine Bauchgefühl nach, erst ab Bookworm stärkeres Vertrauen entgegen bringen. Bis dahin ist es mir nicht unrecht, wenn der Installer zunächst eher konservativ bleibt und ext4 vorschlägt. Wer will, kann ja btrfs auswählen.

Ich kann allerdings sagen, daß ich mit btrfs noch keine Probleme hatte. Auf meiner kleinen Synology wurde schon vor 5 Jahren btrfs eingesetzt, und die lief, bis sie zu klein wurde, tadellos. Allerdings hat Synology auf die ganzen fortschrittlichen Eigenschaften von btrfs verzichtet, nur Prüfsumen konnte man aktivieren, das Dateisystem wurde auf einem RAID-1 (md) eingerichtet.

[ralli]

Du meinst, daß der Debianinstaller btrfs statt ext4 vorschlagen sollte? Oder geht es dir nur um eine separate /home-Partition?

Nein das meinte ich nicht, ext4 ist ja ein bewährter Standard, und im Installer können ja auch andere Dateisysteme ausgewählt werden. Ich habe nicht den Standard (für Anfänger empfohlen) genommen, sondern die Option separate Home Partition genommen in dem Glauben, das die separate home Partition als Subvolume eingerichtet würde. Denn nur von Subvolumes können ja Snapshots gemacht werden. So habe ich es jedenfalls bei der Einarbeitung gelesen, wenn ich mich nicht irre. Ansonsten arbeite ich mit Testing (kommendes Bookworm), so das es wohl das neueste Btrfs sein sollte. Ein Subvolume ist wohl am ehesten mit einem Dataset von XFS vergleichbar. Bitte korrigieren, wenn ich Unsinn schreibe.

BTRFS Fehler können mit folgendem Befehl angezeigt werden:

Code: Alles auswählen

btrfs device stats /dev/sdb1

Erst wenn dabei Fehler gefunden werden, empfiehlt sich ein Scrub. Checksum für Datenintegrität überprüfen:

Code: Alles auswählen

btrfs scrub start /dev/sdb1

Behobene Fehler werden dann unter "corrected errors" angezeigt.

Wie der Fehlerzähler wieder (wenn erforderlich) auf 0 gesetzt wird, weiß ich (noch) nicht. Alles ausprobierte funktionierte bisher einwandfrei. Nun schaue ich mir mal an ob und wie ich einen Snapshot von /home machen kann, wenn das überhaupt geht, denn das ist wohl kein Subvolume.

Gruß ralli

[ralli]

Hab jetzt mal einen snapshot von einem subvolume dokumente angelegt:

Code: Alles auswählen

btrfs subvolume snapshot dokumente dokumente-snapshot

Es wurde ein Ordner dokumente-snapshot angelegt. Dann habe ich das subvolume dokumente gelöscht. Einfach den Ordner dokumente (der ein subvolume ist) im Nautilus gelöscht. Mir deucht, das war irgendwie verkehrt, oder? Mit welchem btrfs Befehl hole ich den snapshot zurück? Ich finde kein rollback, oder bin ich blind? Bin gerade ein wenig irritiert. Alles andere vorher habe ich verstanden, aber hier hakt es irgendwie. Brauche hier für ein wenig Unterstützung und Hilfe.

Gruß ralli

[schorsch_76]

Ich kann allerdings sagen, daß ich mit btrfs noch keine Probleme hatte. Auf meiner kleinen Synology wurde schon vor 5 Jahren btrfs eingesetzt, und die lief, bis sie zu klein wurde, tadellos. Allerdings hat Synology auf die ganzen fortschrittlichen Eigenschaften von btrfs verzichtet, nur Prüfsumen konnte man aktivieren, das Dateisystem wurde auf einem RAID-1 (md) eingerichtet.

Ich kann aus meiner Erfahrung sagen das btrfs bisher ohne Probleme läuft. Raid1 hatte ich auf dem Hetzner Server aktiv. Auch einen HDD Ausfall und ein Resilver hat unter buster problemlos funktioniert. lzo als Kompression läuft auch sehr gut. Ich hab es auf 2 Raspberry Pi4 "Servern" und auf dem Desktop am laufen. Auf dem NAS läuft es auf einem mdadm RAID5. Hier hab ich mich noch nicht getraut RAID5 unter btrfs zu probieren.
https://www.phoronix.com/news/Btrfs-Warning-RAID5-RAID6

Mein Setup ist eigentlich immer so:
/dev/sda1 EFI
/dev/sda2 swap
/dev/sda3 boot falls verschlüsseltes root
/dev/sda3/4 btrfs subvol=0

In dem btrfs hab ich dann meine Subvolumes wie rootfs, homefs, etc.

Hier ist bsp. die fstab von einem Raspberry Pi mit einer 512GB SD (für Dauereinsatz ausgelegt) als Datenträger unter einem reinem Debian bullseye mit Debian Kernel.
41824

Das sieht dann so aus:
41825

Die Snapshots werden von cron und einem kleinen Script gemacht das auch automatisch die Snapshots auf das NAS schiebt welches auch wieder mit btrfs läuft.

[ralli]

Leider komme ich nicht weiter. Ich schildere hier mal meine bisherige Vorgehensweise.

Ich installierte Debian Testing (Bookworm) als Neuinstallation im normalen Installationsmodus. Im Installer habe ich dann im Partitionsbereich das Filesystem von ext4 auf Btrfs umgestellt. Ich wählte eine separate Home Partition. Und installierte den Gnome Desktop. So weit so gut.

Dann rief ich Das Programm Laufwerke (Gnome-Disk-Utility) auf, um meine interne klassische HD zu partitionieren und mit Btrfs zu formatieren.
Das Gerät /dev/sda1 mit der UUID 393b07a6-f584-4e14-962d-e5ec5a22b04d und dem Label backup wird automatisch beim Systemstart gemountet und eingehängt.

Wechseln auf sdb1 und Terminal als root aufrufen.

Jetzt lege ich ein Subvolumen dokumente auf sdb1 an:

Code: Alles auswählen

btrfs subvolume create dokumente

Es kommt die Bestätigung:

Code: Alles auswählen

Create subvolume './dokumente'

Das Subvolume dokumente wurde also erfogreich angelegt und erscheint auch im Nautilus als Ordner.

Dann mach ich mich noch zum Eigentümer:

Code: Alles auswählen

chown -R ralph:ralph 8bea453e-8b83-499a-8ec0-b94e2582ad47

und starte den Rechner neu. Bitte um Bestätigung, ob ich bis hier alles richtig gemacht habe.

Nach erfolgten Neustart befülle ich das Subvolumen mit Daten.

Nun mache ich einen snapshot:

Code: Alles auswählen

btrfs subvolume snapshot dokumente dokumente-snapshot

Jetzt möchte ich das Subvolume dokumente löschen, um den snapshot zurück zu rollen. Wie gehe ich hier vor? Reicht es, im Nautilus den Inhalt des Ordners dokumente zu löschen oder muß ich den gesammten Ordner löschen oder muß ich sogar das Subvolume dokumente löschen? Was ist die richtige Vorgehensweise?

Und wie rolle ich den vorher gemachen snapshot zurück, um zu sehen ob es funktioniert bei mir. Ich bitte um Unterstützung, weil ich es hier nicht ganz verstehe.

Danke, Gruß ralli

[schorsch_76]

Snapshot zurück Rollen ist einfach.

Code: Alles auswählen

unmount filesys
mv filesys filesys.old
btrfs subvol snapshot filesys-20221101 filesys
mount filesys

[ralli]

Snapshot zurück Rollen ist einfach.

Code: Alles auswählen

unmount filesys
mv filesys filesys.old
btrfs subvol snapshot filesys-20221101 filesys
mount filesys

Hallo Georg,

Danke!

Gruß ralli

[ralli]

So, ich habe einige Entscheidungen getroffen. Als erstes bleibe ich bei Btrfs, weil COW und bereits im Kernel. Snapshots sind mir nicht so wichtig, weil sie eh kein Backup ersetzen. Somit brauche ich dann wohl auch keine Subvolumes auf meiner Datenplatte, Ich kennzeichne jetzt den Thread mit gelöst.

Gruß ralli