Tocho: souveräner persönlicher Speicher, verschlüsselt und zwischen zwei Standorten repliziert

Du kannst diesen Artikel im Audioformat anhören (erzeugt mit NotebookLM):

1. Einleitung

Tocho ist ein persönliches Projekt, das Ismael Ripoll und ich, Raúl, betreiben, mit dem Ziel, über ein Massenspeichersystem zu verfügen, das einigermaßen zuverlässig, verschlüsselt und zwischen zwei verschiedenen physischen Standorten repliziert ist.

Die ursprüngliche Idee war einfach: Jeder von uns würde einen Raspberry Pi mit einer SATA-Festplatte von 16 TB besitzen. Jede Festplatte würde dazu dienen, die eigenen Daten zu speichern und gleichzeitig eine verschlüsselte Kopie der Daten des anderen. Auf diese Weise hätte jeder eine externe Replik in einem anderen Haus.

Mit der Zeit hat sich das Projekt weiterentwickelt. Es ist nicht mehr nur „ein heimisches NAS mit einer entfernten Kopie“, sondern eine persönliche Infrastruktur, die Folgendes kombiniert:

• Massenspeicher;
• Kreuzkopien;
• Verschlüsselung;
• nativer Zugriff von Linux aus;
• Überwachung;
• Schutz vor Ausfällen;
• teilweiser Schutz vor Ransomware;
• versionierte Kopien mit Borg;
• und eine klare Philosophie der technischen Souveränität.

Es ist kein Unternehmenssystem und soll auch keine professionelle Infrastruktur ersetzen. Aber es bietet eine sehr wichtige Verbesserung gegenüber dem Vorhandensein einer einzigen lokalen Kopie oder, noch schlimmer, gegenüber dem Fehlen jeder systematischen Backup-Strategie.

2. Motivation

Die Hauptmotivation ist sehr praktisch: Persönliche Daten beanspruchen immer mehr Platz und passen nicht immer gut in die kommerziellen Cloud-Dienste. Fotos, Videos, Repositorys, Dokumente, Festplattenabbilder, Maschinenkopien, persönliche Projekte und historische Archive können leicht mehrere Terabyte erreichen.

Die kommerziellen Dienste lösen viele Probleme sehr gut, aber sie bringen auch Einschränkungen mit sich:

• wiederkehrende monatliche Kosten;
• Abhängigkeit von einem Anbieter;
• ungleichmäßige Integration mit Linux;
• fehlende echte Kontrolle über Protokolle und Automatismen;
• Platzbeschränkungen;
• sich ändernde Richtlinien;
• und oft eine Oberfläche, die eher für allgemeine Nutzer als für technische Arbeitsabläufe gedacht ist.

Tocho entsteht aus einer anderen Idee: Wenn wir über ausreichend technisches Wissen verfügen, können wir eine eigene Infrastruktur aufbauen, sie verstehen, reparieren und an unsere Bedürfnisse anpassen.

Allerdings ist eine der Lehren des Projekts gerade die, dass dies nicht umsonst ist. Auch wenn man keine monatliche Gebühr zahlt, muss man Festplatten, Adapter, Stromversorgung, Kühlung, Verwaltungszeit, Tests, Überwachung und Wartung bezahlen. Die kommerzielle Cloud kann teuer erscheinen, bis man alles zusammenrechnet, was es bedeutet, selbst eine einigermaßen zuverlässige Infrastruktur zu betreiben.

3. Ziele des Projekts

Die Hauptziele von Tocho sind:

1. Über viel Speicherplatz zu vertretbaren Kosten verfügen.
2. Eine entfernte Replik der wichtigen Daten vorhalten.
3. Die Vertraulichkeit der auf dem Server des anderen abgelegten Daten schützen.
4. Das Risiko von Verlusten durch Ausfälle, Diebstahl, Brände oder andere lokale Vorfälle reduzieren.
5. Standardwerkzeuge von Linux verwenden.
6. Nativen Zugriff auf die Dateien ermöglichen, ohne von einer proprietären Anwendung abhängig zu sein.
7. Versionierte und deduplizierte Kopien anfertigen.
8. Das Risiko verringern, dass eine Ransomware oder ein menschlicher Fehler alle Kopien zerstört.
9. Das System für beide Administratoren verständlich und reparierbar halten.

Die Philosophie ist, dass Zuverlässigkeit nicht nur vom Kauf teurer Hardware abhängt, sondern von der Kombination guter Praktiken: Repliken, Verschlüsselung, Überwachung, regelmäßige Prüfungen, Trennung von Privilegien und echte Wiederherstellungsfähigkeit.

4. Allgemeine Architektur

Jeder Teilnehmer hat eine ähnliche Installation:

• einen Raspberry Pi, der als Server fungiert;
• eine SATA-Festplatte von 16 TB;
• einen USB-SATA-Adapter, der mit großen Festplatten kompatibel ist;
• eine eigene Stromversorgung für die Festplatte;
• ein Gehäuse oder physisches Rack;
• Belüftung;
• SSH-Zugriff mit öffentlichen Schlüsseln;
• lokaler Dateiexport, in meinem Fall auch über NFS;
• verschlüsselte Bereiche;
• und geplante Aufgaben zum Kopieren und Verifizieren.

Das konzeptionelle Schema ist dieses:

