ZFS vs BTRFS - Filesystem | Deduplizierung und Snapshots

 

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!

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