Das eigentliche Problem hat sich erst ergeben, als sich erhaltenswerte Daten angesammelt haben. Früher, so von 1990 bis 2000, waren meine wertvollsten Daten diverse Spielstände (Helden-Charaktere aus Diablo, Kampagnen bei Command & Conquer, usw.), die vor einem Plattmachen-und-neu-Aufsetzen des Rechners (was bei Windows 95/98 durchaus öfters mal hilfreich war) gerettet werden mussten. Dazu habe ich die diversen Verzeichnisse abgeklappert und die betreffenden Dateien auf eine Diskette kopiert. Meistens hat dazu auch eine einzelne 3,5"-Diskette ausgereicht.
Etwas später kam ich auf die schlaue Idee, die Festplatte in eine System-Partition und eine Daten-Partition zu unterteilen, sodass man die Dateien ohne Wechseldatenträger aus der Schußlinie bringen konnte. Mit etwas Disziplin konnte man die Daten auch gleich dort sammeln, sodass die Sucherei nicht erst im Falle einer anstehenden Neuinstallation losgeht. Diese Aufteilung hatte auch in Dual-Boot-Szenarien Vorteile, wenn z.B. Windows XP und Linux auf der gleichen Maschine koexistieren: Windows kann von Haus aus kein ext2/ext3 lesen, Linux war lange Zeit sehr unbeholfen mit NTFS (zumindest was das Schreiben angeht). Da war eine separate Daten-Partition mit FAT32 als "neutrale Zone" sehr praktisch.
So richtig sicher waren die Daten in diesem Szenario allerdings auch nicht: leicht geht bei Neuinstallation
eines Betriebssystems was schief und man sitzt vor einer Festplatte mit Datenmüll. Um das zu vermeiden habe
ich mir damals eine USB-Festplatte mit üppigen 40 Gigabyte Kapazität gekauft, auf der die wichtigen
Daten landeten. Im Falle einer Neuinstallation konnte man die Festplatte abziehen und war somit vor
Partitionierungs-Pannen gefeit. Dieses Setup ging auch lange Zeit gut, bis ich so ca. 2008 anfing meine privaten
Projekte mit SVN (Subversion) zu verwalten. Mangels eigenen Servers hatte ich mit Repositories im
file://-Schema gearbeitet, was eigentlich ganz gut funktioniert hat... wenn da nicht das
Problem mit den verschiedenen Subversion-Versionen gewesen wäre. Ich meine mich zu erinnern, dass das
Subversion unter Windows neuer war und ständig das Repository-Format upgraden wollte, während die
Version in der Linux-Paketverwaltung etwas älter war, und das neue Format nicht verstanden hätte.
Im Oktober 2009 hatte ich mir einen Barebone-PC (Point of View ION-CS330) gekauft, mit 2 Gigabyte RAM, 320 Gigabyte Festplatte und DVD+/-RW-Laufwerk. Ich glaube damals hatte ich NetBSD darauf laufen. Dieser PC war mein Subversion-Server und hatte auch gleich noch ein Samba-Share für die Ablage gemeinsamer Dateien. Ein manuell angestoßenes Backup-Skript hat alles eingesammelt, ein ISO-Image erzeugt und es auf einen vorher eingelegten CD-Rohling gebrannt. Nach Abschluss des Backups sprang die Schublade auf und das Skript gab eine Anweisung, wie der Datenträger zu beschriften war (z.B. "Backup 2010-03-12"). Irgendwann haben CD-ROMs für das Backup nicht mehr ausgereicht, aber der Sprung auf DVD-Rohlinge hatte hier noch mal einiges an Luft verschafft.
Das ganze hat super funktioniert, ich hatte den Rechner 24/7 laufen und konnte von jedem anderen Rechner/Betriebssystem aus darauf zugreifen. Insbesondere als sich 2011 noch ein Netbook (Asus Aspire One D255) hinzugesellte war es sehr nützlich, ein per Netzwerk verfügbares Laufwerk zu haben. Allerdings kam ich irgendwann auf die Idee, ein Energiemessgerät anzuschließen und habe gesehen, dass dieses Setup rund 40 Watt verbrauchte, was aufs Jahr hochgerechnet stolze 350 kWh ergibt (damals rund 80 EUR, heute ca. 140 EUR). Also begab ich mich auf die Suche nach einer Alternative.
Anfang 2014 hatte ich mir einen Raspberry Pi gekauft, der gegen Ende des Jahres den Platz des Barebone-PCs eingenommen hat, mit der ollen 40-Gigabyte-USB-Festplatte als Massenspeicher. Die Backup-Strategie mit den DVDs hatte gezeigt, dass die Menge an wirklich erhaltenswerten Daten gar nicht mal so groß war, sodass die 40 Gigabyte genügend Platz boten; für die Daten selbst und für mindestens ein Backup. Da der Raspberry Pi keinen DVD-Brenner mehr hatte, musste ich mein Skript so anpassen, dass es die erzeugten ISO-Images auf der Festplatte liegen lässt, damit man sie später per FTPS abtransportieren kann. Als die Images dann irgendwann auf 5 Gigabyte angewachsen sind, habe ich auch aufgehört sie auf DVD zu brennen und sie nur noch auf einem zweiten Rechner gelagert.
Bei der zweiten Filebox hatte ich mit dm-crypt und LUKS herumgespielt und den Inhalt der externen Festplatte mit
AES verschlüsselt. Außerdem kam zu Subversion noch Git hinzu. Alles in allem war das eine ganz gute
Lösung für mich: Dateiablage per FTPS (mit vsftpd), Dateien browsen mit HTTPS und Basic
Authentication, Subversion via HTTPS und Git via SSH.
Die Einrichtung und meine Gedanken dazu hatte ich in meinem Artikel ein Fileserver mit dem Raspberry Pi ausführlich beschrieben.
Im Laufe der Zeit habe ich immer weniger Subversion benutzt und bin 2016 komplett auf Git umgestiegen. In der
Zwischenzeit hatte ich gelernt, dass ein SSH-Server ausreicht, um SFTP zu machen und somit via Filezilla bequem
auf die Daten zugreifen zu können. Ich hatte mich dann entschlossen, die alten Zöpfe abzuschneiden und
bin auf einen Raspberry Pi 3 B umgestiegen, dort einen 32-Gigabyte-USB-Stick als Massendatenspeicher
angeschlossen und war nur noch via SSH unterwegs. Das ISO-Image erzeugende Backup-Skript war immer noch an Bord,
bloß jetzt ohne den Abschnitt mit dem svnadmin dump. Auch auf die verschlüsselte
Datenablage habe ich verzichtet, weil ich mir dachte im Falle eines Unfalls ist es gar nicht so verkehrt, wenn
man von einem anderen System aus auf die Daten zugreifen kann. Ich habe ja nichts zu verbergen...
Zur Filebox 3 habe ich keine Anleitung; tatsächlich ist es auch nur ein Vanilla-Raspbian mit einem nach
/mnt gemounteten USB-Stick auf dem die Git-Repositories und Dateien liegen, plus das
geringfügig angepasste Backup-Skript ohne den GPG-Schritt.
So ab 2020 haben sich meine Aktivitäten im Bereich Computer-Restauration intensiviert und es sind größere Mengen Fotos angefallen, für die ich einen brauchbaren Ablageort gesucht habe. Die Filebox war das nicht, weil der Zugriff via Filezilla zu unbequem und der Speicherplatz unter Berücksichtigung des Backup-Verfahrens auf ca. 10 Gigabyte begrenzt war. Aber zurück in die Situation, dass Betriebssystem und Daten auf dem gleichen Datenträger liegen, wollte ich ganz sicher nicht kommen. Also habe ich im Januar 2021 wieder eine USB-Festplatte gekauft (WD Elements, 2 Terabyte) und an meinen Desktop-PC angeschlossen.
Und wie hätte es anders sein können: es sind wieder die gleichen Probleme und Wünsche aufgekommen: es wäre schön, wenn man von allen Geräten aus an die Daten käme. Insbesondere die Synchronisation zwischen PC und Netbook (inzwischen ein Acer TravelMate B117) wäre extrem wünschenswert. Zwar lassen sich die Fotos am PC eh viel besser bearbeiten, und wenn sie erst mal im Git-Repository der Webseite sind, dann komme ich ja wieder vom Netbook aus dran, aber oft will man doch noch mal schnell was nachschauen (z.B. welcher IC auf der Grafikkarte drauf war) und braucht dafür die Fotos in hoher Auflösung. Außerdem kamen jetzt noch ein paar Jahrgänge diverser Computer-Zeitschriften hinzu, Software-Downloads die darauf warten auf einem Retro-PC in Betrieb genommen zu werden... und das flog wieder auf mehreren Geräten verstreut herum, oft dupliziert und redundant, oder noch schlimmer: fast gleich bis auf winzige Unterschiede. So konnte und sollte es nicht weitergehen; Zeit für eine neue Filebox-Generation.
Durch eine Änderung meines beruflichen Umfelds hatte ich plötzlich viel mit Docker, Containern, der Cloud und ähnlichen Themen zu tun. Da ich sowieso schon längere Zeit vor hatte, auch privat etwas mit Docker herumzuspielen, fiel meine Wahl für die vierte Filebox-Generation auf diese Mittel. Meine Erwartung war auch, dass ich mich weniger mit der Einrichtung der diversen Dienste rumschlagen muss, sondern mehr Zeit mit dem Ausprobieren und Entdecken neuer Anwendungen verbringen kann. In dem Zusammenhang erschien es auch als großer Vorteil, dass man einzelne Container (und damit die darin wohnende Anwendung mit allen ihren Abhängigkeiten) wieder rückstandsfrei runterwerfen kann. Oder besser noch: Wegwerfen auf Probe (= Container stoppen) und wenn man doch noch mal etwas nachprüfen möchte, wieder zurückholen.
(Ja, "normal" installierte Dienste kann man auch starten und stoppen, und sauber als Paket installierte
Anwendungen wird man mit einem apt-get purge auch wieder rückstandsfrei los; das sind keine
Alleinstellungsmerkmale einer Docker-Umgebung. Da war sicher auch ein bisschen "ich will aber mal das neue
Werkzeug benutzen" dabei. Ich habe auch einige Nachteile kennengelernt, teilweise durch das Design der
Container-Images begründet. Komplexität verschwindet nicht.)
Meine Erfahrungen dazu habe ich im Artikel Filebox 4.0: jetzt mit Docker beschrieben.