Figura 1

Jeder Server hat eine doppelte Funktion:

• Hauptserver für lokale Daten;
• entferntes Ziel der verschlüsselten Kopie des anderen.

5. Modell der Kreuzreplikation

Das grundlegende Replikationsmodell ist bewusst einfach. Die Daten werden regelmäßig kopiert, normalerweise nachts, mittels rsync.

Im üblichen Fall:

1. Der lokale Server enthält die Hauptdaten.
2. Vor der Kopie wird der Zustand der Festplatte geprüft.
3. Wenn die Festplatte in gutem Zustand zu sein scheint, wird die Synchronisierung gestartet.
4. Die Daten des anderen werden verschlüsselt gespeichert.
5. Der physische Eigentümer des entfernten Servers kann den echten Inhalt nicht lesen.

Figura 2

Es ist auch möglich, nach dem Kopieren vieler Daten eine manuelle Synchronisierung zu erzwingen. Das verringert das Risikofenster zwischen dem Zeitpunkt, an dem ein neues Datum auf dem lokalen Server erscheint, und dem Zeitpunkt, an dem es entfernt repliziert ist.

rsync ermöglicht es, die Bandbreite leicht zu begrenzen (--bwlimit), aber in der Praxis tun wir das nicht: Jeder Knoten verfügt über 1 Gbps und die Kopien werden nachts gestartet, sodass wir nie einen Leistungsverlust bemerkt haben, weder im Heimnetzwerk noch in der Verbindung zwischen den beiden Häusern. Sollte sich das eines Tages ändern, wäre das Aktivieren des Limits trivial.

6. RPO: wie viele Daten wir verlieren können

Im aktuellen Zustand hat das System ein RPO von ungefähr einem Tag für die Daten, die nur nachts synchronisiert werden.

RPO bedeutet Recovery Point Objective: der maximale Datenzeitraum, von dem angenommen wird, dass er bei einer Katastrophe verloren gehen könnte. Wenn die Kopie jede Nacht erfolgt, ist der übliche maximale Verlust das, was seit der letzten korrekten Kopie geändert wurde.

In der Praxis:

• wenn die nächtliche Kopie gut verlaufen ist, kann ich höchstens die Daten desselben Tages verlieren;
• wenn ich nach dem Kopieren vieler Daten manuell eine Synchronisierung ausführe, verringere ich dieses Fenster;
• wenn die Kopie fehlschlägt und ich es nicht bemerke, verschlechtert sich das reale RPO.

Das macht die Überwachung nicht zu einem nebensächlichen Detail. Es genügt nicht, „Kopien zu haben“: Man muss wissen, dass die letzten Kopien korrekt abgeschlossen wurden.

7. Verschlüsselung mit GoCryptFS

Ein wesentlicher Punkt des Projekts ist, dass jeder Teilnehmer Daten des anderen beherbergt, sie aber nicht lesen können soll.

Deshalb wird ein Teil der entfernten Daten mit GoCryptFS verschlüsselt gespeichert. Dieses System ermöglicht es, eine verschlüsselte Darstellung der Dateien auf der Festplatte zu haben, während der Eigentümer sie transparent einbinden kann, wenn er auf sie zugreifen muss.

Das bringt mehrere Vorteile:

• die Festplatte kann entfernt, ersetzt oder zerstört werden, ohne die Daten offenzulegen;
• der physische Eigentümer des Servers kann den echten Inhalt der Kopie des anderen nicht inspizieren;
• die Kopie kann mit Standardwerkzeugen erfolgen, weil letztlich normale verschlüsselte Dateien kopiert werden;
• die Einbindung kann lokal auf dem Raspberry Pi oder entfernt von einem anderen Computer aus erfolgen.

Figura 3

In der Praxis ist es nützlich, die Einbindung von einem leistungsfähigeren PC aus vornehmen zu können. Der Raspberry Pi ist eine effiziente Maschine, aber die Verschlüsselung kann die CPU belasten. Wenn der Prozess wenige Threads verwendet oder die Kopie intensiv ist, kann das Auslagern eines Teils der kryptografischen Arbeit auf einen leistungsfähigeren Computer die Leistung verbessern.

8. NAS, aber nicht nur NAS

Ein Teil von Tocho funktioniert wie ein NAS: ein vom lokalen Netzwerk aus zugänglicher Dateiserver. In meinem Fall kann ich die Dateien über NFS einbinden und natürlich von Linux aus mit ihnen arbeiten.

Das ist sehr bequem, bringt aber auch ein Risiko mit sich: Wenn mein PC vollständigen Zugriff auf das Dateisystem hat, könnte ein eigener Fehler, ein fehlerhaftes Skript oder eine Ransomware die Daten direkt ändern oder löschen.

Deshalb ist es wichtig, zwei Funktionen zu unterscheiden:

1. Arbeits-NAS, gedacht für den bequemen Zugriff auf Dateien.
2. Backup-System, gedacht zum Aufbewahren von Versionen und zum Widerstehen von Fehlern oder Angriffen.

Ein NAS ist nicht automatisch ein Backup. Wenn es dauerhaft mit Schreibrechten eingebunden ist, gehört es zur selben Risikofläche wie der PC.

9. Borg-Kopien: Deduplizierung, Verschlüsselung und Versionen

