Autor: Torsten

Die Ausgangslage

Nachdem ich mir einen neuen VPS (Virtual Private Server) angemietet habe, der ausschließlich auf SSDs setzt, ist die Schreib- / Leseperformanz zwar deutlich besser als vorher mit HDD aber SSD Speicherplatz ist nach wie vor teurer als klassische Festplatten. Somit sind VPS Server die auf SSD basieren teurer bzw. andersrum gibt es für das gleiche Geld deutlich weniger Speicherplatz. Bei Contabo ist der angebotene Speicherplatz ca. halb so groß wie bei den HDD Servern.

Somit hat sich mir die Frage gestellt, wie ich von dem alten Server mit 1,4 TB Speicherplatz auf einen Server mit 800GB umziehen kann ohne zu viel Sicherheit / Komfort zu verlieren.  Voll war der Server nicht aber es waren über ca. 950 GB belegt.

Ein guter Teil des Speicherplatzes auf dem Server ist von Backups belegt, die man auf einem Server unweigerlich benötigt, gerade auch wenn man mal etwas testet / ausprobiert. Neben dem Buchblog sind auf dem Server auch diverse andere Dienste. Der Blog nimmt eher den kleinsten Teil ein. Oft fallen Fehler auch nicht direkt auf, weil man nicht jede Funktion täglich nutzt. Somit schadet es nicht auch mal einen alten Stand einsehen zu können? War das schon immer so? Wie war es wann?

Backups aber wie?

Tägliche Backups speichern in der Regel von Tag zu Tag das gleiche (es ändert sich ja kaum was, wenn man zum Beispiel auf dem Blog ein oder zwei Beiträge verfasst). Viele Backuplösungen in Linux basieren auf Rsync. Rsync ist ein sehr gutes Tool zum synchronisieren zwischen zwei Verzeichnissen und bietet Funktionen wie Resuming / Checksummenprüfung usw. mit. Für Backups ist es aber nur bedingt geeignet, weil es die Daten einfach x Mal neu anlegt.

D.h. es werden bei einem Backupsystem (z.B. Daten der letzten 3 Tage, vorherigen 2 Wochen, letzten 2 Monate, letzte 2 Jahre = 3+2+2+3 = 10 facher Platz der Daten). Wenn man 50GB sichert, dann sind das mal eben 500GB nur für Backups. Dafür ist SSD Speicherplatz eigentlich zu schade.

Alternativ bieten sich Backuplösungen an, die Daten komprimieren. Diese lassen sich jedoch schlechter lesen. Einige Varianten müssen erst entpackt werden. Auf Linux gibt es z.B. Tar in Kombination mit einem Packverfahren. Das ist mit einer SSD und nicht zu großen Files ganz erträglich. Ein direkter Zugriff auf einzelne Dateien ist aber ziemlich unpraktisch, weil die ganze Datei gelesen werden muss (das ist der Teil wo die SSD durch höhere Leseraten den Prozess halbwegs erträglich macht). Wenn so eine große Datei beschädigt wird, kann es aber auch sein, dass das ganze Backup nicht mehr lesbar ist.

In einer grafischen Umgebung dauert das Öffnen zwar eine Weile ist aber von der Bedienung ansonsten erträglich. Wenn man auf der Kommandozeile arbeitet, wird es aber ziemlich unschön, weil es nicht einfach möglich ist Verzeichnisse zu entpacken oder ähnliches durchzuführen. Im schlimmsten Fall muss man also alles auspacken. Das benötigt Zeit und Speicherplatz.

Es gibt auch weitere Lösungen wie z.B. Bacula, was aber recht aufgebläht ist (ein Webfrontend – das benötigt also einen Webserver – für eine Backuplösung finde ich zum Beispiel ziemlich unglücklich). Im Zweifelsfall kommt man nur noch mit einer Rescuecd an den Server und dann sollte das Restore einfach sein.

Zusätzlich ist die Lösung halbkommerziell. Man kann sich also soweit ich das gesehen habe nicht einfach die aktuelle Version per apt install ziehen ohne einen Key dafür zu haben. Bei der 9.4er Version hat bei mir die Installation in Ubuntu 20.04 nicht funktioniert. Auch das ist nicht vertrauensbildend aber Ubuntu 20.04 holpert eh noch an so einigen Stellen aktuell.

Filesystem zur Backupunterstützung?

