Backing Up a Linux Desktop Properly

3 Aug 2026

A Linux desktop can contain years of work, personal documents, browser profiles, application settings, photos, SSH keys, virtual machines and locally stored email.

Losing the machine does not have to mean losing the data—but only if the backup was designed properly before something went wrong.

Copying a few folders to an external drive is better than nothing, but a reliable backup needs to answer several questions:

What is being backed up?
How often does it run?
Where is the backup stored?
Can older versions be recovered?
Is the backup encrypted?
Has a restore actually been tested?

A proper Linux desktop backup should protect against accidental deletion, failed drives, malware, theft and major disasters such as fire or flooding.

A Backup Is Not the Same as Synchronisation

This is one of the most important distinctions.

A synchronisation service keeps folders matched between devices or cloud storage. If a file is deleted, corrupted or encrypted by ransomware, that change may also be synchronised.

A backup should preserve previous versions and allow you to recover data from before the problem occurred.

Services such as OneDrive, Dropbox, Google Drive and Nextcloud can be useful parts of a protection strategy, but synchronisation alone is not a complete backup.

Follow the 3-2-1 Backup Rule

A strong starting point is the 3-2-1 rule:

Keep three copies of important data.
Store those copies on at least two different types of storage.
Keep at least one copy off-site.

For a Linux desktop, that might mean:

The original data on the computer
A local backup on an external drive or NAS
An encrypted off-site backup in cloud storage or another physical location

This protects against more than a single hard-drive failure.

If the computer and backup drive are stolen together, the off-site copy remains available. If the cloud account is locked or compromised, the local backup still exists.

Decide What Needs Backing Up

Most personal files are stored inside the user’s home directory:

/home/username

The shortcut for the current user’s home directory is:

Important locations may include:

~/Documents

~/Pictures

~/Videos

~/Music

~/Desktop

~/Downloads

~/Projects

There are also hidden files and folders containing application settings.

Hidden names begin with a dot:

~/.config

~/.local

~/.ssh

~/.mozilla

~/.thunderbird

List hidden items with:

ls -la ~

Do not assume that backing up only the visible folders captures everything important.

Files That Are Often Forgotten

A complete desktop backup may also need to include:

Browser profiles and bookmarks
Email profiles and locally stored messages
Password-manager databases
SSH keys
GPG keys
VPN configurations
Development projects
Git repositories
Virtual-machine files
Container data
Application databases
Custom scripts
Desktop and application settings
Locally installed fonts
Scanned documents
Accounting files
Game saves
Flatpak application data

Useful locations can include:

~/.config

~/.local/share

~/.ssh

~/.gnupg

~/.var/app

Some application data may live elsewhere, so review the software you actually use.

What Usually Does Not Need Backing Up

Some data can usually be recreated and may waste backup space.

Examples include:

Browser caches
Thumbnail caches
Temporary files
Package caches
Trash
Rebuildable development dependencies
Downloaded installation media
Swap files
Large disposable virtual-machine snapshots

Possible exclusions include:

~/.cache

~/.local/share/Trash

~/Downloads

node_modules

Do not exclude Downloads automatically if it contains documents or installers that cannot easily be replaced.

Full-System Backup or Personal-Data Backup?

There are two broad backup approaches.

Personal-data backup

This protects the home directory, settings and important user files.

Advantages:

Smaller backups
Faster completion
Easier version history
Easier migration to another computer
Less storage required

The operating system and applications can be reinstalled separately.

Full-system backup

This attempts to capture the operating system, applications, configuration and user data.

Advantages:

Faster recovery to a similar machine
Useful for complex systems
Can preserve customised configurations
May support bare-metal restoration

Disadvantages:

Larger backups
More complicated restores
Hardware differences can cause problems
More system files and temporary data are included

For many desktop users, a good personal-data backup plus a record of installed applications is easier to maintain than a full disk image.

Record Installed Packages

Reinstalling Linux is much easier when you know which applications were installed.

Debian and Ubuntu

Create a package list:

dpkg --get-selections > ~/installed-packages.txt

A more readable list of manually installed packages:

apt-mark showmanual > ~/manually-installed-packages.txt

Fedora and Red Hat-Based Systems

dnf repoquery --userinstalled > ~/installed-packages.txt

