Open Source Backup for Linux Servers

What to Back Up on a Linux Server

Not everything on a Linux server needs to be backed up. The operating system itself can be reinstalled from packages, and configuration management tools like Ansible or Puppet can recreate the system state. Focus your backup resources on data that cannot be recreated.

Always back up:

• /etc: System configuration files, service configs, cron jobs, user accounts, SSH keys
• /home: User data, scripts, personal configurations
• /var/www: Web application files and content
• /var/lib: Application state data (databases, mail spools, Docker volumes)
• /opt: Manually installed applications and their data
• /root: Root user's home directory, including backup scripts and credentials

Usually exclude:

• /tmp and /var/tmp: Temporary files that are regenerated
• /var/cache: Package manager caches, web caches
• /var/log: Optional, unless you need log history for compliance (consider a separate log management solution)
• /proc, /sys, /dev: Virtual filesystems that represent kernel state, not real data
• /usr and /bin: Package-managed system files that can be reinstalled

For containers and orchestrated environments, back up the persistent volumes and configuration (Docker Compose files, Kubernetes manifests), not the container images themselves. Images are built from Dockerfiles and can be rebuilt from source.

Best Tools for Linux Server Backup

BorgBackup is widely considered the best backup tool for Linux servers. All three of its key strengths, storage efficiency, compression flexibility, and SSH-based storage, align perfectly with Linux server environments. Most Linux servers can SSH to other Linux servers, making Borg's SSH-only storage limitation irrelevant. The combination of content-defined chunking, configurable compression (lz4 for speed, zstd for balance, lzma for archival), and mature encryption makes BorgBackup the default recommendation for Linux-to-Linux backup scenarios.

The companion tool borgmatic wraps BorgBackup with a YAML configuration file that defines repositories, backup paths, exclusions, retention policies, and pre/post-backup hooks. Instead of maintaining a shell script, you maintain a declarative configuration. Borgmatic handles the Borg commands, pruning, and consistency checks based on your config.

Restic is the better choice when you need cloud storage backends. If your backup target is Backblaze B2, Amazon S3, Wasabi, or another cloud provider, Restic connects natively without intermediary tools. It also supports parallel uploads, which can saturate high-bandwidth connections better than Borg's single-threaded upload. For a detailed comparison, see BorgBackup vs Restic vs Kopia.

rsync remains a valid choice for simple file mirroring where deduplication is unnecessary. It is pre-installed on virtually every Linux system, uses minimal resources, and works well for synchronizing directories between servers. However, rsync does not provide encryption, deduplication, or snapshot management. Use it as a complement to a dedicated backup tool, not as a replacement.

rdiff-backup combines rsync-like file mirroring with reverse incremental storage. It keeps a current mirror of your data plus reverse diffs that allow you to go back to previous versions. This approach is simpler than chunk-based deduplication but less storage-efficient. It works well for small datasets where simplicity is valued over efficiency.

Database Backup Strategies

Databases require special handling because their on-disk files are in constant flux and cannot be reliably backed up by simply copying them. A backup tool that copies database files while the database is writing to them will produce a corrupted backup that cannot be restored.

PostgreSQL: Use pg_dump for logical backups (SQL dump) or pg_basebackup for physical backups (binary copy of the data directory). Logical backups are smaller and can be restored to different PostgreSQL versions. Physical backups are faster to restore and support point-in-time recovery when combined with WAL archiving. Run the dump command as a pre-backup hook in your backup script, then include the dump file in your BorgBackup or Restic backup.

MySQL/MariaDB: Use mysqldump for logical backups or mariabackup (Percona XtraBackup for MySQL) for hot physical backups. For large databases, physical backups complete much faster than mysqldump because they copy data files directly rather than generating SQL statements. Always use the --single-transaction flag with mysqldump on InnoDB tables to ensure consistency.

MongoDB: Use mongodump for logical backups. For replica sets, take the backup from a secondary node to avoid impacting primary performance. MongoDB also supports filesystem-level snapshots on the data directory if the storage engine is WiredTiger and journaling is enabled.

Redis: Redis provides RDB snapshots (point-in-time dumps) and AOF (append-only file) persistence. The simplest backup approach is to copy the latest RDB file, which Redis writes atomically. Include the RDB file path in your backup tool's source directories.

A common pattern is to run database dumps as a pre-backup hook, store the dumps in a staging directory, and then include that directory in the backup. This ensures the backup contains a consistent database snapshot alongside the filesystem data.

Filesystem Snapshots with LVM and Btrfs

Linux filesystem snapshots provide a way to create a consistent point-in-time view of the filesystem, which the backup tool can then read without worrying about files changing during the backup.

LVM snapshots: If your server uses LVM (Logical Volume Manager), you can create a snapshot of a logical volume before running the backup. The snapshot captures the state of the filesystem at that instant. The backup tool reads from the snapshot, which does not change even as the live filesystem continues to be modified. After the backup completes, remove the snapshot. This approach ensures consistency without stopping services.

# Create LVM snapshot
lvcreate --size 10G --snapshot --name backup-snap /dev/vg0/data

# Mount snapshot read-only
mount -o ro /dev/vg0/backup-snap /mnt/backup-snap

# Run backup from snapshot
restic -r b2:bucket backup /mnt/backup-snap

# Clean up
umount /mnt/backup-snap
lvremove -f /dev/vg0/backup-snap

Btrfs snapshots: Btrfs filesystems support instant, zero-cost snapshots that share data blocks with the original through copy-on-write. Create a read-only snapshot, back it up, then delete the snapshot. Btrfs snapshots are faster to create and have no performance overhead compared to LVM snapshots, which can degrade write performance on the original volume.

# Create btrfs snapshot
btrfs subvolume snapshot -r /data /data/.snapshots/backup-snap

# Back up from snapshot
borg create user@server:/repo::backup-$(date +%Y%m%d) /data/.snapshots/backup-snap

# Remove snapshot
btrfs subvolume delete /data/.snapshots/backup-snap

Scheduling with Systemd Timers

While cron is the traditional choice for scheduling backups on Linux, systemd timers offer several advantages: integration with journald for centralized logging, dependency management (start backup only after network is available), automatic retry on failure, and resource control through cgroups.

A systemd timer consists of two unit files: a service unit that defines what to run, and a timer unit that defines when to run it. The timer unit supports calendar-based scheduling (daily, weekly, specific times) and randomized delays to avoid all machines backing up at the exact same moment.

The key advantage of systemd timers over cron for backup jobs is the OnFailure= directive, which can trigger a notification unit when the backup fails. This provides built-in alerting without adding error handling logic to your backup script.

Multi-Tier Backup Architecture

Production Linux servers should use at least two backup tiers to protect against different failure scenarios.

Tier 1: Local/fast backup. Run hourly or daily BorgBackup to a local backup server or NAS. This provides fast backup and restore for operational recovery, such as accidentally deleted files, bad deployments, or application errors. Restore from this tier in minutes.

Tier 2: Offsite/cloud backup. Run daily Restic to Backblaze B2 or another cloud provider. This protects against physical disasters (fire, flood, theft) and compromised local infrastructure (ransomware that spreads to network storage). Restore from this tier in hours, depending on data volume and download bandwidth.

This two-tier approach implements the 3-2-1 backup rule: three copies of data (production + local backup + cloud backup), on two different media types (server disks + cloud object storage), with one copy offsite (cloud).

For highly critical infrastructure, add a third tier using a geographically distant backup target or cold storage (like AWS Glacier) for long-term archival retention. This protects against regional disasters and provides compliance-grade data retention.