Ich hatte schon vor einer Weile von Dateisystemen wie BTRFS / ZFS angesehen aber die Guides zu dem Thema sahen nicht so einfach aus und die diversen Anmerkungen dies oder jenes ist nicht stabil oder “ich würde es nicht produktiv verwenden”, haben mich immer wieder abgehalten.

Für Btrfs spricht, dass es Komprimierung unterstützt. Das heißt die Dateien werden zum Teil deutlich kleiner, als im Original, sind aber transparent zugreifbar. Man benötigt keine extra Werkzeuge und kann direkt per Kommandozeile die Dateien zugreifen, ohne mit zusätzlichen Programmen / Befehlen zu hantieren (so als wenn sie nicht komprimiert wären). Zusatznutzen ohne Komforteinbußen hört sich immer gut an.

Weiterhin beherrscht Btrfs die Deduplizierung. In Obigem Fall von 10 Kopien wird also nur 1/10 des Platzes belegt, wenn sich die Daten nicht geändert haben. Wenn sich die Daten drei mal geändert haben dann eben 3/10 (ausgehend von ca. gleicher Gesamtgröße). Man steht also in Kombination mit der Komprimierung immer noch deutlich besser da.

Mein Backup mache ich mit Timeshift / Backintime. Beides sind Werkzeuge, die auf RSYNC basieren. In Kombination mit einem Filesystem wie BTRFS oder ZFS führ das aber in der Theorie zu einer deutlichen Verringerung des belegten Speicherplatzes. Die Komprimierung liegt ca. bei dem Faktor 2,5 bis 3. Allerdings werden nur bestimmte Datentypen komprimiert.

Ein weiterer Vorteil, der mich aktuell nicht interessiert ist die Snapshotfunktion. Diese Funktion hat mein Server über die SSDs bereits eingebaut. Ich kann also über den VPS 3 Snapshots erzeugen und zu diesen Ständen zurückkehren.

Diese Funktion werde ich ggf. Später testen. Die Snapshotfunktion ist z.B. interessant, wenn man ein neues Betriebssystem installiert und dabei geht etwas schief. Man kann damit sehr leicht und schnell zu einem vorherigen Stand zurückkehren. Beim Test von Ubuntu 20.04 hätte mir die Funktion wohl einen Tag Arbeit erspart. Mittlerweile habe ich es installiert aber ohne Snapshots (in meinem Fall direkt auf dem SSD Server, hätte ich das definitiv nicht gemacht).

Welches darf es den sein ZFS oder Btrfs?

Die oben genannten Funktionen bieten sowohl ZFS als auch Btrfs. Btrfs ist allerdings bei meinem VPS anbietet bereits in der Rescue CD integriert. Weiterhin bietet das auf der Rescue CD integrierte Pratitionierungswerkzeug Btrfs an und Btrfs bietet eine Migration von Ext4 nach Btrfs an. Besonders letzterer Aspekt klang reizvoll.

Da ich vorher einen Snapshot erstellt hatte, habe ich die Migration gestartet und nach grob 4-5 Stunden (auf einer SSD! – nur ca. 30-40MB pro Sekunden und nur ein Kern der CPU benutzt) war die Migration durch. Danach habe ich das Laufwerk gemountet und dann beim Boot diverse Fehlermeldungen bekommen. Scheinbar ist das mit dem Migrieren doch nicht so einfach wie versprochen. Die Warnung vorher Backups durchzuführen ist also absolut ernst zu nehmen.

Das Vertrauen in Btrfs und die Migrationsfunktion war bereits gesunken aber dank Snapshot habe ich einen zweiten Versuch gestartet. Der ist schon viel früher abgebrochen. Somit stand für mich fest, die Migration kann man vergessen. Theoretisch soll man die auch rückgängig machen können aber da ich einen Snapshot hatte, habe ich das gelassen.

Somit bin ich zu Ansatz zwei übergegangen. Eine neue Partition mit Btrfs zusätzlich zur vorhandenen

Nach den obigen Migrationsversuchen war das Vertrauen in Btrfs deutlich geschrumpft aber ganz ehrlich: Ich habe noch nie eine erfolgreiche Migration von einem Dateisystem in ein andres gesehen.

Backup mit Btrfs

