Btrfs

marco_f

Commander
Registriert
Mai 2013
Beiträge
2.467
Hallo an die Experten :)!

Ich habe einen Raspberry Pi 4 und will auf einer USB-Festplatte Nextcloud Daten abwerfen lassen. Als Dateisystem habe ich mir Btrfs ausgepickt, weil es eine hohe Datenintegrität (inkl. Selbstheilung?) habe soll. Nun kann ich weder auf meinem Raspberry Pi 4 (Betriebssystem Raspberry Pi OS Bookworm) in GParted eine Partition mit Btrfs noch auf meinem PC mit Kubuntu 24.04 im KDE-Partitionsmanager eine Partition mit Btrfs erstellen. Hat jemand einen Tip warum? Fehlen mir Pakete? Und läuft Btrfs inkl. aller Features auf dem Raspi nach der Erstellung der Partition auch. Insbesondere die permanente Prüfung der Datenintegrität und ggf. Heilung sind mir wichtig. Performance ist mir relativ egal - es sollen Fotos von meinem Handy dort gedumpt werden und später auf einer zweiten Nextcloud in einem anderen Haushalt in der Familie gespiegelt werden.

Danke für dienliche Tipps :)!
 
Geht ein Dateisystem nur für eine Partition?
Oder muss das ganze Volume in dem jeweiligen Dateisystem formatiert sein?

Ich kenn mich mit Linux oder RPi nicht aus.
Bei Synology kann man nur ganze Volumes mit BTRFS nutzen.
 
btrfs-progs ist aber schon installiert, falls das die Frage ist?

Und was selbstheilung und so angeht. Hab backups.
 
  • Gefällt mir
Reaktionen: guzzisti, TomH22, Das MatZe und eine weitere Person
Wenn es dir nur um die Intigrietät der Daten geht, wäre eine Regelmäßig erstellte Liste mit Hashes besser*, Selbstheilung funktioniert naturgemäß nur bei RAID (egal ob ZFS, BTRFS oder dm-verity) RAID hat seine ganz eigene lange Liste mit Problemen

Wenn der Hash nicht mehr stimmt holt man die Datei aus dem Backup.

Ich würde zu der Hash Liste + Plus Backup auf mindestens 2 Datenträgern mit unterschiedlichem Dateisystem und Speichertype (SSD, HDD, BluRay usw) raten, denn wenn bei einem Dateisystem etwas schief geht, helfen auch die besten Integritäts und Selbstheilungsfunktionen nix. (Hier z. B. ZFS)
 
Zuletzt bearbeitet:
Die Hashes auf Dateien sind absoluter Sackgang, wenn Nextcloud die Dateien verwalten soll. Zudem ist es etwas sinnig Dateien zu hashen, wenn BTRFS sowieso schon Hashes auf Blockebene berechnet. Ohne Raid kann BTRFS mindestens feststellen, dass es eine Diskrepanz zwischen Hash und Datenblock gibt. Das ist aber auch nur praktisch, wenn aktives Monitoring betrieben wird und das System nach Möglichkeit entsprechende Fehlermeldungen aktiv an die Administration kommuniziert.

Ansonsten schau, dass das Laufwerk nicht irgendwo gemountet ist und dann klassisch mfs.btrfs ohne Umwege: https://wiki.ubuntuusers.de/Archiv/Installieren_auf_Btrfs-Dateisystem/#Der-mkfs-btrfs-Befehl
 
  • Gefällt mir
Reaktionen: madmax2010
Piktogramm schrieb:
Das ist aber auch nur praktisch, wenn aktives Monitoring betrieben wird und das System nach Möglichkeit entsprechende Fehlermeldungen aktiv
Und genau da scheitert es... Du brauchst eh einen Mechanismus die Daten zu sichern, da baut man einen schritt ein der die Hashes erzeugt und gegen die alten verglichen wird, die gleichen Hashes können dann auch genutzt werden um festzustellen was gesichert werden muss, rsync und rclone machen z. B. Genau das mit --checksum, letzteres kann auch Nextcloud als Ziel / Quelle.

