Linux-Konfiguration sichern: Dotfiles, Paketlisten und echte Backups

Nach einem Desktop-Umbau möchtest du die vertrauten Tasten und Einstellungen wiederhaben. Nach einem Laufwerksausfall brauchst du dagegen auch Dokumente, Projekte und weitere Daten. Beides wird oft „Backup“ genannt, löst aber unterschiedliche Aufgaben. Mein Cthulhu-Repository macht diese Trennung gut sichtbar.

Cthulhu sammelt persönliche Konfigurationen und Systeminformationen aus meiner Linux-Praxis. Es ist ein Ausgangspunkt zum Verstehen und Nachbauen, kein vollständiges Abbild einer Festplatte. Dieser Artikel erklärt den aktuellen Skriptumfang und einen überschaubaren Weg, die eigene Sicherung zu prüfen.

Was willst du später wiederherstellen?

Definiere ein Ziel: „Nach einer Neuinstallation soll Rofi wieder so aussehen“ ist überprüfbarer als „Alles ist irgendwo in Git“. Notiere auch den erwarteten Betriebssystemstand und die Programme, die die gesicherten Dateien lesen.

Was speichert Cthulhu als Systemstand?

tools/save_system.sh erkennt die Distribution und schreibt einen Ordner mit Datum. Im geprüften Stand sind diese Zweige vorhanden:

• Arch: ausdrücklich installierte und fremde Pakete sowie der Kernelstand.
• Debian: dpkg-Auswahl, APT-Quelldateien und Kernelstand.
• Gentoo: verfügbare Paketliste, emerge --info, world-Datei und Kernelstand.
• NixOS: die vorhandene /etc/nixos/configuration.nix, gegebenenfalls /etc/nixos/flake.nix, NixOS-Version und Channel-Liste.

Gerade bei NixOS ist der Umfang wichtig: Das Skript kopiert nicht automatisch ganz /etc/nixos. Eine importierte hardware-configuration.nix, weitere Module oder eine flake.lock müssen zusätzlich gesichert werden. Ein vorhandener Hauptdatei-Name belegt noch keine vollständige Wiederherstellbarkeit.

Ein erneuter System-Snapshot am selben Tag ersetzt den vorhandenen datierten Ordner. Prüfe deshalb den Zielordner und bewahre wichtige ältere Stände separat auf. Das Datum ist hier keine beliebig feine Versionierung jeder Ausführung.

Welche Desktop-Dateien sind tatsächlich erfasst?

tools/save_core.sh enthält feste Pfadpaare. Dazu gehören Fastfetch, Rofi, Picom, Dunst, einige Window-Manager-Verzeichnisse und ausgewählte Desktop-Konfigurationen. Vorhandene Dateien werden vor dem Ersetzen im Repository mit einem Sicherungsnamen verschoben; fehlende Quellen landen als Hinweise im Log.

Die aktuelle XMonad-Zuordnung liest ~/.xmonad. Mein neuerer Gruvnode-Aufbau liegt hingegen unter ~/.config/xmonad. Sway und Waybar sind im Repository vorhanden, aber im geprüften save_core.sh keine automatisch gesicherten Pfadpaare. Auch Kitty und Shell-Konfigurationen sind dort nicht pauschal erfasst.

Erstelle deshalb eine eigene Liste deiner aktiven Pfade. Für Sway etwa ~/.config/sway, für Waybar ~/.config/waybar und für Gruvnode zusätzlich XMonad, Xmobar, Rofi, Kitty und ~/.xinitrc. Trenne kopierbare Desktop-Einstellungen von Zugangsdaten und Laufzeitdateien.

Das Projekt lesen und einen lokalen Snapshot prüfen

Arbeite in einer eigenen lokalen Kopie. Der Clone holt meinen veröffentlichten Stand; er lädt nicht automatisch deine späteren Sicherungen hoch:

git clone https://github.com/dennishilk/cthulhu.git

Wechsle in den Ordner:

cd cthulhu

Lies zuerst die genannten Skripte und ihre Pfadpaare. Falls die Ausführungsrechte fehlen, setze sie:

chmod +x tools/cthulhu tools/*.sh

Zeige zunächst die verfügbaren Core-Komponenten an:

./tools/cthulhu list core

Wenn der Sicherungsumfang zu deinem System passt, erstelle einen lokalen System-Snapshot:

./tools/cthulhu save system

Kontrolliere anschließend den ausgegebenen datierten Ordner und logs/cthulhu.log. Sind die benötigten Dateien vorhanden und lesbar? Fehlende optionale Werkzeuge können protokolliert werden, ohne den gesamten Lauf zu stoppen. Für Desktop-Dateien gibt es zusätzlich ./tools/cthulhu save core, dessen konkrete Pfade du vorher mit deiner Liste abgleichst.

Was kann die aktuelle Restore-Funktion?

Core-Restore kopiert ausgewählte Komponenten zurück. Bei einem bestehenden Ziel fragt der Helfer nach; die bisherige Konfiguration wird unter ~/.config/cthulhu-backup-DATUM/ gesichert. Es ersetzt danach das ausgewählte Zielverzeichnis. Prüfe daher zuerst Quelle, Ziel und Sicherung, und schließe betroffene Anwendungen.

Für eine zuvor geprüfte Rofi-Sicherung lautet der einzelne Komponentenaufruf:

./tools/cthulhu restore core rofi

Mehrere Wiederherstellungen am selben Tag verwenden denselben Sicherungswurzelordner. Bewahre einen wichtigen Ausgangsstand deshalb separat auf. Ein abschließender Text allein genügt nicht: Öffne Rofi anschließend und prüfe sein tatsächliches Verhalten.

System-Restore ist im derzeitigen Quellcode noch kein automatischer Wiederaufbau. Die Funktion prüft den Snapshot-Ordner, zeigt ihn an und protokolliert die Anfrage. Sie kopiert keine Systemdateien zurück und installiert keine Pakete. Die Systeminformationen dienen als Grundlage für einen bewussten manuellen Aufbau.

Eine Wiederherstellung ausprobieren

Teste eine unkritische einzelne Komponente, bevor du einen Ausfall hast. Notiere den Originalpfad, sichere den bisherigen Stand separat und stelle den Snapshot in einer Testumgebung oder unter einem anderen Pfad bereit. Vergleiche Dateien und starte das passende Programm.

1. Prüfe, ob die Sicherung die erwartete Konfigurationsdatei wirklich enthält.
2. Stelle sie zunächst in einem eigenen Testordner bereit.
3. Vergleiche Inhalt, Dateirechte und gegebenenfalls ausführbare Helferskripte.
4. Teste die Anwendung mit den benötigten Paketen und passenden Versionen.
5. Halte fest, welche zusätzlichen Dateien oder Schritte gefehlt haben.

Bei NixOS gehört etwa ein Build zur Prüfung; bei XMonad die Kompilierung. Eine kopierte Textdatei kann trotzdem auf ein fehlendes Hintergrundbild, einen nicht installierten Launcher oder einen alten Modulnamen verweisen. Der NixOS-Einstieg zeigt einen kleinen Build-und-Test-Ablauf.

Git ist Versionierung, Veröffentlichung ist eine Entscheidung

Lokale Sicherungen brauchen keinen Cloud-Upload. Ein Git-Push veröffentlicht beziehungsweise überträgt aber die ausgewählten Inhalte an den konfigurierten Remote. Prüfe vor einem Commit Konfigurationen, Logs, Pfade und enthaltene Schlüssel. Für persönliche Sicherungen ist eine bewusst private Ablage sinnvoll.

Der Cthulhu-Befehl push verwendet aktuell git add -A und erfasst damit alle Änderungen im Repository. Er gehört deshalb nicht zu unserer ersten Sicherungsübung. Eine .gitignore kann neue Dateien ausnehmen; bereits verfolgte Dateien oder Geheimnisse in früheren Commits verschwinden dadurch nicht aus der Geschichte.

Ein Repository auf derselben ausgefallenen Platte rettet deine Daten nicht. Bewahre wichtige Sicherungen auf einem unabhängigen Medium auf, schütze vertrauliche Kopien passend und teste den Zugriff samt Wiederherstellung. Deine persönlichen Dokumente benötigen zusätzlich ihren eigenen festgelegten Sicherungsumfang.

Quellen und geprüfter Umfang

Die Aussagen über Cthulhu beziehen sich auf die Skripte vom 7. Oktober 2026. Der Quellcode ist für den aktuellen Umfang maßgeblich.

• Cthulhu: System-Snapshots
• Cthulhu: feste Core-Pfade
• Cthulhu: Restore-Implementierung
• Kopierhilfen und Sicherungsziele
• Git: Möglichkeiten und Grenzen von gitignore