Um den Backup-Teil zu stärken, habe ich begonnen, BorgBackup zu verwenden. Borg ist ein Backup-Werkzeug mit Deduplizierung, Komprimierung und authentifizierter Verschlüsselung. Es ist dafür gedacht, effiziente Kopien anzufertigen, weil es nach der ersten nur die Blöcke speichern muss, die sich geändert haben.

Dieser Teil ist besonders wichtig, weil er einen konzeptionellen Unterschied gegenüber der klassischen Nutzung eines NAS einführt.

Mit NFS arbeite ich direkt an sichtbaren Dateien. Mit Borg erstellen die Client-Computer versionierte Kopiearchive innerhalb eines Repositorys. Das ermöglicht es, viele Versionen aufzubewahren, ohne den verwendeten Platz linear zu vervielfachen.

Borg bringt drei sehr wertvolle Eigenschaften:

• Verschlüsselung;
• Deduplizierung;
• logische Snapshots.

Das macht es für historische Kopien viel geeigneter als eine einfache Replik mit rsync.

10. Pro Computer eingeschränkte SSH-Schlüssel

Jeder Computer, der Kopien zum Server anfertigt, hat einen eigenen SSH-Schlüssel, der speziell für diese Funktion erstellt wurde.

Diese Schlüssel sollten keinen allgemeinen Zugriff auf den Server gewähren, keine interaktive Shell öffnen lassen und nicht erlauben, das System zu administrieren. Die Idee ist, dass jeder Schlüssel nur erlaubt, den notwendigen Dienst auszuführen, um Kopien zum entsprechenden Borg-Repository hinzuzufügen.

Borg unterstützt die Verwendung von borg serve mit über SSH erzwungenen Befehlen, was genau das geeignete Muster für diese Art von Konfiguration ist.

Konkret wird dies erreicht, indem man jeden Schlüssel auf einen bestimmten Befehl innerhalb der Datei authorized_keys beschränkt. Wenn man command="<autorisierter Befehl>" vor den öffentlichen Schlüssel setzt, führt der Server nur diesen Befehl aus, wenn sich jemand mit dem Schlüssel verbindet, auch wenn der Client versucht, einen anderen zu starten. Auf diese Weise kann ein Schlüssel, der zum Anfertigen von Kopien gedacht ist, keine interaktive Shell öffnen, das Dateisystem durchlaufen oder Daten willkürlich löschen. Es ist ein Schlüsselelement, um das Risiko von Ransomware und anderen Angriffsszenarien zu reduzieren.

Das Schema ist ungefähr dieses:

Figura 4

Das verringert das Risiko erheblich für den Fall, dass ein Laptop, ein PC oder eine andere Client-Maschine kompromittiert wird. Wenn ein Angreifer den Schlüssel dieser Maschine erlangt, sollte er weder frei in den Server eindringen noch irgendetwas löschen können.

11. Append-only-Modus und Verteidigung gegen Ransomware

Eine der jüngsten Motivationen des Projekts ist die Verbesserung des Schutzes vor Ransomware.

Das Problem eines traditionellen NAS ist, dass, wenn die Dateien mit Schreibrechten vom Haupt-PC aus eingebunden sind, eine Ransomware auch die Daten des NAS verschlüsseln oder zerstören könnte. In diesem Fall würde das NAS aufhören, ein echtes Backup zu sein, und zu einer verwundbaren Erweiterung des Computers selbst werden.

Um dieses Risiko zu reduzieren, können die Borg-Repositorys im Append-only-Modus konfiguriert werden. Die Dokumentation von Borg erklärt, dass dieser Modus nützlich ist, wenn eine Client-Maschine entfernte Kopien zu einem Server mit borg serve anfertigt, weil eine kompromittierte Client-Maschine die Kopien auf dem Server nicht dauerhaft löschen kann.

Die Trennung ist entscheidend:

• die Clients können Kopien hinzufügen;
• die Clients sollten die Historie nicht zerstören können;
• das Beschneiden alter Versionen muss ein separater Vorgang sein;
• ein Angriff von einem Client-Computer aus sollte nicht alle guten Kopien löschen können.

Das beseitigt nicht alle Risiken. Ein Angreifer könnte schlechte oder verschlüsselte Kopien hinzufügen, und man müsste das Problem erkennen, bevor man ein zerstörerisches Beschneiden vornimmt. Aber es ist eine sehr wichtige Verbesserung gegenüber einem dauerhaft mit vollem Zugriff eingebundenen NFS-Verzeichnis.

12. Trennung zwischen lebenden Daten und Backups

Eine Zukunftsidee ist, die Nutzung des Servers als Speicher für direkt manipulierbare Dateien zu reduzieren und ihn zunehmend in einen Speicher für Borg-Kopien zu verwandeln.

Das bedeutet, zu unterscheiden zwischen:

1. Lebenden Daten, die vom normalen PC aus geöffnet, bearbeitet, verschoben oder gelöscht werden können.
2. Backups, die nur dem Repository hinzugefügt werden und nicht direkt vom üblichen Benutzerkonto modifizierbar sind.

Diese Trennung ist sehr gesund. Die lebenden Daten können auf lokalen Festplatten liegen, zum Beispiel auf einer 4-TB-Festplatte oder einer internen 2-TB-Festplatte. Der Tocho-Server hingegen kann sich vor allem dem Speichern verschlüsselter und deduplizierter Borg-Versionen widmen.

