[PROLOG]
Hier: QuDedup: Backup Job neu verlinken - Ein Ritt ins Verderben musste ich ungewollt und erneut über das desaströse Verhalten der Backup-App HBS3 berichten, welches nach dem Verlinken mehrerer Backups nicht mehr korrekt funktionierte und mir zu allem Überfluss auch noch die bestehende Versionierung „zerschossen“ hat.
Diese Unzuverlässigkeit, vor allem bei versionierten Backups bzw. mit QuDedup, zwang mich nun auch das Verfahren für mein versioniertes Backup anzupassen. Da ich nicht erst das dritte oder vierte Mal schwerwiegende Probleme mit HBS3 habe, habe ich hier: Alternatives Betriebssystem – Backup mit OpenMediaVault auf einem QNAP NAS bereits ein zusätzliches Backup eingerichtet, welches zumindest weitgehend unabhängig von HBS3 ist.
Ein Konzept welches nun in Frage kommt bringt erneut ein alternatives Betriebssystem ins Spiel, von dem ich hier: Alternatives Betriebssystem TrueNAS: Aufrüstung und Inbetriebnahme eines TS-470U einst berichtet hatte: TrueNAS.
Die Installation von TrueNAS auf dem QNAP soll daher nicht im Vordergrund stehen, sondern vielmehr die Software selbst, mit dem Hintergrund diese als Backupsystem zu verwenden. Doch wie schon im anderen Artikel beschrieben, muss auch hier zunächst die Hardware vorbereitet werden, diesen Punkt will ich wenigstens kurz anreißen.
[GEDANKEN ZUM KONZEPT]
Um von HBS3 wegzukommen möchte ich, dass sich TrueNAS die Daten selbst holt (pull-Sync), das ist mit rsync kein Problem. Die Versionierung, die hier das entscheidende Kriterium ist, soll dann von TrueNAS mittels Snapshots der gesyncten Daten erfolgen. Da rsync hier über SSH arbeitet, wird der rsync Server in HBS3 nicht benötigt, sodass ich absolut unabhängig von dieser App bin. Dies wäre so weit auch mit dem bereits eingerichteten OMV Backup-NAS möglich, doch irgendwie mag ich dieses System nicht besonders und will daher auf TrueNAS setzen. Was ohne größere Maßnahmen jedoch nicht mit dem bestehenden OMV-NAS möglich wäre, ist der Schutz der Daten vor „Bit-Rot“, was ich bei dem neuen System durch ZFS in einem Mirror angehen möchte.
Aus meiner früheren „Spielerei“ mit dem TS-470U und TrueNAS weiß ich, dass es unter Umständen keine Lüfterregelung geben wird, was bei dem Rackmount-Modell ein lautes Problem darstellte. Hier hoffe ich, dass es keine Probleme geben wird und der Lüfter entsprechend geregelt wird.
Damit wären wir dann auch schon bei der Hardware angelangt. TrueNAS sollte man nach Möglichkeit nicht auf einem USB Stick installieren und man sollte auch nicht „dafür sorgen“, dass der Datenträger auf dem TrueNAS installiert wird (der dringend eine SSD sein sollte) auch für die Datenablage verwendet werden kann. Kurzum: Für die Installation von TrueNAS geht ein kompletter Datenträger drauf. Bei dem TS-453D hätte ich dann zwar noch drei freie Slots für HDDs, die die Backups beinhalten, jedoch möchte ich hier gerne etwas auf Redundanz setzen und zwei Datenträger für das System verwenden. Da mir zwei Bays für Daten-HDDs langfristig zu wenig wären, benötige ich also eine PCIe Erweiterung für 2x M.2 SSDs sowie die SSDs selbst. Hierzu habe ich mir eine günstige Karte von Axagon besorgt, die M.2 habe ich noch liegen.
Das nächste Thema ist der RAM, von dem mein TS-453D nur 4GB hat, die ich aus Bestand aber auf 8GB aufrüsten konnte. Das ist die Minimalanforderung von TrueNAS, hier muss ich also sehen, wie weit ich komme, notfalls muss aufgerüstet werden.
[UMSETZUNG - HARDWARE UND INSTALLATION IN KURZ]
Leider muss ich bereits bei der Installation Abstriche machen:
Das BIOS ist nicht in der Lage von der PCIe Erweiterung (die ansonsten einwandfrei funktioniert) zu booten. Abhilfe könnte hier ein Bootloader auf USB oder dem DOM schaffen, aber das wäre mir dann doch etwas zu viel Frickelei. Es war mal wieder Crazyhorse, der vorschlug einfach von externen SSDs über USB zu booten. Diesen Weg bin ich dann schlussendlich auch gegangen.
Direkt nach der Installation dann schon der nächste Rückschlag:
Gerne hätte ich das BSD-basierte TrueNAS Core eingesetzt, doch leider wird die 2,5GbE Schnittstelle des NAS nicht von BSD unterstützt (das bedeutet, dass gar keine Netzwerkanbindung möglich ist). „Notgedrungen“ muss ich also auf TrueNAS Scale setzen, welches auf Linux basiert.
Die Installation war wie üblich denkbar einfach, daher nur ein paar Stichpunkte dazu:
Image von TrueNAS mit Rufus bootfähig auf USB-Stick schreiben, TS-453D von diesem Stick booten (Monitoranschluss erforderlich) und TrueNAS auf die SSDs im Mirror installieren.
Als Datenträger für die Backups kommen hier zwei 14TB MG07 von Toshiba im Mirror zum Einsatz.
[UMSETZUNG - SOFTWARE]
Bevor ich mich genauer umschauen kann welche Möglichkeiten ich bei der Datensicherung habe, gilt es aber noch eine andere, wichtige Hürde zu überwinden:
Während es mit QNAP NAS / QTS überhaupt kein Problem darstellt, das System per Zeitplan ein- und auszuschalten, sind derartige Funktionen in TrueNAS nicht vorgesehen. Für ein Backupsystem ist dies für mich jedoch obligatorisch!
Das Herunterfahren jedenfalls kann einfach realisiert werden, das Einschalten hingegen war der Grund weshalb ich bislang Abstand von TrueNAS genommen habe. Dies ist ohne externe Hilfe schlichtweg nicht möglich, sodass der Einschaltbefehl von einem externen System kommen muss, was ich zwar nicht schön finde, mittlerweile aber immerhin als Lösung akzeptiere. In diesem Fall sendet meine Firewall (OPNsense) mittels cron einfach ein WOL Signal, dass das NAS aufweckt. Das Herunterfahren wird über cron von TrueNAS realisiert. Da es im BIOS des TS-453D keine Option für WOL gibt, muss dies allerdings erst per Software aktiviert werden (ethernet-wol g in der Interfaceconfig). Das funktioniert weitgehend einwandfrei, sodass ich mich nun an das Wesentliche ranmachen kann. „Weitgehend“, weil das System aus unerfindlichen Gründen auch immer um 23:35 Uhr eingeschaltet wird. Dem bin ich einfach nicht weiter auf den Grund gegangen sondern habe meine Backupzeit so angepasst, dass diese Einschaltzeit passt 😊. Zur Sicherheit wird natürlich trotzdem mittels WOL geweckt.
Die Einrichtung der Grundeinstellungen war weitestgehend auch kein Problem, lediglich die Erstellung der rsync-Jobs bzw. dessen User mit SSH-Key hat mich etwas Nerven gekostet, weil ich mich damit bislang nicht ausreichend auseinandergesetzt hatte.
Alles in allem war die Einrichtung des Systems sicherlich nicht so intuitiv wie es bei QNAP der Fall ist, aber es war auch kein Hexenwerk!
Nachdem die üblichen Grundeinstellungen für Netzwerk, Uhrzeit, etc. vorgenommen wurden, musste das Storage erstellt werden. Das Ergebnis sieht recht unspektakulär wie folgt aus:
Das Storage mit dem Namen „Backup“ besteht aus zwei Disks in einem Mirror, bei QNAP würde man dies als „Speicherpool im RAID 1“ bezeichnen:
Darauf werden anschließend „Datasets“ angelegt, die bei QTS am ehesten den Volumes entsprechen, wobei bei QuTS Hero damit direkt auch eine Freigabe einhergeht:
Relevant sind hier die Datasets 001-003, welche die Backups beherbergen. Wie auch bei QNAP ist die Aufteilung hier entscheidend für die spätere Versionierung durch Snapshots, die sich immer auf ein Dataset auswirken. Dedup und Kompression habe ich hier zumeist deaktiviert, um Ressourcen zu sparen. Freigaben wie bei QTS / QuTS Hero müssten nun separat erstellt werden, sofern diese denn benötigt werden. Dies ist hier jedoch nicht der Fall, denn eine Freigabe bezieht sich hier auf z.B. SMB oder NFS, was ich allerdings nicht brauche. Die erstellten Datasets sind direkt mittels SSH erreichbar und beschreibbar, mehr brauche ich nicht.
Die drei auf dem ersten Screenshot angezeigten „nicht zugewiesenen“ Disks sind übrigens der DOM, den ich nicht ausgebaut habe (falls bei dem Modell überhaupt möglich).
Im nächsten Step ging es dann schon um die Backup-Jobs. Hier läuft dies direkt über den im System integrierten rsync-Dienst und stellt sich in der Gesamtheit wie folgt dar:
Zu dem fehlgeschlagenen Job komme ich später…
Die Erstellung dieser Jobs ist für QNAP-gewohnte natürlich etwas „rudimentär“:
rsync_create.PNG
(Diejenigen, die den konzeptionellen Fehler in diesen Einstellungen finden, haben aufgepasst ;). Der Fehler wurde noch behoben... gut, dass ich hierdurch noch rechtzeitig darauf aufmerksam wurde!)
rsync erstellt dabei die Ordnerstruktur vom NAS, beginnend mit dem Freigabenamen, direkt in dem ausgewählten Dataset.
Damit nun auch eine Versionierung erfolgt, müssen Snapshots eingerichtet werden. Dies geschieht über den Menüpunkt „Data Protection“ wo auch die rsync Jobs angelegt werden:
Hier wird also täglich versioniert, immer bevor die Daten neu gesynct werden, insgesamt werden Versionen für 7 Tage, 8 Wochen und 24 Monate beibehalten. Tatsächlich wurden auch schon Snapshots erstellt, allerdings hatte ich zum Testbetrieb hier noch andere Uhrzeiten gewählt:
Auf dem vorherigen Screenshot findet man auch die Zeitplanung für das Scrubbing, womit die beiden Disks des Mirrors abgeglichen werden, damit ZFS etwaige Fehler wie Bit-Rots vorbeugen und beheben kann.
Damit ist die Einrichtung im Wesentlichen abgeschlossen und wir können ein Blick auf die Praxis werfen…
[BETRIEB IN DER PRAXIS]
Die Sync Jobs haben (nach erfolgreicher Einrichtung) ihre Jobs auf Anhieb erledigt… naja, mal wieder weitestgehend… Ein Job soll sich meine Daten der laufenden VMs holen, was praktisch unmöglich ist, da sich die Daten sekündlich ändern und rsync diesen Job mit Fehlern abbricht. Abhilfe schafft hier ad hoc (leider) nur HBS3, mit dem ich einen Snapshot der Daten erstellen kann, sodass diese ohne Fehler gesichert werden können. Dies erfolgt intern auf dem NAS selbst, die dort gesicherten, aber ungenutzten Daten kann sich TrueNAS dann via rsync holen, da ich dem QNAP keine Schreibrechte auf das Backup geben werde… leider auch wieder nur in der Theorie… denn die von der VS erstellten Snapshot-Daten (*.state) sind nur für den admin lesbar, den ich allerdings nicht als Backupuser verwende, sodass auch dies wieder eine Sackgasse ist! Eine Option um die Dateirechte bei dem internen Sync zu entfernen gibt es leider nicht, und mit irgendwelchen Scripten, die das täglich automatisch machen, möchte ich mich auch nicht rumärgern… hier muss ich mir also noch etwas einfallen lassen.
Was mir nicht sonderlich gefällt ist, dass es keine Fortschrittsanzeige für die Jobs gibt. Stattdessen wird lediglich angezeigt, dass der Job läuft, nicht aber wie weit dieser fortgeschritten ist und ohne Möglichkeit ihn vorzeitig zu beenden. Die fehlende Fortschrittsanzeige scheint aber ein rsync-„Problem“ zu sein, technisch nämlich gar nicht möglich… keine Ahnung wie sich die Anzeige hier in HBS3 auswirkt (ich habe rsync hier lange nicht verwendet).
Auch fällt auf, dass das System extrem träge wird, sobald ein Job läuft. Schuld daran ist vornehmlich der zu gering bemessene RAM in Verbindung mit der rsync-Option „Delay Updates“. Die Option habe ich mittlerweile deaktiviert und den RAM auf 16GB aufgerüstet.
Im Dashboard sieht es idle nun so aus:
… und während ein Sync läuft so:
Mit nur 8GB RAM hatte das System selbst nach erfolgtem rsync Job noch geswappt, das hat nun glücklicherweise ein Ende und das System läuft flüssig und stabil. Auch wird die gesamte Bandbreite meines 1G LAN ausgenutzt, was ich bei HBS3 (kein rsync) meist nicht behaupten konnte.
Gefällt mir soweit gut! Natürlich habe ich auch Benachrichtigungen via Mail eingerichtet, sodass mich das System bei Fehlschlag eines Jobs (u.a.) alarmiert. Außerdem logge ich via Syslog auf mein QNAP, sodass ich hier 24/7 Einsicht in die Geschehnisse vom TrueNAS System habe… wenn auch recht unübersichtlich, denn ein so schönes Log wie bei QNAP sucht man hier vergebens: Die GUI hält keinerlei Logs bereit, stattdessen muss man diese über das CLI aufspüren und durchsuchen oder eben auf Syslog zurückgreifen. Hier besteht aus meiner Sicht ein deutliches Verbesserungspotential.
Wichtig ist natürlich nicht nur, dass die Daten gesichert werden, sondern dass man auch an sie herankommt, wenn sie benötigt werden. Da ich keinerlei Dateidienste aktiv habe und auch nicht vorhabe, solche zu aktivieren, bediene ich mich einfach SSH um mittels WinSCP übersichtlich durch die Backups zu browsen. Hierüber kann ich auch einzelne Daten wiederherstellen, eine weitere Option für eine Gesamtwiederherstellung wäre wiederum rsync von TrueNAS an das Ziel.
Einen kleinen Abstrich muss ich allerdings bei der Versionierung mittels Snapshots machen: Bei QNAP kann man wunderschön durch die einzelnen Snapshots browsen und sich den jeweiligen Stand genau anschauen. Bei einer Versionierung mittels HBS3 wäre dies ebenfalls möglich. Bei dem TrueNAS System besteht eine solche direkte Möglichkeit allerdings nicht, stattdessen muss man sich die gewünschte Version zunächst „blind“ aussuchen und die darin enthaltenen Daten in ein neues Dataset wiederherstellen, das man anschließend durchsuchen kann. Das hätte ich mir komfortabler gewünscht, aber ich kann damit leben! Da ich eigentlich ein Freund von zentral verwalteten, oder zumindest zentral überwachten Backups bin, bin ich natürlich nicht ganz fein mit der Tatsache, dass ich nun (wieder) ein System habe, in das ich zwecks Überwachung der Backups gelegentlich mal reinschauen muss, sicherlich ist auch das aber nur eine Sache der Gewohnheit.
Insgesamt bin ich mit dieser Lösung schon sehr zufrieden, lediglich über Kleinigkeiten muss ich mir noch Gedanken machen… da wäre die schon angesprochene Problematik mit den VM-Backups (die ich allerdings nicht zwingend in diesem System haben muss) und auch dass das System auf zwei externen SSD installiert ist scheint zumindest das System selbst nicht für gut zu befinden, denn das wird bei jedem Systemstart moniert, außerdem werden keine SMART Werte und Temperaturen geliefert. Das kleinste Übel ist, dass mit der regulären Einschaltzeit des NAS kein Scrubbing (monatlich) möglich ist, zumindest nicht innerhalb einer Einschaltperiode. Hier muss ich sehen, wie es sich verhält, wenn das Scrubbing immer wieder unterbrochen wird, eventuell muss ich hier den Ein/Aus Zeitplan für den einen Tag im Monat etwas anpassen.
Was die Hardware angeht, kann ich bei der Lüfterregelung Erfolg vermelden, denn im Gegensatz zum Rackmount-Modell wird der Lüfter hier einwandfrei geregelt. Einziger „Blickfang“ sind hier die beiden System-SSD, die an USB-Adaptern hängen. Das sieht etwas… alternativ aus, lässt sich im Rack aber gut und sicher verstecken. Eigentlich wollte ich die Adapter in den offenen Erweiterungs-Slot führen, sodass die SSD auf dem HDD-Käfig im NAS liegen, Platz ist ausreichend vorhanden, doch leider sind die Kabel der Adapter 2-3cm zu kurz, sodass das nicht möglich ist.
[EPILOG]
Ich sehe TrueNAS ja nicht zum ersten Mal, arbeite allerdings zum ersten Mal etwas intensiver damit und es gefällt mir wirklich sehr gut. Von QNAP mag man einiges gewohnt sein, Gutes sowie Schlechtes, was in TrueNAS anders umgesetzt ist, daran muss man sich einfach gewöhnen. Ob TrueNAS das wirklich stabilere System insbesondere für meine Zwecke ist, kann ich so früh noch nicht bewerten, allerdings weiß ich, wie es um QTS steht, und das lässt sich schwer unterbieten. Auch der ganz aktuelle Massen-Fall, bei dem durch HBS3 Quelldaten gelöscht wurden, statt diese zu sichern, bestätigt mich in meinem Grundgedanken zumindest beim Backup von QNAP und HBS3 Abstand zu gewinnen.
Trotz allem wird das neue System zunächst nur das OMV-Backup-NAS ablösen, das (interne) Backup-NAS mit QTS (notgedrungener Push-Sync seit ich mich von der HBS-Backupfunktion verabschieden musste) wird vorerst bestehen bleiben und später ersatzlos entfallen, wenn ich mit dem neuen System etwas vertrauter bin. Übrig bleibt dann noch mein externes Backup, welches ebenfalls auf ein QNAP-NAS mit Push-Sync läuft. Ob und wie ich dieses System (2-Bay) ersetzen werde, bleibt abzuwarten. Mein ebenfalls internes Backupsystem (QTS), bei dem Snapshot-Replika auf das Ziel geschrieben werden, wird ebenfalls bestehen bleiben. Bis auf unheimlich lange Verarbeitungszeiten und Snapshot-Problemen in QTS allgemein ist mir hier nämlich bislang kein ernstes Problem untergekommen.
Irgendwo hatte ich mal geschrieben, dass „man sein Backupkonzept leben muss“, genau das ist hier mal wieder geschehen, indem dafür Sorge getragen wurde, dass das Backup sauber und zuverlässig funktioniert. Das niedergeschriebene Konzept wurde entsprechend angepasst.
Etwas Arbeit muss ich hier noch investieren, dann ist es aber auch mal wieder an der Zeit, dass ich für mich selbst sorge… mit einem Kaltgetränk in der Sonne klappt das meist ganz gut, das werde ich nachher mal probieren… cheers! 