Oder wie ich es bei mir gemacht habe --ignore-existing + --checksum, damit werden geänderte einfach nicht mit übernommen, wenn man (wie ich) weiß das die Originale sich niemals verändern, sehr hilfreich.
 
Zuletzt bearbeitet:
An der Stelle kann man sich dann mal mit btrfs snapshots und btrfs send/recieve beschäftigen. Deine Lösung ist quasi Teil des Dateisystems.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen und madmax2010
BTRFS prüft die Integrität der Dateien mittels Checksummen. Diese werden beim Schreiben erstellt und bei jedem Lesen geprüft. Dabei werden nicht nur normale Daten (reguläre Dateien) sondern auch Metadaten (Verzeichnisstruktur, Zeitstempel etc.) mit Checksummen versehen. Kommt es beim Lesen zu einem Missmatch der Prüfsummen, gibt BTRFS einen Fehler an das anfordernde Programm zurück. BTRFS verhindert also, dass fehlerhafte Daten gelesen werden können.

Für die Selbstheilung benötigst du mindestens zwei Festplatten, welche als BTRFS-RAID 1 miteinander verknüpft werden. Kommt es nun zu einem Missmatch der Checksummen, liest BTRFS die Daten von der anderen Festplatte aus. Sind diese korrekt, repariert BTRFS die fehlerhafte Daten auf der ersten Festplatte und gibt die korrekten Daten an das aufrufende Programm zurück.

Für eine regelmäße Prüfung der Datenintegrität führt man einen sogenanten Scrub durch. Dieser ließt einmal alle Daten des Dateisystems aus und prüft alle Checksummen.

Um Backups zu machen bieten sich BTRFS-Snapshots an. Ein Snapshot stellt einen atomaren Stand eines BTRFS-Subvolume dar. Diesen Snapshot kann man dann mittels BTRFS send/receive auf eine Backup-Platte (idealerweise auch mit BTRFS formartiert) übertragen. Bei Angabe eines Parent-Snapshots werden dabei nur die Daten übertragen, welche seit dem hinzugekommen/verändert wurden, was das Anlegen von Backups stark beschleunigt. Natürlich bietet es sich an, auch bei der Backup-Platte durch Scrubs die Integrität der Daten regelmäßig zu prüfen.

Hier mal das Vorgehen skizziert: Wenn du zwei Festplatten (mit je einer Partition) hast, kannst du auf diesen wie folgt ein BTRFS-Dateisystem erstellen:

Bash:
mkfs.btrfs -L storage -d raid1 -m raid1 /dev/sdx1 /dev/sdy1

Mittels -L wird ein Label vergeben, über das sich das Dateisystem leichter ansprechen lässt. -d und -m konfigurieren Raid1 für Daten und Metadaten. Nun kann das Dateisystem eingehangen werden:

Bash:
mkdir /media/storage
mount -L storage /media/storage

Anschließend legst du ein Verzeichnis Snapshots und ein Subvolume Data an:

Bash:
mkdir /media/storage/snapshots
btrfs subvolume create /media/storage/data

In dem Subvolume Data kannst du zukünftig deine Daten ablegen. In dem Verzeichnis Snapshots werden BTRFS-Snapshosts des Subvolume Data abegelgt.

BTRFS-Snapshots lassen sich dann wie folgt erstellen:

Bash:
btrfs subvolume snapshot -r /media/storage/data /media/storage/snapshots/snapshot-1

Wenn unter /media/backup eine Backup-Platte eingebunden ist, lässt sich dieser Snapshot wie folgt auf diese Platte übertragen:

Bash:
btrfs send /media/storage/snapshots/snapshot-1 | btrfs receive /media/backup

Weitere Backups von Snapshots lassen sich, solange der Vorgänger auf beiden Platten vorhanden ist wie folgt anlegen, weibei nur die Änderungen übertragen werden:

Bash:
btrfs send -p /media/storage/snapshots/snapshot-1 /media/storage/snapshots/snapshot-2 | btrfs receive /media/backup

In regelmäßigen Abständen kann man einen Scrub wie folgt machen:

Bash:
btrfs scrub start /media/storage

Der Status des Scrubs lässt sich wie folgt auslesen:

Bash:
btrfs scrub status /media/stoarge

Eine Beispielausgabe kann wie folgt aussehen:

Code:
UUID:             xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Scrub started:    Sat Apr  5 08:00:31 2025
Status:           finished
Duration:         12:06:04
Total to scrub:   13.86TiB
Rate:             333.36MiB/s
Error summary:    no errors found

Am Ende muss noch ein Eintrag in der /etc/fstab gemacht werden, damit das Dateisystem beim Start automatisch eingebunden wird:

Bash:
LABEL=storage /media/storage btrfs subvol=/,compress=zstd:1,noatime 0 0

Dabei sorgt compress=zstd:1 dafür, dass leicht zu komprimiertede Dateien komprimiert abgelegt werden und noatime sorgt dafür, dass keine Lesezeitstempel erzeugt werden. Es empfiehlt sich diese Option zu setzen. Werden diese benötigt, dann die Option relatime verwenden.
 
  • Gefällt mir
Reaktionen: morb
@jodd2021 Welche Bedenken hast du? Die Integrität prüft BTRFS standardmäßig mittels CRC32. Das bekommt sogar der PI hin. Der Flaschenhals wird der IO-Durchsatz sein. Den wirst du aber in allen Fällen haben. Ein Problem, welches ich für mein Szenario noch sehe, ist, dass drei USB-Anschlüsse benötigt werden. Wenn man auf die Selbstheilung (und damit auf die zweite Platte) verzichten kann, benötigt man nur zwei.
 
Ack der III schrieb:
Welche Bedenken hast du?

Das der PI mehr mit sich selber beschäftigt ist und die Ressourcen für seine eigentlichen Aufgaben fehlen. Die fehlenden Anschlüsse sind da auch nicht hilfreich und machen das ganze nur unnötig kompliziert. Das ganze erreicht man mit regelmäßigen Backups einfacher.
 
jodd2021 schrieb:
Das der PI mehr mit sich selber beschäftigt ist und die Ressourcen für seine eigentlichen Aufgaben fehlen.
Die Aufgaben schafft der PI locker nebenbei.

Allerdings hätte ich aus Stabilitätsgründen wohl eher Ext4 empfohlen.
 
Pummeluff schrieb:
Allerdings hätte ich aus Stabilitätsgründen wohl eher Ext4 empfohlen.
Warum? Was ist den an BTRFS nicht Stabil nutze das für quasi alles, inklusive Snapshots und RAID1, nur RAID5/6 ist halt schwierig. Weshalb dann mindestens Metadaten RAID1 sein müssen und regelmäßig gescrubt werden sollte.
 
Danke für die umfangreichen Antworten :).

Mir geht es primär darum nicht immer weiter degridierende Daten zu pflegen - die Fotos meiner ersten Digicam von vor über 22 Jahren sind in einem dermaßen miserablen Zustand - zusätzlich dazu dass sie gemäß dem damaligen Stand der Technik schon nicht besonders gut waren.
Backup ist natürlich eingeplant - Offlinebackup(ab in die Schublade danach) 1x pro Monat. Und zur Anwendung: Es geht mir primär um die Sicherung meiner Fotos von meinem Handy und evt bald auch Systemkamera. Der Pi (4) hat sonst nur noch als Pi-Hole zu funktionieren, also 24/7 Zeit sich um die Daten zu kümmern.

Frage: Meint ihr man kann die Datenintegrität auch hinbekommen indem ich auf einem Datenträger das Volume spiegele? Meine USB SSD ist 4x so groß wie ich schätze, dass ich Speicherplatz brauche.
Ergänzung ()