Das Ziel ist, von diesem Modell:

Figura 5

zu diesem anderen überzugehen:

Figura 6

Wenn das normale Benutzerkonto einen Fehler macht, ein zu weitreichendes rm ausführt oder kompromittiert wird, sollte es keinen direkten Zugriff haben, um alle historischen Kopien zu zerstören.

13. Inkrementelle Kopien und teilweise Synchronisierung

Eine offene Frage ist, ob man inkrementelle Kopien anfertigen kann, ohne jedes Mal den gesamten Dateibaum durchlaufen zu müssen.

Mit rsync besteht das normale Modell darin, Quelle und Ziel zu vergleichen, um zu entscheiden, was sich geändert hat. Das ist robust, kann aber kostspielig sein, wenn es sehr viele Dateien gibt.

Es gibt mehrere mögliche Strategien:

• manuelle Synchronisierungen bestimmter Ordner nach wichtigen Änderungen starten;
• Borg-Kopien der wirklich wichtigen Datensätze anfertigen;
• Listen kürzlich geänderter Dateien mit find verwenden, auch wenn das fragiler ist;
• die Daten besser nach Änderungshäufigkeit trennen: kalte Dateien, aktive Daten und kritische Kopien;
• Systeme mit nativen Snapshots in Betracht ziehen, falls in Zukunft Btrfs oder ZFS verwendet wird.

Im Allgemeinen ist Borg für versionierte Backups geeigneter als eine einfache Replik mit rsync. Für die Replik eines navigierbaren Dateibaums bleibt rsync sehr einfach und praktisch.

14. Nativer Zugriff von Linux aus und Souveränität über die Dateien

Einer der wichtigsten Vorteile von Tocho ist, dass es mir erlaubt, mit meinen Dateien nativ unter Linux zu arbeiten.

Im Gegensatz zu einigen kommerziellen Cloud-Diensten zwingt mich das System nicht, über eine Weboberfläche, eine proprietäre Anwendung oder eine fremde Integrationsschicht zu gehen. Ich kann Dateisysteme mit Standardwerkzeugen einbinden, mit NFS, SSHFS, GoCryptFS oder Borg zugreifen, Aufgaben mit Skripten automatisieren und genau entscheiden, wie ich die Daten organisieren will.

Das hat einen enormen praktischen Wert. Für einen Linux-Benutzer ist das Dateisystem nicht nur ein Ort, an dem man Dokumente ablegt: Es ist eine universelle Schnittstelle. Dieselben Werkzeuge, die ich zum Programmieren, Indexieren, Suchen, Vergleichen, Versionieren oder Transformieren von Daten verwende, können direkt auf meine Dateien wirken.

Google Drive ist ein gutes Gegenbeispiel. Obwohl es ein sehr beliebter Dienst ist, bietet Google keinen vollständigen offiziellen Google-Drive-Client für Linux an. Tatsächlich gibt es eine von der Community gepflegte Seite, How long since Google said a Google Drive Linux client is coming?, die die seit dem 24. April 2012 verstrichene Zeit zählt, als Google mit der Nachricht „hang tight“ andeutete, dass Linux-Unterstützung kommen würde.

Dieses Fehlen zwingt Linux-Benutzer, auf inoffizielle Werkzeuge oder Teillösungen angewiesen zu sein. Einige funktionieren sehr gut, wie rclone, aber sie bleiben alternative Schichten um einen Dienst herum, der nicht in erster Linie für meinen Arbeitsablauf gedacht ist.

Mit Tocho hingegen ist die Situation umgekehrt: Ich kontrolliere den Server, das Protokoll, das Dateisystem, die Verschlüsselung, die Berechtigungen und die Automatismen. Ich bin nicht davon abhängig, dass ein Unternehmen entscheidet, ob Linux eine erstklassige Integration verdient oder nicht.

Das ist eine konkrete Form der technischen Souveränität: nicht nur die Daten zu besitzen, sondern entscheiden zu können, wie auf sie zugegriffen wird.

15. Was wir noch nicht haben: native Fotoverwaltung

Allerdings ist diese Souveränität noch nicht in allen Bereichen vollständig.

Ein offener Punkt ist die Fotoverwaltung. Die kommerziellen Dienste haben den Teil der Benutzererfahrung sehr gut gelöst: automatisches Hochladen vom Handy, geteilte Alben, Miniaturansichten, Zeitleiste, Duplikaterkennung, einfaches Teilen und bequemer Zugriff von jedem Gerät aus.

Tocho bietet dafür noch keine eigene Alternative. Es kann Fotos natürlich als Dateien speichern, bietet aber noch keine Erfahrung, die mit Google Photos, iCloud Photos oder ähnlichen Diensten vergleichbar wäre.

Ein interessanter zukünftiger Schritt wäre, eine eigene Lösung für Fotografie einzurichten, die in der Lage ist:

• automatische Kopien vom Handy zu empfangen;
• Miniaturansichten zu erzeugen;
• Alben zu organisieren;
• Fotos und Alben einfach und kontrolliert mit Freunden und Familie zu teilen;
• die Bilder innerhalb der eigenen Infrastruktur zu halten;
• sich mit dem bereits bestehenden Kopier- und Replikationssystem zu integrieren.

