Building a Linux Rescue Setup for Freelance Developers in 2026

How to stay operational when your workstation fails: backups, reproducible installs, and a ready-to-use rescue machine

Life as a solo entrepreneur is rarely a smooth ride, but the feelings it brings when you have to deliver a project and your workstation crashes are beyond words. So, for those who would rather avoid that experience — myself included — having a peace-of-mind plan in place can save a few hairs… or at least keep them from turning grey.

This article describes a maintenance procedure for a rescue system based on the Linux/Debian family:

• securing your system by planning for its restoration/backup in the event of software incidents,
• maintaining a rescue PC — most likely your old one (in my case, my wife’s Intel Mac) — for hardware incidents.

Data backup and recovery will be covered in a separate article.

System hardening

I use Linux by conviction, based on the Debian distribution, for its stability and apt package management, with Xfce as my desktop environment for its lightweight-to-usability ratio. While my personal preference leans toward plain Debian, I use Linux Mint day-to-day so I can recommend and install it for non-technical people. It is more user-friendly, both in terms of UX and hardware support. Whatever your choice, I recommend installing the system on a btrfs partition so you can take advantage of Timeshift for system backup and restoration.

Btrfs (B-Tree File System) is a modern filesystem with native snapshot support — point-in-time images of your system. Unlike ext4, it creates snapshots almost instantly and without duplicating disk space, thanks to its copy-on-write mechanism.

Timeshift leverages this feature to provide a simple backup/restore interface, comparable to “Time Machine” on macOS or System Restore on Windows.

Installation: *sudo apt install timeshift*

On first launch, the configuration wizard asks you to set:

1. The snapshot type: choose BTRFS if your system partition is indeed btrfs
2. The target partition for storing snapshots
3. The automatic backup frequency (daily, weekly…)
4. The number of snapshots to keep

I recommend creating a first snapshot manually right after installing and configuring your workstation, then taking one before any major update or risky installation.

If something goes wrong, Timeshift lets you restore the system in a few clicks from the GUI, or from the command line if the system no longer boots.

Maintaining a rescue machine

The idea behind a rescue PC is simple: having a machine that can take over immediately in the event of a hardware failure on your main PC. It’s a matter of credibility! With a rescue PC configured identically, getting back to work takes minutes rather than hours or days.

To ensure this continuity of service, the rescue PC must be a software mirror of your main machine. In practice, this means keeping three elements up to date:

• an installation script (*install.sh*) listing all your apt packages
• specific software installed manually (*/opt* + */etc/profile*)
• your personal configuration files (dotfiles)

Installation script (install.sh)

There used to be a now-abandoned tool called *apt-clone* that allowed you to clone an apt installation from one machine to another. It is still available in the repositories, but it is no longer maintained and is unreliable on recent versions of Debian/Ubuntu.

The alternative is to maintain a manual installation script. Here is the approach:

When you first install your system, capture the reference list of manually installed packages: *apt-mark showmanual > APT.ini.txt*

Then, at any point, to get only the packages you have added since that baseline: *comm -23 <(apt-mark showmanual | sort) <(sort APT.ini.txt) > APT.added.txt*

From this list, you — or an AI — can build a clean, commented *install.sh* script. The advantage of a manual script over a blind restore is that you can target any Debian-compatible distribution: plain Debian, Linux Mint, Ubuntu, or lighter distributions like MX Linux or antiX.

For example:

# ============================================
# DEVELOPMENT & COMPILATION
# ============================================
echo "Dev tools..."

# Versioning
apt install -y git                   
apt install -y git-cola gitk         
apt install -y mercurial tortoisehg 

External software

For software not available in the apt repositories (recent JDK, proprietary tools, etc.), I follow the convention of installing in */opt*. This centralises manual installations in a dedicated directory, separate from the apt-managed system, and simplifies maintenance.

The associated environment variables are configured in */etc/profile* so they are available to all users.

ls -l /opt
lrwxrwxrwx  1 user  user    12 sept. 28  2025 jdk -> /opt/jdk-25/

tail /etc/profile
### JAVA
JAVA_HOME=/opt/jdk
PATH=$JAVA_HOME/bin:$PATH

export PATH JAVA_HOME

Dotfiles configuration files

Dotfiles are your personal environment configuration files. Their names start with a dot (hence “dot”), which makes them hidden on Linux. They contain the core of your working comfort: shell aliases, Git configuration, email and browser profiles, SSH keys.

The essential files to copy from */home/<user>/* are:

• *.bashrc* — aliases, variables, shell configuration
• *.gitconfig* — Git identity and preferences
• *.mozilla/* — Firefox profiles and bookmarks
• *.thunderbird/* — Thunderbird accounts and emails
• .*ssh/* — SSH keys and host configuration

Warning: these files contain sensitive information (passwords stored in Firefox, private SSH keys). The destination disk must be encrypted to prevent any compromise in the event of the rescue PC being lost or stolen.

Deploying to the rescue machine

Once your install.sh, /opt software, and dotfiles are kept up to date on the main PC, you need to replicate them to the rescue PC. The go-to tool for this is rsync, which only copies differences and preserves permissions.

For dotfiles:

*rsync -avz ~/.bashrc ~/.gitconfig ~/.ssh/ ~/.mozilla/ ~/.thunderbird/ user@rescue-pc:/home/user/*

For software installed in /opt:

*rsync -avz /opt/jdk-25/ user@rescue-pc:/opt/jdk-25/*

To run the installation script remotely:

*ssh user@rescue-pc ‘bash -s’ < install.sh*

To automate these synchronisations without manual intervention, several options are available:

• cron + rsync: the simplest option — a weekly cron job that pushes updates to the rescue PC
• Syncthing: a continuous synchronisation solution between your machines, ideal when both PCs are often running at the same time
• Jenkins: for those who already have a CI server in place, a Jenkins job can orchestrate the entire update process

Automation will be covered in a future article.

Conclusion

Setting up this rescue system requires an initial investment of a few hours, but it is an insurance policy that proves invaluable at the worst possible moment. When your main PC fails the night before a delivery, having a machine ready in minutes rather than waiting several days for repairs or reinstallation makes all the difference.

The three pillars — a reproducible installation script, software organised in /opt, and saved dotfiles — form a lightweight system that is easy to maintain and applicable to any distribution in the Debian family.

Backing up your data (projects, documents, databases) completes this setup and will be covered in the next article.