Eine Frage: Entweder ich bin zu blöd oder Kubuntu 24.04 hat keinen Btrfs-support mehr? btrfs-tools fehlen und in der KDE-Partionsverwaltung kommt auch die Meldung, dass dies fehlt und deshalb keine Partitionen dieses Types geändert / erstellt werden können.
In Discovery finde ich auch keine Einträge. Wie komme ich an den Support?
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
marco_f schrieb:
Frage: Meint ihr man kann die Datenintegrität auch hinbekommen indem ich auf einem Datenträger das Volume spiegele? Meine USB SSD ist 4x so groß wie ich schätze, dass ich Speicherplatz brauche.
Heikles Thema BTRFS kann es, aber wenn z. B. ein Firmware Fehler dafür sorgt das beide Versionen falsch zurückkommen, bringt es nix außerdem dürften die Kopien auf der SSD / HDD in der gleichen Page bzw direkt neben einander landen, altern tun sie natürlich auch gleich.
 
AlphaKaninchen schrieb:
Warum? Was ist den an BTRFS nicht Stabil nutze das für quasi alles,
Ich hab so einige Dateisysteme in meiner Laufbahn durch: Ext2, 3, 4, XFS, JFS, Reiser3+4, BTRFS.

BTRFS hatte ich ca. 10 Jahre lang als Root-FS auf meinem Rechner. Von den ganzen Features genutzt hab ich nur die Kompression. BTRFS hatte lange das Problem, dass die Anzeige des freien Speichers nicht korrekt. Aber ansich ist es seit einigen Jahren durchaus stabil.

Nicht gegen BTRFS aber für Ext4 spricht halt einfach die Robustheit. Irgendwelche Argumente würden dabei aber in den Bereicht der anekdotischen Evidenz fallen. Diskussionen dazu gibt's haufenweise u.a. bei Reddit.

Datenverluste hatte ich vor vielen Jahren mal mit XFS auf meinem ARM-Nas. XFS war damals nach meiner Erkenntnis nur auf x86 stabil. Mittlerweile hat sich das auch geändert.
 
Zuletzt bearbeitet:
Pummeluff schrieb:
Ich hab so einige Dateisysteme in meiner Laufbahn durch: Ext2, 3, 4, XFS, JFS, Reiser3+4, BTRFS.
Für mich würde außer XFS und BTRFS alles nicht in Frage kommen weil kein CoW, bei XFS ist das aber noch experimentell.

Meiner Erfahrung nach und entgegen einer der Posts im verlinkten Reddit Thread ist CoW auf SMR HDDs (und QLC SSDs) einfach konsistenter mit der Performance, während sie bei Journaling einbricht weil der Controller der HDD Daten hin und her kopieren muss. Unter BTRFS unterscheidet sich deren Performance kaum von CMR HDDs bzw TLC SSDs. (Die Schreibgeschwindigkeit ist natürlich langsamer, aber sie bricht nicht auf 5 MB/s ein)
 
Zuletzt bearbeitet:
Pummeluff schrieb:
Ich hab so einige Dateisysteme in meiner Laufbahn durch: Ext2, 3, 4, XFS, JFS, Reiser3+4, BTRFS.
Spannend. Ich bin immer wieder zu ext4 und zu ZFS zurückgekehrt. Btrfs konnte mich bisher nicht überzeugen. Mag vielleicht auch daran liegen, dass selbst die Distributoren sich nicht mal einig sind, ob das jetzt stabil genug ist um es zum Standard zu machen oder nicht. Vielleicht fehlt mir auch einfach die Anwendung für btrfs.

Generell kann ich - außer zu ext2 und dem frühen ext3 - zu keinem FS in über 20 Jahre etwas negatives sagen. Probleme mit korrupten Daten gab's seinerzeit naturgemäß vor allem wenn das System hart abgeschaltet werden musste weil es kein Journal gab bzw. es noch nicht so funktionierte wie erwartet. Aber ansonsten hatte ich bislang immer Glück.
 
Zurück
Oben