Losing data on a Linux server is painful, and it's almost always preventable. This guide walks you through setting up automatic Linux backups using tools like rsync, cron, and tar, so your data is protected without you having to think about it.
Publish date: 5/22/2026
Ask any sysadmin about their worst day on the job, and there's a good chance it involves lost data. A botched update, a runaway rm -rf, a failed drive — any of these can wipe out hours, days, or even months of work in seconds. The fix isn't complicated, though: a well-designed automatic backup strategy means that when something goes wrong (and eventually, something will), you're restoring from last night's backup rather than starting from scratch.
This guide covers how to set up automated Linux backups using tools that come standard on most distros. No paid software required, no vendor lock-in, just solid, time-tested methods you can set up in an afternoon.
The problem with manual backups is simple: people forget to do them. Or they do them inconsistently. Or they back up the wrong directories. Automation removes the human element from a task that really shouldn't depend on humans remembering to do it.
Beyond just running the backup, automation also lets you schedule backups during off-peak hours, rotate old backups to save disk space, and get notified if something fails. That's a lot harder to pull off reliably if you're doing it by hand.
Before jumping into scripts, it helps to know which tools you're working with and why they're suited for the job.
rsync is probably the most widely used backup tool on Linux. It copies files efficiently by only transferring what has changed since the last run, which makes incremental backups fast even over a network. It supports SSH out of the box, so you can back up to a remote server securely without any extra setup.
tar is the traditional Unix archiver. It bundles files and directories into a single archive (usually compressed with gzip or bzip2), which makes it easy to move backups around or store them as snapshots. Unlike rsync, tar creates a complete copy of everything in one file rather than a mirrored directory structure.
cron is the Linux job scheduler. It's what ties everything together by running your backup scripts on a schedule, whether that's nightly, hourly, or weekly.
Duplicati and BorgBackup are worth mentioning as well. Both are open-source tools that handle deduplication, encryption, and remote storage more elegantly than raw rsync or tar scripts. If you want a more feature-complete solution, either of these is worth exploring. But for this guide, we'll focus on the built-in tools since they work everywhere.
Here's a practical rsync command that backs up a directory to a remote server over SSH:
rsync -avz --delete /var/www/ user@backup-server:/backups/www/
Breaking that down: -a enables archive mode, which preserves permissions, timestamps, symlinks, and ownership. -v is verbose output so you can see what's happening. -z compresses data during transfer. --delete removes files on the destination that no longer exist on the source, keeping the backup in sync.
If you're backing up locally (for example, to a second drive mounted at /mnt/backup), just swap the destination:
rsync -av --delete /var/www/ /mnt/backup/www/
For remote backups, it's worth setting up SSH key authentication so the script can connect without prompting for a password. Without that, automated scripts will fail silently.
Rather than running rsync directly from cron, it's cleaner to write a shell script that handles the logic, logging, and any error handling you want.
Here's a starting point:
#!/bin/bash
# Configuration
SOURCE="/var/www /etc /home"
DEST="user@backup-server:/backups/$(hostname)"
LOG="/var/log/backup.log"
DATE=$(date +"%Y-%m-%d %H:%M:%S")
echo "[$DATE] Backup started" >> "$LOG"
for DIR in $SOURCE; do
rsync -az --delete "$DIR" "$DEST" >> "$LOG" 2>&1
if [ $? -ne 0 ]; then
echo "[$DATE] ERROR: Failed to back up $DIR" >> "$LOG"
fi
done
echo "[$DATE] Backup complete" >> "$LOG"
Save this as something like /usr/local/bin/backup.sh and make it executable:
chmod +x /usr/local/bin/backup.sh
Test it manually before adding it to cron:
/usr/local/bin/backup.sh
Check the log file afterward to make sure everything ran correctly.
Once your script is working, cron handles the scheduling.
Open the crontab editor as root:
crontab -e
To run the backup every night at 2 AM, add:
0 2 * * * /usr/local/bin/backup.sh
Cron syntax follows the format: minute, hour, day of month, month, day of week. The asterisk means "every" for that field. If you want to run it more frequently, say every six hours, you'd write:
0 */6 * * * /usr/local/bin/backup.sh
Crontab Guru is a handy tool for generating and verifying cron expressions if you're not confident in the syntax.
Running the same rsync command every night works, but you'll eventually end up with only one copy of your data, and it'll always reflect the most recent state. If a file gets corrupted or accidentally deleted and you don't notice for a few days, your backup will be corrupted too.
Backup rotation solves this by keeping multiple dated snapshots. Here's an approach using tar to create timestamped archives alongside your rsync backup:
#!/bin/bash
BACKUP_DIR="/mnt/backup"
SOURCE="/var/www"
DATE=$(date +"%Y-%m-%d")
ARCHIVE="$BACKUP_DIR/www-$DATE.tar.gz"
# Create a compressed archive
tar -czf "$ARCHIVE" "$SOURCE"
# Delete archives older than 30 days
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +30 -delete
The find command at the end handles cleanup automatically. You can adjust +30 to however many days of history you want to retain, keeping in mind the disk space implications.
File backups alone aren't enough if you're running a database. MySQL/MariaDB and PostgreSQL both need to be dumped properly to get a consistent, restorable backup.
For MySQL/MariaDB:
mysqldump -u root -p"$DB_PASSWORD" --all-databases | gzip > /backups/mysql-$(date +%F).sql.gz
For PostgreSQL:
pg_dumpall -U postgres | gzip > /backups/postgres-$(date +%F).sql.gz
These commands can be added to the same backup script and scheduled via cron alongside your file backups. Store the database password securely, ideally in a restricted file with chmod 600, rather than hardcoding it in the script.
Knowing a backup ran is as important as actually running it. You can configure cron to email you on failure by adding a MAILTO variable at the top of your crontab:
MAILTO=you@yourdomain.com
0 2 * * * /usr/local/bin/backup.sh
This only works if your server has a mail transfer agent configured (like Postfix). For a simpler approach, you can add a curl call inside your backup script to hit a webhook service like Healthchecks.io, which will alert you if a scheduled job stops checking in.
Keeping backups on the same server you're backing up isn't a real backup strategy; if the server fails, you lose both. At minimum, backups should go to a separate machine, a different location, or a cloud storage bucket.
rsync works great over SSH to a remote server. If you want to push to cloud storage, tools like rclone act as a bridge between your Linux server and services like AWS S3, Backblaze B2, or even SFTP destinations, using the same rsync-style syntax you're already familiar with.
A common pattern is the 3-2-1 rule: keep three copies of your data, on two different media types, with one copy offsite. It's a good target to work toward as your backup setup matures.
A backup that you've never restored from is just a backup you hope works. Schedule regular test restorations, even if it's just restoring a single file to verify the archive isn't corrupted. For tar archives:
tar -tzf /backups/www-2025-06-01.tar.gz | head -20
This lists the contents without extracting, letting you confirm the archive is intact. For a full test, restore to a temporary directory:
tar -xzf /backups/www-2025-06-01.tar.gz -C /tmp/restore-test/
Doing this even once a month will save you from the unpleasant surprise of discovering your backups were quietly failing for weeks.
Automated backups don't have to be complicated. With rsync, tar, and cron, you can have a working backup system in place within an hour, one that runs silently in the background and gives you real peace of mind. Start simple, test your restores, and add rotation and offsite storage as you go.
Whether you're running a small project or managing production infrastructure, xTom has the right solution to keep your workloads running reliably. We offer enterprise-grade dedicated servers, colocation services, IP transit, shared hosting, and a full range of IT services and solutions. For fast, scalable VPS hosting with NVMe storage, V.PS is a great fit for any workload, from dev environments to production deployments.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
There's no single answer, but rsync is a great default for most use cases because it's fast, handles incremental transfers well, and works over SSH without any additional software. For more advanced needs like deduplication and encryption, BorgBackup is worth considering.
It depends on how much data you can afford to lose. For production servers, nightly backups are a reasonable baseline; for databases or frequently changing files, hourly or even more frequent snapshots might make sense. The key is matching your backup frequency to your recovery point objective (RPO).
Yes, and it's a good idea. Using rsync over SSH, you can push backups from your VPS to any remote server you have SSH access to. Just set up SSH key authentication first so the process can run unattended.
At minimum, back up /home, /etc, /var/www (or wherever your web files live), and your database dumps. The /etc directory is especially important since it holds your system and application configuration. You generally don't need to back up /tmp, /proc, /sys, or /dev.
Check your log files after each run and, more importantly, do test restores regularly. Listing the contents of a tar archive or restoring a file to a temporary directory confirms the backup is intact and restorable, not just present on disk.
Use backup rotation: automatically delete archives older than a set number of days using a find command with -mtime. Combine this with rsync for live mirrors and tar for point-in-time snapshots, and you'll keep storage manageable while retaining meaningful history.