ZFS vs BTRFS - Filesystem | Deduplizierung und Snapshots

This page is also available in English

Auf der Suche nach Dateisystemfeatures wie Snapshots oder Deduplizierung, bin ich bei den Dateisystemen ZFS und später bei BTRFS gelandet. Im Linuxumfeld ist das Dateisystem ext4 zwar derzeit ein quasi Standard, Dateisysteme wie ZFS und BTRFS bieten aber einen erheblichen Mehrwert.

Als Beispiel k√∂nnen, beim Einsatz von ZFS oder BTRFS, mehrere Disken einen Pool bilden. Mittels Raid ist der Pool vor dem Ausfall einer Platte gesch√ľtzt und der Speicherplatz kann mittels zus√§tzlicher Festplatten jederzeit erweitert werden.¬†¬†

BTRFS ist direkt in den Linux Kernel integriert und wird, im Gegensatz zu ZFS, nicht per Kernel Modul geladen. 

Linuxbenutzer haben bei der Wahl des Dateisystems mehrere M√∂glichkeiten. F√ľr Windowsbenutzer stellt sich diese Frage nicht, hier ist die Wahl des Dateisystems mit NTFS zu beantworten. NTFS wurde im Laufe der Jahre um Features erweitert, f√ľr die es urspr√ľnglich nicht konzipiert wurde. So kann NTFS mittlerweile komprimieren, verschl√ľsseln und per ‚ÄěVolume Shadow Copy‚Äú Snapshots erstellen. Im Windows Server wurden Features wie Storage Spaces, der gemeinsame Zugriff von mehreren Servern auf ein Volume (Cluster Shared Volume: Hyper-V) und Deduplizierung dazugebaut. Die Deduplizierung ist im Falle von NTFS nicht Inline, sie erfolgt per geplanten Task im Nachhinein.

Copy on Write (COW)

Sowohl ZFS als auch BTRFS sind, im Gegensatz zu NTFS, Copy on Write Dateisysteme. Bei Copy-On-Write Dateisystemen werden ge√§nderte Bl√∂cke nicht √ľberschrieben, sondern in den freien Platz geschrieben und im Anschluss in den Metadaten aktualisiert. Dadurch k√∂nnen Snapshots einfacher realisiert werden. Ein¬†Snapshot¬†repr√§sentiert¬†das Dateisystem zu einem fr√ľheren Zeitpunkt. Snapshots sind also Momentaufnahmen des Dateisystems zu einem bestimmten Zeitpunkt. Aus logischer Sicht ersetzen Snapshots die Notwendigkeit eines¬†Backups. Um sich vor einem Hardwareausfall oder einem defekten Dateisystem zu sch√ľtzen, sollte¬†nat√ľrlich trotzdem ein Backup angelegt werden, auch wenn die¬†in ZFS und BTRFS integrierte Raid-Funktionalit√§t bei Verwendung mit zwei¬†oder mehreren Festplatten vor dem Ausfall einer Festplatte¬†sch√ľtzt.

(Inline-)Deduplizierung

Deduplizierung bedeutet, dass das Filesystem Blöcke die bereits auf den Datenträger geschrieben wurden, nicht erneut schreibt, sondern darauf referenziert.
Werden ein und derselbe Ordner mehrfach kopiert, benötigt dieser nur soviel Platz, wie ein Ordner beansprucht, da die Blockmuster bereits mit dem ersten Ordner abgelegt wurden.

Die meisten Filesysteme können diesen Vorgang im Nachhinein per geplantem Task erledigen, einige wenige Dateisysteme erledigen die Deduplizerung während des Schreibvorganges, also Inline: Inline Deduplizierung. Eine Inline Deduplizierung benötigt mehrheitlich relativ viel Systemressourcen, also RAM und CPU Performance.

ZFS