Dieser Teil wäre eine natürliche Weiterentwicklung des Projekts: vom „ich habe die Dateien gespeichert“ zum „ich habe auch persönliche Dienste über meinen Dateien“.

16. Verwendete Hardware

Jede Installation besteht ungefähr aus:

• Raspberry Pi;
• SATA-Festplatte von 16 TB;
• USB-SATA-Adapter, der mit großen Festplatten kompatibel ist;
• geeignetem Netzteil für die Festplatte;
• Gehäuse, Rack oder physischem Halter;
• zusätzlicher Belüftung;
• heimischer Netzwerkverbindung mit Glasfaser.

Ein wichtiges Detail ist, dass nicht alle USB-SATA-Adapter korrekt mit Festplatten großer Kapazität funktionieren. In manchen Fällen kann es Einschränkungen des Chipsatzes, der Firmware, des Typs der USB-SATA-Brücke, der UASP-Unterstützung, der Verwaltung großer Sektoren oder einfach Kompatibilitätsprobleme mit modernen Festplatten von vielen Terabyte geben.

Deshalb war es notwendig, einen zuverlässigeren Adapter zu wählen, auch wenn er teurer war.

17. Kühlung, Geräusch und physische Stabilität

Die Temperatur der Festplatte ist ein wichtiger Faktor für die Langlebigkeit und Stabilität des Systems.

In meinem Fall ist die Festplatte in einer Metallstruktur montiert, die für mehrere Festplatten gedacht ist, obwohl ich derzeit nur eine verwende. Das bietet mehr Metallmasse und damit mehr Wärmeableitungskapazität.

Außerdem verfügt das Rack über einen vom Raspberry Pi aus per PWM gesteuerten Ventilator. Das ermöglicht es, die Geschwindigkeit des Ventilators anzupassen, das Geräusch zu reduzieren und die Festplatte auf einer vernünftigen Temperatur zu halten.

Figura 7

Das Ziel ist nicht, aggressiv zu kühlen, sondern zu vermeiden, dass die Festplatte viele Stunden lang heiß arbeitet. Eine Festplatte, die lauwarm und stabil bleibt, ist einer Festplatte vorzuziehen, die thermischen Spitzen oder mangelhafter Belüftung ausgesetzt ist.

18. Der Fall des Ventilators: wenn Plug and Play es nicht ist

Eine weitere Lehre des Projekts ist, dass heimische Hardware selten so plug and play ist, wie sie verspricht.

In meinem Fall kaufte ich bei AliExpress ein günstiges Rack für drei Festplatten, das theoretisch bereits vorbereitet war und einen mitgelieferten Ventilator enthielt. Die Idee war einfach: die Festplatte montieren, alles anschließen und das System funktionieren lassen.

Aber genau dieser billige, serienmäßig mitgelieferte Ventilator des Drei-Festplatten-Racks hatte ein eindeutig fehlerhaftes Verhalten: Was sich erhitzte, war der Ventilator selbst, nicht die Festplatte, die er kühlen sollte. Im Leerlauf, ohne eine echte Last, die das gerechtfertigt hätte, erreichte der Ventilator in wenigen Sekunden etwa 70 °C. Das heißt, es war nicht die Festplatte, die bei 70 °C war, sondern der Ventilator selbst, etwas, das weder akzeptabel noch sicher war.

Da er ohnehin ersetzt werden musste, tauschte ich den ursprünglichen Ventilator von etwa einem Zentimeter Dicke gegen einen von zwei Zentimetern. Dickere Ventilatoren können mit weniger Aufwand Luft bewegen und sind im Allgemeinen für denselben Durchsatz leiser. Das war wichtig, weil der Server im Wohnzimmer installiert ist, wo das Geräusch ein realer Faktor ist.

Auch der Wechsel war nicht sofort möglich. Ich musste den 3D-Drucker verwenden, um Zylinder oder Adapter-Abstandshalter herzustellen, die es ermöglichten, den neuen Ventilator korrekt im bestehenden Gehäuse zu montieren.

Diese Episode fasst den Charakter des Projekts sehr gut zusammen: Auf dem Papier scheint es nur „ein Raspberry Pi mit einer Festplatte“ zu sein. In der Praxis tauchen viele kleine, aber wichtige Details auf:

• Kompatibilität des USB-SATA-Adapters;
• Stromversorgung der Festplatte;
• Temperatur;
• Geräusch;
• Vibrationen;
• physische Montage;
• Luftstrom;
• angepasste Teile;
• PWM-Steuerung;
• Standort innerhalb des Hauses.

Jedes Detail mag geringfügig erscheinen, aber alle zusammen trennen einen improvisierten Aufbau von einem einigermaßen zuverlässigen System.

19. Überwachung und Prüfungen

Das System enthält mehrere regelmäßige Prüfungen.

Bevor eine wichtige Kopie gestartet wird, wird der Zustand der Festplatte mit smartctl abgefragt. Wenn die Festplatte einen problematischen Zustand oder einen drohenden Ausfall meldet, kann die Kopie übersprungen werden, um zu vermeiden, auf einen potenziell defekten Datenträger zu schreiben oder eine heikle Situation zu verschärfen.

Außerdem gibt es eine stündliche Prüfung, die verifiziert, dass die Maschine erreichbar ist und die Festplatte weiterhin eingebunden oder verfügbar ist. Diese Prüfung fragt auch den freien Speicherplatz mittels df ab.