Arch Linux

pacman -Qqe > ~/installed-packages.txt

Flatpak

flatpak list --app --columns=application > ~/flatpak-apps.txt

Snap

snap list > ~/snap-packages.txt

Store these lists inside the backed-up home directory.

Use

rsync

for Straightforward File Backups

rsync is one of the most useful Linux backup and copying tools.

A basic home-directory backup might look like:

rsync -aHAX --info=progress2 /home/carl/ /media/carl/BackupDrive/home-carl/

The options mean:

-a — archive mode, preserving most file attributes
-H — preserve hard links
-A — preserve ACLs
-X — preserve extended attributes
--info=progress2 — show overall progress

The trailing slash matters.

This:

/home/carl/

copies the contents of the directory.

Without the trailing slash, rsync may create an additional carl directory inside the destination.

Perform a Dry Run First

Before copying or deleting anything, test the command with:

rsync -aHAXn --delete /home/carl/ /media/carl/BackupDrive/home-carl/

The -n option means dry run.

Nothing is changed, but rsync shows what it would do.

This is particularly important when using:

--delete

The --delete option removes destination files that no longer exist at the source. It is useful for mirrors, but dangerous if the source or destination path is wrong.

A Mirror Is Not Enough

A plain rsync mirror keeps one current copy.

If a file is deleted from the computer and the backup runs with --delete, it may also disappear from the backup.

For proper protection, use one of these approaches:

Keep dated snapshots
Use a versioned backup program
Rotate multiple backup sets
Use a snapshot-capable filesystem
Keep a second offline copy

Version history is what lets you recover yesterday’s copy after today’s file becomes corrupted.

Creating Dated

rsync

Backups

A simple dated backup can use:

backup_date=$(date +%F)

rsync -aHAX /home/carl/ "/media/carl/BackupDrive/backups/$backup_date/"

This creates a new directory such as:

backups/2026-08-01/

The problem is that every backup may store another full copy.

A more space-efficient approach uses hard links to unchanged files, but that requires more careful scripting.

Tools such as rsnapshot provide this behaviour in a managed way.

Using

rsnapshot

rsnapshot uses rsync and hard links to create snapshot-style backups.

Install it on Ubuntu or Debian:

sudo apt update

sudo apt install rsnapshot

Its configuration is commonly stored in:

/etc/rsnapshot.conf

It can maintain schedules such as:

Hourly
Daily
Weekly
Monthly

Unchanged files are hard-linked between snapshots, so they do not consume a full second copy.

Test the configuration:

sudo rsnapshot configtest

Run a manual snapshot:

sudo rsnapshot daily

Be aware that the configuration file traditionally requires tabs in some fields. Follow the package documentation carefully.

BorgBackup: Encrypted, Deduplicated Backups

BorgBackup is a strong option for local, NAS and remote backups.

It provides:

Encryption
Compression
Deduplication
Versioned archives
Integrity checking
Selective restore
Remote repositories over SSH

Install it on Ubuntu or Debian:

sudo apt install borgbackup

On Fedora:

sudo dnf install borgbackup

Create a Borg Repository

For an external drive mounted at /mnt/backup:

borg init --encryption=repokey-blake2 /mnt/backup/carl-borg

Borg will ask for a passphrase.

Store that passphrase securely. If it is lost, the encrypted backup may be unrecoverable.

Export the repository key:

borg key export /mnt/backup/carl-borg ~/borg-repository-key.txt

Store the exported key separately from the computer and backup drive.

Create a Borg Backup

borg create \

--stats \

--compression zstd,6 \

/mnt/backup/carl-borg::'{hostname}-{now:%Y-%m-%d_%H-%M}' \

/home/carl \

--exclude '/home/carl/.cache' \

--exclude '/home/carl/.local/share/Trash'

List the archives:

borg list /mnt/backup/carl-borg

Display information:

borg info /mnt/backup/carl-borg

Apply Borg Retention Rules

A backup repository should not grow forever.

Example:

borg prune \

--list \

--keep-daily=7 \

--keep-weekly=4 \

--keep-monthly=12 \

/mnt/backup/carl-borg

This keeps:

Seven daily archives
Four weekly archives
Twelve monthly archives

