A Linux server backup is more than a copy of /home. To bring a server back after a disk failure, a hacked system or a deleted VM, you need the right data, the configuration that runs it, a copy that lives somewhere else, and a recovery procedure you have actually tried. This guide explains what to back up on a Linux server, which methods and tools to use, and how to plan a full recovery.
The problem: servers are rebuilt from memory
When a Linux server dies without a proper backup, the team tries to rebuild it from memory: which packages were installed, how Nginx was configured, where the application kept its uploads, which cron jobs ran at night. Something is always missing. Recovery stretches from hours to days, and some data, such as the last database changes or files uploaded by customers, is simply gone.
The consequence for the business is downtime, lost revenue and sometimes a data protection incident to report. A planned Linux server backup turns that rebuild into a restore.
What to back up on a Linux server
| Path or item | Why it matters |
|---|---|
/etc | System and service configuration: web server, SSH, firewall, users, mounts |
/home, /root | User files, SSH keys, scripts kept in home directories |
/srv, /var/www, /opt | Applications and websites, depending on your layout |
/var/lib/<app> | Application state (but see databases below) |
/usr/local | Software and scripts installed outside the package manager |
/var/spool/cron and /etc/cron.* | Scheduled jobs |
| Package list | To reinstall the same software quickly (dpkg --get-selections or rpm -qa) |
| Database dumps | Consistent copies of MySQL, MariaDB, PostgreSQL and others |
| Docker volumes and Compose files | Container data and the definition of the stack |
| TLS certificates and keys | Often under /etc/letsencrypt; included with /etc, but must be encrypted in the backup |
Do not back up /proc, /sys, /dev, /run and /tmp: they are virtual or temporary. Caches such as /var/cache can be excluded to save space.
Databases need special handling
Copying the files under /var/lib/mysql or /var/lib/postgresql while the database is running produces copies that may not start. Dump the databases first, to a directory included in the file backup, using mysqldump --single-transaction, mariadb-dump or pg_dump. See the database backup guide and automatic MySQL backup.
Three methods of Linux server backup
| Method | How | Restore | Best for |
|---|---|---|---|
| File-level | Copies selected directories (restic, Borg, rsync, tar) | Single files fast; full server requires reinstall plus restore | Most servers, especially with configuration management |
| Image-level (bare metal) | Copies the whole disk or system (Relax-and-Recover, Clonezilla, hypervisor backups) | Entire machine at once, including partitions and boot loader | Servers that are hard to rebuild |
| Snapshots | LVM, ZFS, Btrfs or cloud provider snapshots | Very fast rollback on the same storage | Short-term protection before changes; not a backup on their own |
A common and robust combination is a daily file-level backup offsite plus snapshots for fast rollbacks. For virtual machines on Proxmox VE, back up the whole VM at the hypervisor level as well; see the Proxmox VE backup guide.
Choosing a tool
- restic: encrypted, deduplicated, incremental, supports S3, SFTP and many backends. A single binary.
- BorgBackup: encrypted, deduplicated, very efficient compression, usually over SSH to a Borg server.
- rsync: fast synchronization, but no encryption or version history unless combined with hard-link snapshots.
- tar: simple archives, useful for occasional copies, inefficient for daily backups.
- Relax-and-Recover (ReaR): creates a rescue image to restore a whole system onto new hardware, combined with a file backup.
A complete restic setup with scheduling, retention and alerts is described in automatic Linux backup.
A minimal backup for one server
# 1. Dump databases (example: MySQL) into the backup area
mysqldump --defaults-extra-file=/root/.my-backup.cnf --single-transaction \
--routines --triggers --events --all-databases | gzip > /var/backups/mysql-all.sql.gz
# 2. Save the package list
dpkg --get-selections > /var/backups/packages.txt # Debian/Ubuntu
# rpm -qa | sort > /var/backups/packages.txt # RHEL family
# 3. Encrypted, deduplicated backup offsite
restic backup /etc /home /root /srv /var/www /usr/local /var/backups /var/spool/cron \
--exclude-caches
# 4. Retention
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --pruneWhere to store the backup
Follow the 3-2-1-1-0 rule. A second disk in the same server protects only against disk failure. A backup server in the same rack protects against more, but not against fire, flood or an attacker with access to your network. At least one copy must be offsite, encrypted, and preferably immutable for a period (object lock) so ransomware on the server cannot delete it. Read about offsite data center backup to compare options.
Plan the full recovery
Write the procedure before you need it:
- Provision a new server or VM with the same distribution and version.
- Install the backup tool and connect to the repository (you need the password stored outside the server).
- Reinstall packages from the saved list:
dpkg --set-selections < packages.txt && apt-get dselect-upgrade. - Restore
/etccarefully (network settings, disk UUIDs in/etc/fstaband host keys may need adjustment), then the application directories. - Restore databases from the dumps.
- Update DNS, check certificates, test the application, and only then reopen traffic.
Run this procedure on a test machine at least twice a year and measure the time it takes. That number is your real recovery time; compare it with your RTO.
Common Linux server backup mistakes
- Backing up only data and not configuration, or the reverse.
- Copying live database files instead of dumps.
- Keeping the backup encryption password only on the server.
- Treating snapshots or RAID as backups.
- Never testing a full restore.
Backnix is being built to back up Linux servers with a lightweight agent, client-side encryption and offsite storage, with file and full-system recovery. See the server backup page for the current status and the plans and prices.