Mein Hauptfokus lag auf der Verkleinerung der Backups also lag es nahe einen Teil der 800GB als Bbtrfs Partition anzulegen. Somit habe ich über das Rettungsystem Gparted gestartet und 200GB in Btrfs umgewandelt. Dort habe ich mehrere Subvolumes angelegt (Backintime, Timeshift, Root – für einen späteren Boottest, Snapshot – für spätere Snapshottests), dort kann man wiederum ein weiteres Subvolume für jedes Subvolume anlegen, von dem man Snapshots erstellen will).

Die Trennung der Snapshots hat damit zu tun, dass man die beim Zurücksetzen eines anderen Snapshots nicht verlieren möchte. Somit sollten man die separat halten.

Wichtig ist, dass man beim Mounten (ich habe direkt die Variante über die fstab Einbindung genutzt) die Komprimierung aktiviert. Die Daten werden dann während des Schreibens gepackt. Das komprimieren geht auch nachträglich, ist aber aufwendiger. Das Aktivieren der Komprimierung auf oberster Ebene hat sich auf die Subvolumes vererbt.

Anschließend kann man die Daten ganz normal auf das Laufwerk schreiben, dass in das Dateisystem eingebunden wird (in meinem Fall Verzeichnis btrfs mit den o.g. Unterverzeichnissen / Subvolumes).

Das Ergebnis vom Packen war bereits vielversprechend. Die Daten werden deutlich geschrumpft. Allerdings packt Btrfs mit den Standardeinstellungen nur die Daten, bei denen es eine deutliche Einsparung erwartet. Dateien bei denen das nicht der Fall ist, werden nicht gepackt. Man kann das erzwingen aber das habe ich bisher nicht getestet.

Der zweite Schritt ist das Deduplizieren. Das macht Btrfs nicht beim Schreiben, sondern man kann es nachträglich ausführen. Interessant ist dabei, dass man für jedes Subvolume einzelne Snapshots erstellen kann aber das Deduplizieren volumeübergreifend funktioniert.

Was bringt’s?

Bei obigem Beispiel würde also bei moderater Datenänderung zwischen 1/10 (Bester Fall fast ohne Änderungen der Daten) und 1/2 (bei deutlich mehr Änderungen) der Daten übrig bleiben. Wie sich in meinem Fall gezeigt hat sind es etwas mehr als 1/4.

Die o.g. Zahlen verstehe ich so:

Ursprünglich wurden durch die Daten 314GB belegt. Fast die Hälfte der Daten wurde komprimiert (152GB). Die komprimierten Daten hatten nach der Komprimierung noch ca. 1/3 der vorherigen Größe (das passt auch zu den Messungen die ich im Netz gefunden habe).

Der zweite Effekt ist die Deduplizierung, die in einem Backupszenario extrem gut funktioniert. Effektiv werden die vorher 314GB auf 86GB gespeichert. Das ist nicht schlecht dafür, dass ich den geringsten Kompressionslevel (ZSTD1) verwendet habe ohne erzwungene Komprimierung.

Es kann sein, dass man noch etwas mehr rausholen kann allerdings steigt die Rechenzeit dafür überproportional an. Sollten über die Komprimierung noch mal 5GB eingespart werden können, wird das ziemlich lange dauern bzw. zu sehr geringen Schreibraten führen. Den Effekt der erzwungenen Komprimierung kann ich nicht abschätzen.

Die Performanz beim Schreiben kann ich nicht wirklich bewerten, weil es sich um ein VPS handelt und die Performanz dort naturgemäß geteilt ist. Teilweise waren es 200MB, teilweise auch nur 50MB/s. Die Schreibgeschwindigkeit mit Komprimierung ist natürlich nicht so hoch wie z.B. bei ext4 ohne Komprimierung.

Die Frage ist was limitierend ist (wenn es die Schreibleistung der SSD / HDD ist, dann kann Btrfs schneller sein als ext4, wenn es die Rechenleistung des Prozessors ist, dann wird eher das Gegenteil der Fall sein, wenn man die Komprimierung verwendet).

Man möge mich korrigieren, wenn ich mit obigen Annahmen falsch liege aber meine Einschätzung der Daten oben deckt sich ca. mit der Ersparnis, sollte also richtig sein.

Ist Btrfs stabil?

Das wird die Zeit zeigen. Ich gehe im schlimmsten Fall das Risiko ein meine Backups zu verlieren. So lange ich nicht gleichzeitig die Originale kaputt mache, ist das Risiko begrenzt. Zumal ich bei dem SSD Server nun zusätzlich Snapshots anfertigen kann und somit (sofern ich denn vorher einen Snapshot erzeugt habe) auf diesen Stand zurückkehren kann. Das Risiko sollte also begrenzt sein.