Run a compact operation where supported and appropriate after pruning:

borg compact /mnt/backup/carl-borg

Restore From Borg

List files in an archive:

borg list /mnt/backup/carl-borg::archive-name

Extract an archive into the current directory:

borg extract /mnt/backup/carl-borg::archive-name

Restore only one folder:

borg extract \

/mnt/backup/carl-borg::archive-name \

home/carl/Documents

Test restores into a temporary folder rather than overwriting live data immediately.

Restic: Another Strong Backup Option

Restic is another popular encrypted, versioned backup tool.

It supports storage backends including:

Local disks
SFTP
S3-compatible storage
Backblaze B2
Azure Blob Storage
Google Cloud Storage
Other cloud providers through supporting tools

Install it on Ubuntu or Debian:

sudo apt install restic

Initialise a local repository:

restic -r /mnt/backup/restic-repo init

Create a backup:

restic -r /mnt/backup/restic-repo backup /home/carl \

--exclude /home/carl/.cache \

--exclude /home/carl/.local/share/Trash

List snapshots:

restic -r /mnt/backup/restic-repo snapshots

Restore the latest snapshot:

restic -r /mnt/backup/restic-repo restore latest \

--target /tmp/restic-restore

Déjà Dup for Desktop Users

Users who prefer a graphical interface may find Déjà Dup easier.

It supports scheduled backups and integrates well with GNOME-based desktops.

Install it on Ubuntu or Debian:

sudo apt install deja-dup

Depending on the distribution and version, it may support:

Local folders
External drives
Network locations
Cloud-connected storage
Encryption
Scheduled backups
File restoration

A graphical tool is not automatically less reliable than a command-line tool. The important questions are whether it provides version history, encryption, scheduling and tested restores.

Timeshift Is Not a Personal-File Backup

Timeshift is often described as a backup tool, but its primary purpose is creating system snapshots.

It is useful for restoring:

System files
Package changes
Configuration
A machine after a broken update

It normally focuses on the operating system rather than personal documents.

Timeshift should not be the only protection for:

Documents

Pictures

Projects

Personal files

A sensible setup may use:

Timeshift for system snapshots
Borg, Restic, Déjà Dup or another backup tool for personal data

Disk Images and Clonezilla

A disk image captures partitions or entire disks.

Tools such as Clonezilla are useful before:

Replacing a drive
Major partition changes
Risky operating-system upgrades
Hardware migration
Large-scale system changes

Disk images can provide a fast full-system recovery route.

However, they are not ideal as the only daily backup because:

Images can be large.
Individual file restore may be less convenient.
Images may not retain many historical versions.
The system may need to be offline during imaging.
A damaged source can be copied into the image.

Use disk images alongside regular file-level backups.

Back Up to an External Drive

An external USB drive is one of the easiest local backup destinations.

Before using it, confirm its mount point:

lsblk -f

Then:

findmnt

Do not rely solely on the device name such as:

/dev/sdb1

Device names can change.

Use a stable mount point such as:

/mnt/backup

or the desktop-generated mount path under:

/media/username/

Keep the Backup Drive Disconnected

A backup drive that remains connected all the time is vulnerable to:

Ransomware
Accidental deletion
Electrical damage
Malicious commands
Filesystem corruption
Theft with the computer

For home and small-business desktops, a strong approach is:

Connect the backup drive.
Run and verify the backup.
Safely unmount it.
Disconnect it.
Store it separately.

A permanently connected NAS or drive can still be useful, but it should not be the only copy.

Back Up to a NAS

A network-attached storage device can provide automatic backups for several desktops.

Possible protocols include:

NFS
SMB
SFTP
SSH

Before starting the backup, confirm that the network share is actually mounted:

findmnt /mnt/backup

This avoids a dangerous failure where the expected network share is unavailable and backup software writes into an ordinary local directory instead.

A local fallback directory can quietly fill the computer’s root filesystem.

Back Up Over SSH

Borg, Restic and rsync can store data on another Linux machine over SSH.

An rsync example:

rsync -aHAX --delete \

/home/carl/ \

backupuser@backup-server:/srv/backups/carl/

A Borg example:

borg init \

--encryption=repokey-blake2 \

backupuser@backup-server:/srv/borg/carl