Einmal am Tag, gegen 7 Uhr morgens, wird eine Nachricht per Telegram mit dem allgemeinen Zustand gesendet. Auf diese Weise bleiben wichtige Probleme nicht wochenlang stumm.

Bisher hat uns Telegram nie im Stich gelassen. Außerdem funktioniert diese tägliche Nachricht wie eine Art Totmannschalter: Wir schauen jeden Morgen um 7 darauf, sodass, wenn sie eines Tages nicht ankäme, das Ausbleiben selbst der Alarm wäre und wir uns sofort Sorgen machen würden.

Figura 8

Ein Punkt, der gestärkt werden muss, ist die regelmäßige Überprüfung des Zustands der Kopien. Es genügt nicht, Logs zu erzeugen: Man muss erreichen, dass der Endzustand sichtbar ist.

Eine klare Verbesserung wäre, in die tägliche Telegram-Nachricht Informationen wie diese aufzunehmen:

• letzte korrekte Kopie jeder Maschine;
• Dauer jeder Kopie;
• Menge der hinzugefügten Daten;
• Anzahl der verarbeiteten Dateien;
• Zustand des Borg-Repositorys;
• Ergebnis des letzten borg check, falls es regelmäßig ausgeführt wird;
• verbleibender freier Speicherplatz;
• SMART-Zustand und Temperatur der Festplatte;
• die Zeitverschiebung zwischen den Knoten (alle werden per NTP auf die Uhrzeit gesetzt, aber dies regelmäßig zu verifizieren hilft, Uhrenprobleme zu erkennen);
• expliziter Hinweis, wenn eine Kopie seit mehr als X Tagen nicht abgeschlossen wurde.

Das würde die Überwachung in ein Werkzeug echten Vertrauens verwandeln, nicht nur in eine oberflächliche Verfügbarkeitsprüfung.

20. Verwaltung des Ruhezustands der Festplatte

Festplatten können sich nach einer kurzen Inaktivitätsphase schlafen legen. Das reduziert Verbrauch, Geräusch und mechanischen Verschleiß, führt aber auch zu einer Spannung zwischen zwei Zielen:

• die Festplatte nicht unnötig aufwecken;
• Probleme schnell genug erkennen.

Aus diesem Grund ist es ratsam, schwere Operationen in bestimmten Zeitfenstern zu bündeln, insbesondere die nächtlichen Kopien. Man muss auch zu aufdringliche stündliche Prüfungen vermeiden, wenn das die Festplatte zwingt, ständig zu drehen.

Die praktische Regel ist, dass häufige Prüfungen leicht sein sollten und Operationen, die die Festplatte eindeutig aufwecken, gerechtfertigt sein sollten.

21. Mit git-crypt verschlüsselte Git-Repositorys

Im Fall von Ismael war eine weitere interessante Linie die Verwendung von Git-Repositorys mit Inhalten, die mittels git-crypt verschlüsselt sind.

git-crypt ist ein Werkzeug, das es ermöglicht, bestimmte Dateien innerhalb eines Git-Repositorys transparent zu verschlüsseln. Die als sensibel konfigurierten Dateien werden verschlüsselt im Repository gespeichert, aber autorisierte Benutzer sehen sie entschlüsselt in ihrem Arbeitsbaum. Die offizielle Beschreibung des Projekts ist genau „transparent file encryption in git“.

Das ist nützlich, wenn man ein normales Git-Repository behalten will, aber ohne Geheimnisse, private Konfigurationen, Schlüssel, persönliche Daten oder Dateien offenzulegen, die nicht im Klartext sein sollten.

Figura 9

Das passt gut zur allgemeinen Philosophie von Tocho: nicht nur auf den Perimeter des Systems zu vertrauen, sondern auch die Daten je nach ihrer konkreten Nutzung zu verschlüsseln.

Mit anderen Worten, es gibt mehrere Schutzschichten:

• GoCryptFS für verschlüsselte Dateibäume;
• Borg für versionierte, deduplizierte und verschlüsselte Kopien;
• git-crypt für Geheimnisse oder sensible Dateien innerhalb von Git-Repositorys;
• SSH mit eingeschränkten Schlüsseln, um zu begrenzen, was jede Maschine tun kann;
• Trennung zwischen lebenden Daten und historischen Kopien.

Das gemeinsame Muster ist klar: Jedes Werkzeug schützt einen anderen Teil des Problems.

22. Abgedeckte Risiken

Tocho deckt mehrere Risikoszenarien recht gut ab.

Ausfall einer Festplatte

Wenn eine Festplatte ausfällt, gibt es noch eine Replik am anderen Standort. In diesem Fall muss man eine neue Festplatte kaufen und die Kopie wiederaufbauen.

Diebstahl

Wenn eines der Geräte gestohlen wird, befinden sich die Daten des anderen weiterhin in einem anderen Haus. Außerdem sind die auf der gestohlenen Festplatte abgelegten Daten verschlüsselt.

Brand oder lokaler physischer Schaden

Eine Katastrophe, die nur einen Standort betrifft, sollte nicht alle Kopien zerstören.

Teilweiser menschlicher Fehler