ZFS ist ein Copy-on-Write Filesystem welches prim√§r f√ľr SUN Solaris entwickelt wurde. ZFS wurde sp√§ter auf FreeBSD portiert und mittels des Kernel-Modules ‚ÄěZFS on Linux‚Äú auch f√ľr Linux zug√§nglich gemacht. ZFS bietet eine integrierte RAID-Funktionalit√§t, inkludiert einen eigenen Volume Manager und unterst√ľtzt Dateisysteme bis 16EiB. Das Dateisystem kann jederzeit mit zus√§tzlichen Disken erweitert werden. Neben Features wie einer transparenten Komprimierung, Pr√ľfsummen und Snapshots, bietet ZFS auch die M√∂glichkeit einer Inline-Deduplizierung.¬†

Aufgrund dieser M√∂glichkeiten habe ich ‚ÄěZFS on Linux‚Äú mit Ubuntu getestet.¬†

Bei aktiver Inline-Deduplizierung hatte ich mit ZFS das Problem, dass das Filesystem bei größeren Kopiervorgängen 100% CPU beanspruchte, die Performance langsamer wurde und der Rechner dann nicht mehr reagierte. Man sollte an dieser Stelle aber nicht vergessen, dass die meisten anderen Dateisysteme diese Möglichkeit gar nicht bieten.

Laut einigen Berichten im Internet sollte ein ZFS Volume nur bis 80% gef√ľllt werden, da die Performance ansonsten massiv schlechter wird.¬†Zudem hatte ich mit ZFS Probleme mit dem Standby. Beim Aufwachen des Computers konnte dieser ab und zu das ZFS Volume nicht mehr laden, selbst beim Herunterfahren blieb der Computer dann h√§ngen. Aufgrund dieses Mankos hab ich nach alternativen Dateisystemen mit einem √§hnlichen Featureset gesucht und bin mit BTRFS f√ľndig geworden.

BTRFS

