Nachdem mir inzwischen doch Festplatten zur Unzeit den Geist aufgegeben haben, habe ich mich entschlossen, eine dauerhafte Lösung einzurichten. Schicken wir einige Überlegungen voraus. Die Aufgaben des Backups , der Ausfallsicherung (i.w. RAID) und der Archivierung überschneiden sich, aber sind nicht identisch. So ist die Erwartung, daß ein Backup oder eine Ausfallsicherung gegen Benutzerfehler oder externe Datenangriffe schützen soll oder kann, nur bedingt erfüllbar. Ein gespiegeltes RAID-Laufwerk, bei dem ein Angreifer beispielsweise Daten in-place verschlüsselt hat, nützt nichts, weil der Spiegel ja ebenfalls verschlüsselt wird.
Daten unterscheiden sich darin, ob ein Backup notwendig oder sinnvoll ist: Das Betriebssystem zB bedarf keines Backups, da es normalerweise aus dem Internet wiederherstellbar ist. Eine Ausfallsicherung ist aber eher sinnvoll dafür. Temporäre Daten, Cache-Inhalte, Downloads, Browserverläufe etc. möchte man nicht im Backup oder Archiv finden. Sind sie enthalten, behindern oder verzögern gegebenenfalls eine Wiederherstellung. Darüber hinaus gibt es vertrauliche Daten, die der Systemadministrator zwangsläufig (entweder als root-user oder als Zugriffsberechtigter auf das Backup-Device) zur Kenntnis bekommt. Dieses Problem bedarf kryptographischer Methoden zur angemessenen Behandlung.
Ich habe mich für einen Venti-Server als Archiv- und Backup-Lösung entschieden. Venti ist eine Archivlösung, die für das Betriebssystem Plan9 entwickelt wurde, aber auch für praktisch alle Betriebssysteme durch plan9ports verfügbar ist. Venti hat den Vorteil, daß unnötige Datenduplikate vermieden werden, trotzdem beliebige Dateisysteme gesichert werden können. Etwas, was sich eher nicht für einen Venti-Server eignet, sind jedoch große sequentiell zu verarbeitende Datenmengen (zB ganze DVDs).
Ein klarer Gewinn durch die Venti-Lösung ist die inhärente Datensicherheit durch die implizite kryptographische Hash-Addressierung und die Robustheit gegen partielle Datenverluste. Ein Verschlüsselungsangriff müßte Zugriff auf die Venti-Arenas haben, was man relativ sicher verhindern kann.
Aus Softwaresicht wäre ein Plan9-System vorzuziehen, aber es ist mir nicht gelungen, eine geeignete Hardwarebasis dafür zu finden. Aufgrund der Angebotslage habe ich mich für ein Western Digital MyCloud Ex2 Ultra entschieden, das bei ebay als defekt verramscht wurde. Dazu zwei 3TB-Festplatten, eine WD-red und eine von Seagate, die eigentlich als RAID1 konfiguriert werden sollten. Für ein Archivsystem sehe ich keinen Sinn in RAID1, so liegt eine der Platten erst einmal als Reserve bereit. Das Mainboard ist ein ARMv7 mit 1GB Hauptspeicher, Gigabit-Netzwerkschnittstelle, 2 Plattenslots und USB3. Anstelle der Originalsoftware habe ich das Linux-System (Debian Buster) von fox-exe.ru installiert, dazu Plan9ports und Samba.
Inzwischen hat sich ergeben, daß Plan9 auf dem Raspberry Pi (auch ARMv7) läuft. Ich habe also einen Pi4 mit 8GB RAM und 128GB SD-Karte für weniger als 100 Euronen erstanden, auf dem die Plan9-Version 9front löuft.
Unschön ist allerdings, daß jetzt damit ein viertes System (nach 2 Fritzboxen und der Mycloud) zum Dauerstromverbraucher geworden ist. Die Fritzboxen lassen sich wegen des Telefons nicht vermeiden. Ich überlege, ob ich wenigstens den Stromverbrauch in der Nacht über ein Akkusystem (USV) auf die Zeit umschichten kann, wenn mein eigenerzeugter Solarstrom zur Verfügung steht. Genaugenommen gibt es natürlich noch mehr Dauerstromverbraucher, nämlich die diversen Ethernet-Switches und sonstigen nicht so smarten Smart-Home-Geräte. Die Problematik der Switches ist erschwert dadurch, daß sie sich auf 4 Ebenen im Haus verteilen, also auch die USV-Versorgung wohl über PoE erfolgen muß.
Inzwischen hat sich durch eine Erneuerung meines Desktoprechners – mit entsprechender Hauptspeicherverbesserung – die Möglichkeit ergeben, ein Plan9-System auf einem bhyve aufzusetzen. Der virtuelle Plan9-Server wird automatisch bei jedem Systemstart mitgestartet. Der Venti-Server kann somit genutzt werden ohne das nach dem vorherigen Absatz benötigte Zusatzsystem.
Venti von Plan9ports liefert einige Tools standardmäßig mit. Die archivierten Daten können zB über NFS verfügbar gemacht werden. Die Vermeidung von Duplikaten setzt allerdings voraus, daß alle verwendeten Programme dieselbe Blockgröße verwenden.
Sicherung eines Unix-Dateisystems (ext2 oder BSD ffs) mit Versionen analog zu UNIX dump. Hier stellt sich das Problem mit den Blockgrößen in folgender Form. Ffs speichert typischerweise bei aktuellen Plattengrößen in 32k-Blöcken und 4k-Fragmenten. Der Venti-Default für Blockgröße ist 8k.
Vorteil: das Filesystem wird 1:1 wiederhergestellt, also keine Probleme mit ACLs oder sonstigen inkompatiblen Metadaten.
Sicherung eines Dateibaums (ohne Rücksicht auf das unterliegende Dateisystem, auch über mountpoints hinweg), wahlweise auch als Dump-System mit Versionen. Die Sicherungsdatei wird zB über vacfs verfügbar gemacht.
vac . > wb.vac ... vacfs wb.vac 9pserve `namespace`/vacfs.wb tcp!*!564 ... 9pfs -p 564 vacserver mnt
Die letzte Zeile ersetzt auf FreeBSD das nicht funktionsfähige
9pmount tcp!vacserver!564 mnt
Vacfs hat den Nachteil, daß keine Authentisierung vorgesehen ist, d.h. wer Zugriff auf den Venti-Fingerprint des Archivs hat, kann alles lesen.
Man kann natürlich auch ein dump-, tar- oder cpio-File oder sonstiges Archivformat direkt abspeichern. Inwieweit eine solche Lösung mit dem Wunsch nach Deduplikation verträglich ist, müßte man im Einzelfall prüfen. Möglicherweise ist es sinnvoll, hier adaptive Algorithmen zur Aufteilung in variabel große Blöcke zu verwenden: https://github.com/stroucki/venti-streamchunk.
Ein komplettes Filesystem, eigentlich eine Variante der Sicherung über vac. Fossil-Systeme laufen inzwischen sowohl auf dem Pi4 als auch der Mycloud. Die Authentisierung erfolgt über ein sehr ausgefeiltes System, das aber nur auf Plan9 zur Verfügung steht, insofern ist es nur im ganzen Zusammenhang praktikabel. Ein nicht nur subtiler Unterschied zwischen Plan9 und Unix ist die Semantik des Mountens. Unter Unix erfolgt das Mounten eines Filesystems auf einem Directory durch den Root-User, während bei Plan9 jeder einzelne Prozeß für sich und seine Abkömmlinge die entsprechende Manipulation im Namensraum ausführt. Das bedingt, daß unter Unix beim Mounten dem Root-User vertraut wird, eine Abbildung der Berechtigungen im laufenden System und im Fileserver herzustellen. Beim Mounten unter Plan9 muß sich der mountende Prozeß beim Fileserver über einen zentralen Auth-Server ausweisen. Für die Ausführung ist konkret ein Programm factotum verantwortlich, das die jeweiligen Berechtigungen für jeden authentisierten Benutzer verwaltet.
Factotum in planport ist zwar unter Linux nutzbar, auf FreeBSD jedoch nur bedingt (im Fall von FreeBSD12 läuft es nur unter vgrind). Jedenfalls unterstützt es aber auch nur das Protokoll p9sk1, das von 9front zusätzlich zugelassen werden müßte, und nicht das dort bevorzugte dp9ik. Die Vorzugslösung ist der Export des nativen factotum mittels drawterm. Ein geeignetes Script ist dies:
#!/bin/rc rfork n bind /mnt/term/net /net aux/listen1 -t tcp!*!9999 /bin/exportfs -r /mnt/factotum & os 9pfs -p 9999 localhost mnt/rfactotum
Drawterm ist ein Programm, auf dem ein Plan9-Terminal auf einem Unix-System emuliert wird.
Jede Backup- oder Archiv-Lösung benötigt einen Rahmen, der sicherstellt, daß die erforderlichen Backups tatsächlich angelegt und verwaltet werden. Das Zugänglichmachen ist kein Problem, wenn ein NFS-System genutzt werden kann; wenn es um einzelne Wiederherstellungen geht, tritt das Problem vermutlich sehr selten auf, so daß exzessive Vorbereitung für diesen Fall wenig sinnvoll ist.
Auf einem regelmäßig (oder dauernd) laufenden System kann man einen cron-Job installieren. Leider sind die wenigsten Systeme heutzutage in der Lage, diese Lösung nutzen zu können, da es meist PCs oder Handys sind, die abgeschaltet oder abwesend sein können. Eine Lösung dafür ist das Utility anacron. Anacron sorgt dafür, daß überfällige periodische Aktionen nachgeholt werden.
Am Neujahrstag 2024 traf mich der Ausfall meines Plattensystems, diesmal nicht durch Hardware-Ausfall, sondern anscheinend ein Softwarefehler. Ich hatte auf meinem aktuellen Desktop entdeckt,daß der Rechner auch mit NVME-SSD bestückt werden kann. Somit habe ich dann eine Karte mit 256GB erworben, und mit dem modernen ZFS statt dem bewährten UFS eingerichtet. Ein ZFS-Pool enthält mehrere Datasets (eigenständige FIlesysteme), die unterschiedlichen Zwecken angepaßt werden können, aber sich die verfügbaren physikalischen Speicher nach Bedarf teilen (im Gegensatz zur statischen Partititonierung).
Die zusätzlichen Möglichkeiten der impliziten Datenverschlüsselung und RAID habe ich nicht genutzt, und kein RAID -System hätte bei dem aufgetreten Problem etwas genützt. Der Pool Ließ sich auf einmal nicht mehr importieren, was sich so äußerte, daß das System zwar den Anfang des Bootprozesses bewältigte, aber beim Import des Pools abstürzte, und zwar bevor es in die Multi-User-Umgebung oder in die Single-User-Shell kam.
Mit einem FreeBSD-System, die über Ethernet geladen wurden, stellte ich fest, daß der Pool importiert werden konnte, wenn man ihn auf Readonly stellte, ohne stürzte auch dieses System beim Import sofort ab. Die Daten waren offenbar unbeschädigt. Unter Linux ließ sich der Pool sogar Readwrite importieren. (Der Umstand, daß ZFS sowohl unter FreeBSD als auch Linux genutzt werden kann, ist sicher ein großer Pluspunkt). Trotz durchgeführter Veränderungen aud einigen Datasets bliebe aber das eigentliche Problem unverändert bestehen.
Eine Anfrage im FreeBSD-Forum, ob es eine Möglichkeit gibt, das System wieder gängig zu machen, blieb erfolglos. Es erwies sich ferner, daß ein Neuaufsetzen des Betriebssystems inzwischen (vor allem wegen Grafik) schwieriger war, als das vorhandene System mit den Mitteln der ZFS-Utilities umzukopieren. Hoffen wir, das es diesmal länger hält.