Wenn versehentlich etwas gelöscht wird und die Kopie noch nicht synchronisiert wurde, kann es möglich sein, es aus der vorherigen Replik wiederherzustellen. Allerdings ist dieser Schutz begrenzt, wenn sich die Löschung oder Korruption bereits mit rsync verbreitet hat.

Kompromittierung einer Client-Maschine

Mit Borg im Append-only-Modus und eingeschränkten SSH-Schlüsseln sollte eine kompromittierte Client-Maschine nicht alle historischen Kopien dauerhaft löschen können.

23. Nicht vollständig gelöste Risiken

Das aktuelle System hat noch wichtige Schwachstellen.

Stille Korruption

Wenn eine Datei beschädigt wird und danach repliziert wird, kann die entfernte Kopie schließlich auch die beschädigte Version enthalten. rsync ist für sich allein kein System zur historischen Integritätsprüfung.

Ransomware auf lebenden Daten

Wenn eine Client-Maschine die sichtbaren Dateien massiv verschlüsselt oder modifiziert und danach eine Synchronisierung ausgeführt wird, kann sich der Schaden auf die Replik ausbreiten.

Teilweises Fehlen einer Historie

Eine einfache Replik schützt vor dem Verlust einer Festplatte, aber nicht immer vor logischen Fehlern. Dafür sind Snapshots, alte Versionen oder für einen Zeitraum unveränderliche Kopien nötig.

Verwundbarkeitsfenster

Zwischen einer lokalen Änderung und der entfernten Kopie gibt es ein Zeitfenster, in dem die neuen Daten noch nur an einem Ort existieren.

Langsamer Wiederaufbau

Im Falle des Verlusts einer kompletten Festplatte kann der Wiederaufbau von 16 TB langsam sein. Bei anhaltenden 100 MB/s dauert das Kopieren von 16 TB etwa 44 Stunden. In der Praxis kann es mehr sein, weil die reale Leistung von der Festplatte, dem Netzwerk, der Verschlüsselung, dem Protokoll und der Anzahl der Dateien abhängt.

Deshalb kann es bei einem vollständigen Wiederaufbau vernünftiger sein, die Festplatte physisch ins andere Haus zu bringen und die erste Kopie lokal oder über ein schnelles lokales Netzwerk anzufertigen.

24. Wiederherstellung nach einer Katastrophe

Im Falle eines vollständigen Ausfalls einer Festplatte wäre das allgemeine Verfahren:

1. Den Ausfall mittels SMART, E/A-Fehlern oder dem Fehlen der Festplatte erkennen.
2. Den betroffenen Knoten als nicht zuverlässig markieren.
3. Die automatischen Synchronisierungen zu dieser Festplatte stoppen.
4. Eine neue Festplatte kaufen oder installieren.
5. Das Dateisystem initialisieren.
6. Die Kopie vom anderen Server wiederherstellen.
7. Integrität und Einbindung des verschlüsselten Systems verifizieren.
8. Die nächtlichen Kopien reaktivieren.

Während des Wiederaufbaus befindet sich das System in einem heikleren Moment, weil es vorübergehend nur eine vollständige Kopie geben kann. Deshalb muss man die Wiederaufbauzeit minimieren und riskante Operationen vermeiden, bis die Redundanz wiederhergestellt ist.

25. Mögliche Verbesserungen

Das Projekt ist in seiner aktuellen Form bereits nützlich, aber es gibt mehrere mögliche Verbesserungen.

Persistenter Zustand „verdächtige Festplatte“

Wenn smartctl eine Situation eines drohenden Ausfalls erkennt, genügt es nicht, eine konkrete Kopie zu überspringen. Es wäre ratsam, die Festplatte in einem persistenten Zustand „blockiert“, „verdächtig“ oder „erfordert manuelles Eingreifen“ zu belassen.

Das würde verhindern, dass eine spätere Ausführung erneut automatisch zu kopieren versucht, bis jemand das Problem überprüft.

Periodische aktive SMART-Tests

Derzeit werden nur die SMART-Attribute vor jeder Kopie gelesen, aber es werden keine aktiven Tests gestartet. Es wäre eine gute Idee, einmal im Monat einen langen Test (smartctl -t long) zu planen: Er durchläuft die gesamte Oberfläche der Festplatte und kann defekte Sektoren erkennen, bevor sie Probleme verursachen. Da es eine langsame Operation ist, die die Festplatte wach hält, ist es ratsam, sie in einem nächtlichen Zeitfenster zu starten und das Ergebnis im täglichen Hinweis festzuhalten.

Snapshots oder Versionen

Um sich besser gegen Ransomware, versehentliche Löschungen oder logische Korruption zu schützen, wäre es interessant, einen Versionierungsmechanismus hinzuzufügen.

Einige Optionen wären:

• Snapshots mit Btrfs oder ZFS;
• Kopien mit rsnapshot;
• BorgBackup- oder Restic-Repositorys;
• Hard Links mit Strategien vom Typ rsync --link-dest;
• Aufbewahrung täglicher, wöchentlicher und monatlicher Versionen.

Integritätsprüfung

Es wäre auch nützlich, über einen Katalog von Hashes oder ein System regelmäßiger Verifizierung zu verfügen, das es ermöglicht, stille Korruption zu erkennen.