Die Funktionen, die nicht stabil waren scheinen aber bereits vor zwei Jahren angepasst worden zu sein. Die Probleme bezogen sich auch primär auf Raid 5 / 6. Ich benutze kein Raid.

Aktuell konnte ich aber auch nicht erkennen, dass die Entwicklung voran getrieben wird oder zumindest kommunizieren die Entwickler das nicht. Die arbeiten offenbar eher im stillen Kämmerlein für sich selbst.

Somit sind die Guides alle nicht aktuell und vieles von dem was man dort findet ist veraltet. Einige Einstellungen sind überholt oder werden nicht mehr unterstützt.

Andersrum sind Werkzeuge wie die Deduplizierung nicht direkt integriert, sondern funktionieren über zusätzliche Tools, die oft auch mit nicht vertrauenserweckenden Kommentaren versehen sind (sollte funktionieren, sollte fehlerfrei sein). Der typische Informatikerkonjunktiv. Die Versionsstände sind oft alles andere als hoch 0.1x. Aber das muss alles nichts bedeuten. Bisher läuft es rund aber nach einer Woche ist das noch nicht viel Wert. 😉

Ein detailliertes How to zur Einrichtung von Btrfs in Kombination mit Luks Verschlüsselung habe ich ein einem separaten Blogpost erstellt.

Nachtrag 02.05.2020 – 22:00

Ich habe jetzt auch den Boot von Btrfs hinbekommen. Dafür habe ich mithilfe des Grubcustomizer einen neuen Booteintrag erzeugt und dort einfach die ID der Btrfs Partition angegeben und das entsprechende Subvolume. Die UUID bleibt immer die der Partition (auch wenn man Subvolumes adressiert!).

Beispieleinträge in der fstab:

UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 /btrfs btrfs defaults,ssd,compress=zstd:1 0 0
UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 /btrfs/ROOT/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=422,subvol=/snapshots/ROOT_snaps 0 0

Was bedeutet das? Der Hauptknoten wird unter btrfs eingehängt. Alle untergeordneten Subvolumes werden dadurch automatisch gemountet. Der Zweite Eintrag mountet ein spezielles Subvolume auf /btrfs/ROOT/.snapshots. In der Subvolumehierarchie befindet sich das aber unter /snapshots/ROOT_snaps. Man muss immer aufpassen was Subvolumes und was Verzeichnisse sind. Im Verzeichnisbaum sieht das gleich aus.

Auch die Snapshotfunktion (zumindest das Anfertigen von Snapshots habe ich erfolgreich getestet).

Nachtrag 03.09.2020

Ich habe mittlerweile 2 Server komplett auf Btrfs umgestellt einschließlich dem ROOT Verzeichnis / Laufwerk. Somit spart man sich natürlich noch mal eine Kopie der Dateien und die Speicherung wird effizienter. Das setzt allerdings volles Vertrauen ins Dateisystem voraus.

Bisher hatte ich noch keine Probleme (auf Holz klopf), obwohl ich besonders den lokalen Sever auch schon mehrfach hart runtergefahren habe. Bei beiden Servern nutze ich keine Zusatzsoftware wie Timeshift / Backintime, sondern verwende die automatischen btrfs Snapshots über Snapper. Bei einem Server habe ich das Bootlaufwerk nicht umgestellt und nutze Btrfs nur für Backups mit Backintime und täglicher Deduplizierung.

Ich habe zwischenzeitlich auch noch Mal über ZFS nachgedacht aber die Deduplizierung funktioniert dort leider nur online und benötigt dann immens viel Speicher. Dazu kommt, dass Ubuntu zwar den Support eingebaut hat aber Tools wie gparted nach wie vor ZFS nicht anbieten. Das könnte man natürlich in der Kommandozeile lösen aber so lange mir Btrfs keinen Grund liefert, werde ich ZFS wohl nicht testen.

Weiterhin hat btrfs den Ruf nachträgliche Änderungen einfacher zu Unterstützen (z.B. Raidlevel), während bei ZFS ein Neuaufbau erforderlich ist. Bleibt noch die Aussage ZFS ist stabiler Aussage von einigen Leuten im Netz, die sich aber nicht objektiv untermauern lässt. Das hängt wohl auch immer von Versionen und Setup (z.B. Raid ja oder nein und wenn ja welcher Level) ab.