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