Die Herausforderung besteht darin, dies zu tun, ohne die Festplatte ständig aufzuwecken oder die Verifizierung zu einer zu kostspieligen Aufgabe zu machen.

Erkennung verdächtiger Änderungen

Eine weitere interessante Idee wäre ein System, das automatisch verdächtige Änderungen an den Dateien erkennt, bevor sie zur Replik propagiert werden. Wenn zum Beispiel eine Datei ihren Typ ändert — so wie es das Werkzeug file erkennen würde —, könnte das ein Zeichen für Korruption oder Verschlüsselung durch Ransomware sein: Ein Dokument, das plötzlich zu einer undurchsichtigen Binärdatei wird, oder ein Haufen Dateien, die gleichzeitig ihren Typ ändern, ist ein anomales Muster. Das zu erkennen würde es ermöglichen, die Synchronisierung anzuhalten und zu warnen, bevor der Schaden die entfernte Kopie erreicht.

Wiederherstellungstests

Ein Backup, das nie wiederhergestellt wurde, ist nur eine Hypothese. Deshalb wäre es gesund, regelmäßige Wiederherstellungstests durchzuführen, auch wenn sie nur teilweise sind.

Zum Beispiel:

• ein zufälliges Verzeichnis wiederherstellen;
• verifizieren, dass GoCryptFS von einer anderen Maschine aus eingebunden werden kann;
• verifizieren, dass Borg alte Dateien wiederherstellen kann;
• die Wiederherstellungsschritte dokumentieren;
• bestätigen, dass die notwendigen Schlüssel verfügbar sind.

26. Gelernte Lektionen

Eine der wichtigsten Lektionen des Projekts ist, dass der Aufbau einer eigenen Alternative zu Cloud-Diensten nicht umsonst ist, auch wenn man keine monatliche Gebühr zahlt.

Die Kosten sind nicht nur die Festplatte. Man muss auch berücksichtigen:

• den Preis der großen Festplatten;
• kompatible und zuverlässige USB-SATA-Adapter;
• Netzteile;
• Gehäuse, Racks oder physische Halter;
• Kühlung;
• Geräusch;
• Stromverbrauch;
• Verwaltungszeit;
• Überwachung;
• Wiederherstellungstests;
• Schlüsselverwaltung;
• Dokumentation;
• Reaktion auf Vorfälle.

Deshalb ist es eine gefährliche Vereinfachung, gegen das Bezahlen für einen Cloud-Dienst zu sein, nur weil „ich es selbst umsonst machen kann“. Die Realität ist, dass es gut zu machen Geld, Zeit und Wissen erfordert.

Die Schlussfolgerung ist nicht, dass die Cloud immer besser ist. Die Schlussfolgerung ist differenzierter: die kommerzielle Cloud kann teuer erscheinen, bis man alles zusammenrechnet, was es bedeutet, selbst eine zuverlässige Infrastruktur zu betreiben.

In unserem Fall ergibt Tocho Sinn, weil wir lernen, die Daten kontrollieren, technische Fähigkeiten haben und uns der Prozess interessiert. Aber es ist keine magische und auch keine kostenlose Lösung. Es ist echte Infrastruktur, auch wenn sie zu Hause gemacht ist.

27. Zukünftige Ausrichtung des Projekts

Die natürliche Ausrichtung von Tocho ist, sich von einem replizierten NAS zu einem hybriden System weiterzuentwickeln:

• NAS für große Dateien und bequemen Zugriff;
• Borg für versionierte Kopien;
• pro Maschine eingeschränkte SSH-Schlüssel;
• Append-only, um das Risiko entfernter Zerstörung zu reduzieren;
• kontrolliertes Beschneiden vom Server aus;
• tägliche, wirklich umsetzbare Überwachung;
• Trennung zwischen lebenden Daten und historischen Kopien;
• persönliche Dienste über den Dateien, wie eine künftige eigene Fotoverwaltung.

Diese Entwicklung macht das System widerstandsfähiger nicht nur gegenüber physischen Ausfällen, sondern auch gegenüber menschlichen Fehlern, fehlerhaften Skripten und Ransomware-Angriffen.

28. Zusammenfassung: Schritte zum Aufbau deines eigenen Tocho

Wenn jemand eine ähnliche Konfiguration replizieren möchte, sind dies die grundlegenden Schritte in ungefährer Reihenfolge:

29. Abschließende visuelle Zusammenfassung

Figura 10

30. Fazit

Tocho ist ein heimisches System für verteilten Speicher und Backup, das NAS, entfernte Replik, Verschlüsselung und versionierte Kopien kombiniert.

Sein Wert liegt nicht nur in den verfügbaren Terabyte. Er liegt in der Kontrolle: Kontrolle darüber, wo die Daten sind, wer sie lesen kann, wie sie eingebunden werden, wie sie kopiert werden, wie sie überwacht werden und wie sie wiederhergestellt werden.

Seine natürliche Weiterentwicklung ist, den direkten Zugriff auf die kritischen Dateien zu reduzieren und das Gewicht von Append-only-Repositorys zu erhöhen, die widerstandsfähiger gegen menschliche Fehler und Ransomware sind.

Zusammenfassend ist Tocho eine persönliche Infrastruktur technischer Souveränität: nicht perfekt, nicht kostenlos und nicht trivial, aber verständlich, reparierbar und an unsere reale Arbeitsweise angepasst.