Use SSH keys with suitable restrictions and avoid giving the backup account unnecessary access.

Protect the Backup From Ransomware

Ransomware can affect Linux desktops, particularly where compromised accounts, malicious scripts or shared storage are involved.

Useful protections include:

Offline external drives
Immutable or append-only repositories
Backup-account separation
Read-only snapshots
Version retention
Multi-factor authentication
A separate cloud account
Restricted NAS permissions

The computer being backed up should not necessarily have unrestricted permission to delete every historical backup.

Some backup systems support append-only server configurations where clients may create new archives but cannot remove old ones.

Encrypt the Backup

Backups often contain more sensitive information than the live machine because they preserve years of data.

Encryption protects data if the backup drive, laptop or cloud account is stolen.

Possible approaches include:

Borg or Restic repository encryption
LUKS-encrypted external drives
Encrypted cloud backups
Encrypted archives
Filesystem-level encryption

A LUKS-encrypted drive can be created using tools such as:

cryptsetup

This erases or reformats the selected device, so it must be used with extreme care.

Backup encryption introduces one critical responsibility: protecting the recovery key or passphrase.

Keep recovery information:

In a secure password manager
In a sealed offline record
With an authorised business continuity contact
Separate from the backup itself

Back Up SSH and Encryption Keys Carefully

Important key locations may include:

~/.ssh

~/.gnupg

These folders can contain:

SSH private keys
Host configurations
GPG private keys
Encryption identities
Signing keys

They should be included in encrypted backups.

Check their current permissions:

ls -ld ~/.ssh ~/.gnupg

ls -la ~/.ssh

Private keys should not be made broadly readable.

A typical SSH directory uses:

chmod 700 ~/.ssh

Private key files commonly use:

chmod 600 ~/.ssh/id_ed25519

Do not publish or place private keys in an unencrypted cloud folder.

Backing Up an Email Client

Email may be stored remotely on an IMAP server, but local data can still matter.

Thunderbird profiles commonly live under:

~/.thunderbird

The profile may contain:

Local folders
Account settings
Filters
Address books
Cached messages
Extensions

Close the email client before backing up the profile to reduce the risk of capturing files mid-write.

For business email, also confirm that server-side retention and backup policies are appropriate. A desktop copy should not be the only protection.

Backing Up Browser Profiles

Firefox commonly stores profiles under:

~/.mozilla/firefox

Chromium-based browsers may use:

~/.config/google-chrome

~/.config/chromium

Browser profiles can include:

Bookmarks
Extensions
History
Saved sessions
Cookies
Settings
Locally stored passwords

A browser sync service can help, but it may not preserve every item or previous versions.

Close the browser before a manual profile backup where practical.

Backing Up Virtual Machines

Virtual-machine files can be very large and may be inconsistent if copied while the guest is running.

Possible locations include:

~/VirtualBox VMs

~/Virtual Machines

/var/lib/libvirt/images

Before backing up a virtual machine:

Shut it down cleanly, or
Use the hypervisor’s snapshot or backup support.

Do not assume that copying a live virtual disk provides a reliable restore.

Virtual machines may require separate application-aware backup procedures.

Backing Up Databases

A database should usually be exported through its own tools rather than copied while running.

For PostgreSQL:

pg_dump database_name > database_name.sql

For all PostgreSQL databases:

pg_dumpall > all-databases.sql

For MariaDB or MySQL:

mysqldump --single-transaction database_name > database_name.sql

Then include the export in the normal backup.

Copying active database files directly can create an inconsistent backup unless the database or filesystem snapshot process is designed for it.

Back Up Before Major Changes

Create a fresh backup before:

Distribution upgrades
Repartitioning
Replacing drives
Changing encryption
Installing experimental drivers
Editing bootloader configuration
Large application upgrades
Migrating desktop environments
Removing large package groups

Confirm that the backup completed and that files can be restored before starting the risky work.

Automate the Backup

A backup that depends on someone remembering to run it will eventually be forgotten.

Use:

A backup application’s built-in scheduler
A systemd timer
Cron
A NAS backup agent
A desktop startup schedule

For modern Linux systems, a systemd timer provides useful logging and missed-run handling.

Example Backup Script

Create:

sudo nano /usr/local/bin/desktop-backup.sh

Example:

#!/usr/bin/env bash

set -euo pipefail

SOURCE="/home/carl"

DESTINATION="/mnt/backup/carl"

LOG_FILE="/var/log/desktop-backup.log"

if ! mountpoint -q /mnt/backup; then

echo "$(date --iso-8601=seconds) Backup drive is not mounted" \

>> "$LOG_FILE"

exit 1

/usr/bin/rsync \

-aHAX \

--delete \

--exclude='.cache/' \

--exclude='.local/share/Trash/' \

"$SOURCE/" \

"$DESTINATION/" \

>> "$LOG_FILE" 2>&1

echo "$(date --iso-8601=seconds) Backup completed successfully" \

>> "$LOG_FILE"

Make it executable:

sudo chmod 750 /usr/local/bin/desktop-backup.sh

The mount check is essential. Without it, the script could write to the local filesystem when the backup drive is absent.

Remember that this creates a mirror, not versioned history. Use snapshot-capable storage or a versioned backup tool for stronger protection.

Example systemd Service

Create:

sudo nano /etc/systemd/system/desktop-backup.service

Add:

[Unit]

Description=Back up the Linux desktop

RequiresMountsFor=/mnt/backup

[Service]

Type=oneshot

ExecStart=/usr/local/bin/desktop-backup.sh

User=root

Example systemd Timer

Create:

sudo nano /etc/systemd/system/desktop-backup.timer

Add:

[Unit]

Description=Run the desktop backup daily

[Timer]

OnCalendar=daily

Persistent=true

RandomizedDelaySec=15min

[Install]

WantedBy=timers.target

Reload and enable it:

sudo systemctl daemon-reload

sudo systemctl enable --now desktop-backup.timer

Test the service manually:

sudo systemctl start desktop-backup.service

Check the result:

systemctl status desktop-backup.service

Review the logs:

sudo journalctl -u desktop-backup.service

List the timer:

systemctl list-timers desktop-backup.timer

Confirm the Backup Completed

A command exiting without visible errors is not enough.

Check:

The destination exists.
The expected directories are present.
Recent files are included.
The backup size is reasonable.
The logs show success.
The repository passes its integrity checks.
The backup is not unexpectedly empty.

For a simple file backup:

du -sh /home/carl

du -sh /mnt/backup/carl

The sizes do not need to match exactly because of exclusions, compression, sparse files and filesystem differences, but a large unexplained difference deserves investigation.

Verify Borg Backups

Run:

borg check /mnt/backup/carl-borg

For a more extensive archive-data check:

borg check --verify-data /mnt/backup/carl-borg

This can take a long time on large repositories.

Verify Restic Backups

Run:

restic -r /mnt/backup/restic-repo check

To check stored data more thoroughly:

restic -r /mnt/backup/restic-repo check --read-data-subset=10%

The exact amount checked can be adjusted according to the repository size and maintenance window.

Test a Restore

A backup is only proven when data can be restored.

Choose several files:

A recent document
An older version
A hidden configuration file
A photo
A larger file
A file with unusual permissions

Restore them to a temporary location:

mkdir -p /tmp/restore-test

Then compare them with the originals.

For a plain file backup:

cp /mnt/backup/carl/Documents/example.txt /tmp/restore-test/

For Borg:

cd /tmp/restore-test

borg extract \

/mnt/backup/carl-borg::archive-name \

home/carl/Documents/example.txt

Open the restored files and confirm they are usable.

Testing one restore every few months is far better than discovering a problem during an emergency.

Practise a Full Recovery

For important desktops, document how to recover from complete loss.

A recovery plan might include:

Replace or repair the machine.
Install Linux.
Apply system updates.
Reinstall applications from saved package lists.
Install the backup client.
Retrieve encryption keys securely.
Restore the home directory.
Correct ownership and permissions.
Restore application-specific data.
Test email, browsers, SSH and critical software.

Store these instructions somewhere accessible if the original computer is unavailable.

Backup Frequency

The right frequency depends on how much work you can afford to lose.

Possible schedules include:

Hourly for active project folders
Daily for normal personal files
Weekly for system images
Monthly for long-term offline archives
Before major upgrades
Immediately after important work

