Linux & Backups

Back up Linux configuration: Dotfiles, package lists and data backups

Keep backups local deliberately

Local backups need no upload. Configuration and logs can contain personal information; decide what will be shared before pushing to Git.

In this article
  1. What do you want to recover?
  2. What does Cthulhu save about a system?
  3. Which desktop files are actually included?
  4. Read the project and inspect a local snapshot
  5. What does the current restore implementation do?
  6. Try a recovery before you need it
  7. Git tracks versions; sharing is a separate decision
  8. Sources and reviewed scope

After rebuilding your desktop, you want your familiar keys and settings back. After a drive failure, you also need documents, projects and other data. Both are often called a backup, but they solve different problems. My Cthulhu repository makes that distinction visible.

Cthulhu collects personal configuration and system information from my Linux work. It is material for understanding and rebuilding a setup, not a complete disk image. This guide explains the current script scope and a manageable way to check your own backup.

What do you want to recover?

Backup typeHelps recoverStill missing without extra work
Dotfiles and desktop configurationKeys, bars, colours and application preferencesInstalled applications and dependencies
Package listsA record of installed packagesFile contents and guaranteed identical package versions
NixOS modulesA description of a system setupUncaptured modules, source revisions and personal data
Data backupDocuments, projects and other explicitly selected dataAnything outside the chosen scope

Choose a specific goal. “Restore my Rofi appearance after reinstalling” is easier to check than “everything is somewhere in Git”. Also record the operating system and applications expected to read those saved files.

What does Cthulhu save about a system?

tools/save_system.sh detects the distribution and writes a dated directory. The reviewed version contains these branches:

  • Arch: explicitly installed packages, foreign packages and the kernel version.
  • Debian: dpkg selections, APT source files and the kernel version.
  • Gentoo: available installed-package information, emerge --info, the world file and kernel version.
  • NixOS: existing /etc/nixos/configuration.nix, optionally /etc/nixos/flake.nix, the NixOS version and channel list.

The NixOS scope matters particularly: the script does not automatically copy all of /etc/nixos. An imported hardware-configuration.nix, additional modules or flake.lock need separate inclusion. Finding a main configuration file does not establish complete recoverability.

Running another system snapshot on the same day replaces the existing dated directory. Inspect the destination and keep important older states separately. A date here does not provide unlimited per-run history.

Which desktop files are actually included?

tools/save_core.sh uses fixed source/destination pairs. These include Fastfetch, Rofi, Picom, Dunst, selected window-manager directories and desktop settings. Before replacing an existing repository destination, the helper moves it to a backup name. Missing sources are noted in the log.

The current XMonad mapping reads ~/.xmonad. My newer Gruvnode setup uses ~/.config/xmonad. Sway and Waybar files exist in the repository, but neither is an automatic source pair in the reviewed save_core.sh. Kitty and shell configurations are not automatically included there either.

Make your own inventory of active paths. Sway uses a path such as ~/.config/sway, Waybar ~/.config/waybar. For Gruvnode, also consider XMonad, Xmobar, Rofi, Kitty and ~/.xinitrc. Separate portable desktop settings from credentials and runtime files.

Read the project and inspect a local snapshot

Work in your own local copy. Cloning downloads my published state; it does not automatically upload your later backups:

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

Enter the directory:

cd cthulhu

Read the scripts and their path mappings first. If executable permissions are missing, set them:

chmod +x tools/cthulhu tools/*.sh

Begin by listing available core components:

./tools/cthulhu list core

If the scope fits your system, create a local system snapshot:

./tools/cthulhu save system

Inspect the reported dated directory and logs/cthulhu.log. Are the files you need present and readable? Missing optional tools can be logged without stopping the whole run. Desktop snapshots use ./tools/cthulhu save core; compare its actual paths against your inventory before running it.

What does the current restore implementation do?

Core restore copies selected components back. If a destination exists, the helper asks first and backs up the previous configuration under ~/.config/cthulhu-backup-DATE/. It then replaces that selected destination directory. Check source, destination and backup before proceeding, and close affected applications.

For an already inspected Rofi snapshot, the individual component command is:

./tools/cthulhu restore core rofi

Multiple restores on the same day share a backup root. Keep an important starting state separately. A completion message alone is insufficient: open Rofi afterwards and check how it actually behaves.

System restore is not an automatic rebuild in the current source. The function checks the snapshot directory, prints it and logs the request. It neither copies system files back nor installs packages. That information is a basis for deliberate manual reconstruction.

Try a recovery before you need it

Test one uncritical component before a failure. Record its original path, keep the current state separately and place the snapshot in a test environment or another directory. Compare the files and launch the corresponding application.

  1. Check that the backup actually contains the expected configuration file.
  2. First restore it into a separate test directory.
  3. Compare contents, file permissions and any executable helper scripts.
  4. Test the application with its required packages and appropriate versions.
  5. Record any extra files or steps that were missing.

For NixOS, a build belongs in the check; for XMonad, compilation does. A copied text file can still point at a missing wallpaper, an unavailable launcher or an outdated module name. The NixOS introduction provides a small build-and-test workflow.

Git tracks versions; sharing is a separate decision

Local backups need no cloud upload. A Git push does transmit selected contents to the configured remote and may publish them. Review configurations, logs, paths and keys before committing. Personal backups benefit from a deliberately private destination.

Cthulhu's current push command uses git add -A, staging all repository changes. It is therefore not part of this first snapshot exercise. A .gitignore can exclude new files; it does not remove already tracked files or secrets from earlier commits.

A repository on the same failed disk cannot rescue its data. Keep important copies on an independent medium, protect confidential backups appropriately and test access and recovery. Your personal documents also need their own explicitly chosen backup scope.

Sources and reviewed scope

The Cthulhu descriptions refer to the scripts reviewed on 7 October 2026. Source code determines their current scope.