BTRFS ist mittlerweile fixer Bestandteil des Linuxkernels und wie auch ZFS, ein Copy-On-Write Filesystem. BTRFS bietet, mal abgesehen von der M√∂glichkeit einer Inline Deduplizierung, beinahe alle Features von ZFS. Zu diesen geh√∂ren eine integrierte RAID-Funktionalit√§t, ein inkludierter Volume Manager und die Unterst√ľtzung von Dateisystemen bis 16EiB. Die Funktionen umfassen eine transparente Komprimierung, Pr√ľfsummen und Snapshots. Die Deduplizierung funktioniert derzeit nur per Befehle im Nachhinein. BTRFS ist extrem flexibel beim Erweitern. So k√∂nnen zum Beispiel im Nachhinein jederzeit Disken zum Pool hinzugef√ľgt oder wieder weggenommen werden. Dabei ist es auch m√∂glich in einem Raid unterschiedlich gro√üe Disken zu verwenden, da BTRFS das Raid nicht auf Disk ebene, sondern auf Chunkebene erstellt. Im Falle von Raid1 bedeutet das im Detail, dass immer 1Gbyte gro√üe Chunks auf jeweils eine andere Festplatte gespiegelt werden. Damit die Daten vor dem Ausfall einer Disk gesch√ľtzt sind (Raid1), wird ein Chunk immer gleichzeitig auf zwei verschiedene Disken abgelegt. Werden unterschiedlich gro√üe Disken eingesetzt, versucht BTRFS dabei den F√ľllstand der unterschiedlich gro√üen Disken immer gleich zu halten, gro√üe Disken werden dementsprechend oft beschrieben, kleine weniger. Die Kapazit√§t halbiert sich beim Einsatz von Raid1. (siehe z.B.¬†http://jrs-s.net/2014/02/13/btrfs-raid-awesomeness/)

BTRFS und Raid5/6

Das Raidlevel kann mit BTRFS online geändert werden, Raid 5 und Raid 6 ist derzeit im produktiven Einsatz aber immer noch nicht zu empfehlen:

Aktueller Status Reliabillity Scrub + RAID56 Stability: mostly OK

Aktueller Status Block group profile Stability: Unstable

siehe: btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

Backup und Dateiversionen

Meine Beweggr√ľnde f√ľr ein alternatives Dateisystem resultieren aus den Anforderungen an das¬†Backup. Nach meiner Vorstellung sollte ein Backup folgende Punkte abdecken:¬†

  • Den Schutz vor dem L√∂schen oder √úberschreiben von Dateien
  • Schutz vor dem Ausfall einer Festplatte
  • Schutz vor dem kompletten Ausfall des PCs

Details dazu in folgendem Artikel: Backup Lösung 

Als Backup verwende ich unter anderem das Commandlinetool Rsync.¬†Rsync kopiert beim Starten des PCs alle √Ąnderungen der Originaldaten auf meine externe Festplatte.

Bei genauerer Betrachtung hat diese Backupstrategie einen entscheidenden Haken: √Ąndere oder l√∂sche ich Daten werden diese auch im¬†Backup ge√§ndert oder gel√∂scht. Dieses¬†Setup sch√ľtzt strenggenommen nur vor dem Ausfall der Quellfestplatte, nicht aber vor logischen Fehlern.

Kopiere ich mit rsync mehrere Versionen in verschiedene Ordner, wird die Platte irgendwann voll sein. Ich w√ľrde also¬†verschiedene Versionsst√§nde mit zus√§tzlichen Festplatten bezahlen m√ľssen.

√Ąhnlich ist das Problem bei Verwendung eines Backupprogramms mit Full und Incrementellen Sicherungen, auch hier bekomme ich fr√ľher oder sp√§ter ein Platzproblem, da die Daten nach jeder Vollsicherung doppelt auf meiner Backupplatte liegen.

Mit einem modernen Dateisystem kann das Platzproblem sehr einfach gelöst werden, entweder durch Deduplizierung der Daten oder noch besser durch Snapshots.

Schauen wir uns die erste Variante an:

Deduplizierung

Bei einer Deduplizierung werden Datenbl√∂cke nur einmalig abgelegt und dann mehrfach verwendet. Wird also dieselbe Datei oder eine Datei mit √§hnlichem Bitmuster auf dem Datentr√§ger abgelegt, werden bereits vorhandene Datenmuster auch f√ľr die neu Datei verwendet. Dateien, die sich bereits auf dem Datentr√§ger befinden, ben√∂tigen beim erneuten Ablegen auf diesen keinen zus√§tzlichen Speicherplatz.

F√ľr mein Backup w√ľrde das bedeuten, dass ich meine Daten immer wieder auf das Backuplaufwerk kopiere. F√ľr jeden Kopiervorgang k√∂nnte ich dazu einen eigenen Ordner verwenden und diesen laut Datum benennen. Die Deduplizierung sorgt daf√ľr, dass nur ge√§nderte Daten zus√§tzlichen Speicherplatz ben√∂tigen. Der Ansatz ist schon nicht schlecht, ben√∂tigt aber f√ľr jeden Kopiervorgang Zeit, CPU, Memory und Harddiskperformance. Aus diesem Grund bin ich bei Snapshots gelandet:

Snapshots und Backups

Snapshots bieten die M√∂glichkeit, verschiedene Versionsst√§nde des Dateisystems zu behalten. Dies l√∂st das Problem meines urspr√ľnglichen Rsync Backups.¬†Ich¬†kann beim Einsatz von Snapshots folgende Backupstrategie umsetzten:

Rsync kopiert mir s√§mtliche Daten auf einen Backupdatentr√§ger. Nach dem initialen Kopiervorgang m√ľssen nur noch √Ąnderungen √ľbertragen werden(Inkrementel). Der Backupdatentr√§ger spiegelt den Zeitpunkt des letzten Backups wider. Wenn jetzt nach jedem Kopiervorgang ein Snapshot erstellt wird, hab ich die M√∂glichkeit auch auf √§ltere Backups zuzugreifen. Meine Daten w√§ren somit nicht nur vor dem Hardwareausfall, sondern auch vor einem unabsichtlichen L√∂schen oder √úberschreiben gesch√ľtzt.

Eine mögliche Backupstrategie

Mal angenommen der Rechner wird als primäres Speicherziel verwendet, können beim Einsatz von BTRFS automatisch und regelmäßig Snapshots erstellt werden. Die Daten können zusätzlich automatisiert auf einen NAS kopiert werden (z.B. mit rsync). 

Beim Einsatz von Raid1 ist das Prim√§rdateisystem vor dem Ausfall einer Festplatte gesch√ľtzt.

Die Snapshots sch√ľtzen vor dem L√∂schen oder √úberschreiben von Dateien;

die Kopie auf ein anderes Gerät, vor dem Ausfall des Dateisystems oder der kompletten primären Hardware. 

Sie dazu auch das Thema:  Backup Strategie

 

 

positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE f√ľr deine Bewertung!

Aktualisiert: 17.08.2020 von Bernhard ūüĒĒ


Top-Artikel in diesem Bereich


L√ľftersteuerung Linux Debian: Fancontrol
Nachdem ich in meinem NAS einen L√ľfter eingebaut habe, ist dieser immer mit h√∂chster Geschwindigkeit gelaufen. Im BIOS konnte ich die Geschwindigkeit zwar einstellen, der Automatik-Modus wollte aber nicht so richtig funktionieren. Mittels des Services fancontrol kann die Geschwindigkeit des L√ľfters mit einem beliebigen Sensor und beliebigen Schwellwerten verkn√ľpft und automatisch gesteuert werden.

Debian / Ubuntu: Setup f√ľr das Versenden von Mails aus dem Terminal
Einstellungen um aus dem Terminal oder aus crontab Mails versenden zu können

Debian / Ubuntu / OMV: HD-Idle: HDD Standby
Nachdem sich meine Festplatten nach der eingestellten Zeit nicht oder zu fr√ľh in den Standby-Modus (Spin-Down) bewegen wollten, habe ich nach einer Alternative zum Energiemanagement der HDDs gesucht.

Fragen / Kommentare


(sortiert nach Bewertung / Datum) [alle Kommentare(neueste zuerst)]

‚úćanonym
15.07.2016 18:06
User: Bernd 
Nichts gegen BTRFS, aber BTRFS ist nur Dateisystem. ZFS ist Poolverwaltung und Dateisystem in einem. Die Vorgehensweise bei einem Spiegel ist gegen√ľber ZFS komplett anders. BTRFS nutzt eine Art RAID0 Verbund um Spiegelungen auf Dateiebene zu realisieren. Meiner Meinung nach ist sowas unsinnig. Sp√§testens wenn man dann noch zuk√ľnftig bei BTRFS Dinge wie dateiorientierte Redundanzen realisieren kann, diese Datei bitte redundant halten und diese bitte nicht. Welcher Anwender soll dann noch bei Snaphshots durchblicken?

Sehe Dir mal folgendes Video an: (https://www.youtube.com/watch?v=VlFGTtU65Xo) und sehe Dir mal an, wieviel Mehraufwand bei BTRFS anhand der Befehle notwendig w√§re. F√ľr mich ist BTRFS derzeit zu ZFS nur in Bruchteilen vergleichbar.

PS: Deduplikation sollte mal vermeiden. Es bringt wirklich nur in Sonderf√§llen Vorteile. Deine Gr√∂√üenangabe von etwa 5 - 15% sind typische Werte. Daf√ľr blockiert man massiv seinen Hauptspeicher mit Deduplikationstabellen.

‚úćanonym
17.08.2016 17:24
User: Ikem 
An Ext4 Snapshots wird gearbeitet. Das dazu passende Projekt heisst "Next4".

‚úćanonym
23.07.2018 12:28
User: J .Schwender 
BTRFS ist ebenso als Kernelmodul möglich wie jedes andere FS.
Deduplizierung wird allgemein √ľbersch√§tzt und inline ist Deduplizierung eher eine absurde Idee, da der Speicherverbrauch mit der Anzahl der Dateien extrem steigt, genauso der Vergleichsaufwand und dadurch sehr schnell zum Bremsklotz wird. Und ausgerechnet dies soll ein Mittel zur Reduktion des Aufwandes durch die steigende Anzahl von Dateien sein? Zudem erzeugen eine beachtliche Anzahl der verwendeten Dateitypen aufgrund von Kompressionsverfahren keine gleichen Bl√∂cke (MP4, JPG, DOC, XLS, ODT....). 

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details