Ask:

If the computer failed now, how much work would be acceptable to lose?

If the answer is one hour, a weekly backup is not sufficient.

Retention

Retention determines how long previous versions remain available.

A practical policy might keep:

Seven daily backups
Four weekly backups
Twelve monthly backups
One or more annual archives

Longer retention protects against problems that are discovered late, such as quiet file corruption or accidental deletion noticed months later.

Storage capacity and legal or business requirements may affect the policy.

Monitor for Failures

Automated backups should notify you when they fail.

Possible alert methods include:

Email
Desktop notification
Monitoring platform
Log alert
Messaging service
Backup dashboard

A backup system that fails silently is worse than it appears because it creates false confidence.

At minimum, review the latest backup date regularly.

With systemd:

systemctl status desktop-backup.service

For Borg:

borg list /mnt/backup/carl-borg

For Restic:

restic -r /mnt/backup/restic-repo snapshots

Watch Available Backup Space

Check the destination:

df -h /mnt/backup

A full backup drive may cause jobs to fail or old backups to be removed unexpectedly.

Set alerts before the destination reaches critical capacity.

Also check inode usage:

df -ih /mnt/backup

A repository containing very large numbers of files can exhaust inodes before it exhausts disk capacity.

Common Backup Mistakes

Keeping Only One Copy

One external drive can fail, be stolen or become corrupted.

Leaving the Drive Permanently Connected

A connected backup can be damaged by the same incident as the computer.

Using Synchronisation as the Only Backup

Deleted or corrupted files may be synchronised everywhere.

Never Testing a Restore

A successful status message does not guarantee recoverable data.

Backing Up Only Visible Folders

Important settings and keys may be stored in hidden directories.

Forgetting Encryption Keys

An encrypted backup without its key is effectively lost.

Storing the Key Only on the Backed-Up Computer

The key must survive the loss of that computer.

Copying Live Databases or Virtual Machines

The copied files may be inconsistent.

Using

rsync --delete

Without Version History

Accidental deletion may be copied to the backup.

Backing Up to an Unmounted Folder

A failed external or network mount may cause the backup to fill the computer’s internal drive.

Ignoring Backup Logs

Small repeated warnings often appear before a complete failure.

A Practical Linux Desktop Backup Plan

A dependable setup might look like this:

Daily

Run an encrypted Borg or Restic backup of the home directory to a local NAS or external drive.

Include:

Documents

Pictures

Projects

Desktop

Application settings

SSH keys

Email profiles

Browser profiles

Exclude:

Caches

Trash

Temporary files

Rebuildable dependencies

Weekly

Connect an offline external drive and create a second backup.

Disconnect and store it safely afterwards.

Monthly

Verify repository integrity and restore several test files.

Before major changes

Create a fresh backup and, where useful, a disk image or Timeshift system snapshot.

Off-site

Maintain an encrypted copy in cloud storage or another physical location.

This arrangement protects against hardware failure, accidental deletion, ransomware, theft and site-level disasters.

A Pre-Backup Checklist

Before relying on the setup, confirm:

Important folders are included.
Hidden application data has been reviewed.
Caches and disposable data are excluded.
The backup destination is mounted correctly.
Encryption is enabled where required.
The recovery key is stored separately.
Scheduling is active.
Failure notifications work.
Retention rules are configured.
Available backup space is monitored.
At least one off-site copy exists.
A restore has been tested.

Final Thoughts

Backing up a Linux desktop properly is not about choosing one perfect command. It is about building a system that still works when something goes wrong.

A good backup is:

Automatic
Versioned
Encrypted
Monitored
Stored in more than one place
Tested through real restores

For many users, an encrypted Borg or Restic backup combined with an offline external drive provides an excellent balance of security, efficiency and recoverability.

System snapshots and disk images can add useful recovery options, but they should not replace regular file-level backups of personal data.

The most important step is not creating the first backup. It is proving that you can restore from it.

Need Help Protecting Your Linux Data?

Hamilton Group can help configure secure Linux desktop backups, encrypted external storage, NAS backups, off-site protection and tested recovery procedures.

We can review what needs protecting, automate the process and ensure your backups remain usable when you genuinely need them.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our IT specialists.

Previous Next