VPS Backups: How to Create and Automate Them

To back up a VPS server you need three tools working together: tar to package files, rsync to sync with a remote destination, and cron to run everything automatically. With those three pieces in place, your server is protected without any manual effort.

Why VPS backups are your responsibility

Unlike shared hosting, a VPS provider typically backs up their infrastructure, not your data. If you accidentally delete a database or a script wipes the wrong directory, the provider may have nothing to restore from.

Common data-loss scenarios that strike without warning:

• Human error — a misplaced rm -rf in the wrong directory.
• Ransomware or intrusion that encrypts or deletes files.
• Disk failure, even on reliable hardware.
• A software upgrade that corrupts the database.

The 3-2-1 rule is the minimum standard: 3 copies of your data, on 2 different media, with at least 1 copy off-site.

Essential tools for Linux backups

tar — package and compress

tar bundles entire directories into a single .tar.gz file. It is the simplest way to snapshot a directory.

tar -czf /backup/site_$(date +%F).tar.gz /var/www/mysite

The -c flag creates the archive, -z compresses it with gzip, and -f sets the output filename. The $(date +%F) variable appends today's date so older backups are never overwritten.

mysqldump — export databases

For MariaDB or MySQL, the process is independent of the filesystem. The basic command:

mysqldump -u user -p'password' db_name | gzip > /backup/db_$(date +%F).sql.gz

Always wrap the password in single quotes to prevent the shell from interpreting special characters.

rsync — sync to a remote destination

rsync transfers only the changes since the last run, making it very efficient in terms of bandwidth and time. To push backups to a remote server:

rsync -az --delete /backup/ user@remote-server:/backups/my-vps/

The --delete flag removes files from the destination that no longer exist at the source, keeping the remote folder clean and in sync.

How to automate backups with cron

The cron daemon runs commands on a defined schedule. To edit the current user's crontab:

crontab -e

Example policy running daily backups at 2:00 AM:

# Site file backup
0 2 * * * tar -czf /backup/site_$(date +\%F).tar.gz /var/www/mysite

# Database backup
5 2 * * * mysqldump -u user -p'password' db_name | gzip > /backup/db_$(date +\%F).sql.gz

# Sync to remote server
30 2 * * * rsync -az /backup/ user@remote:/backups/my-vps/

Important: inside a crontab, the % symbol must be escaped as \%.

An all-in-one backup script

It is better to put all the logic in a .sh script and call it from cron. This way you can add logging, notifications, and backup rotation without rewriting the crontab.

#!/bin/bash
DATE=$(date +%F)
BACKUP_DIR=/backup/$DATE
mkdir -p $BACKUP_DIR

# Files
tar -czf $BACKUP_DIR/site.tar.gz /var/www/mysite

# Database
mysqldump -u user -p'password' db_name | gzip > $BACKUP_DIR/db.sql.gz

# Copy to remote
rsync -az /backup/ user@remote:/backups/my-vps/

# Delete local backups older than 7 days
find /backup -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;

echo "Backup $DATE completed" >> /var/log/backups.log

Save this as /usr/local/bin/backup_vps.sh, make it executable with chmod +x, and add to cron: 0 2 * * * /usr/local/bin/backup_vps.sh.

Verification and restoration

A backup that has never been tested is not a backup — it is wishful thinking. Schedule a test restoration at least once a month:

• Extract the .tar.gz to a temporary directory and confirm the files are readable.
• Import the .sql.gz into a test database and verify the tables exist.
• Record how long the restoration took — that is your real RTO.

To restore files from a backup:

tar -xzf /backup/2026-06-20/site.tar.gz -C /var/www/restore/

To restore a database:

gunzip -c /backup/2026-06-20/db.sql.gz | mysql -u user -p db_name

If you manage multiple projects on a single VPS, browse the VPS server guides to evaluate whether a plan with more storage or included snapshots better fits your growth.

Key takeaways

• On a VPS, backup responsibility is yours, not the provider's.
• Use tar for files, mysqldump for databases, and rsync for remote copies.
• Automate with cron or a centralized .sh script for better control and logging.
• Follow the 3-2-1 rule: 3 copies, 2 media types, 1 off-site.
• Test restorations regularly — if recovery fails, the backup is worthless.
• Rotate local backups (7 days) to avoid filling up your VPS disk.

Need a VPS with enough storage for backups and room to grow? At elenlace.com you will find managed plans with dedicated support to help you set up a solid backup policy from day one.

FAQ

How often should I back up my VPS?

It depends on how frequently your data changes. For sites with daily updates (stores, active blogs) a daily backup is the minimum. For applications with frequent transactions, consider backups every 4-6 hours or real-time replication.

Is it safe to store the MySQL password in the script?

The safest approach is to use a ~/.my.cnf file with the credentials and 600 permissions, then reference it with the --defaults-file option in mysqldump. This keeps the password out of command history and the crontab.

What happens if the remote rsync server is unavailable?

rsync will return a non-zero exit code. Your script can capture that code and log it, or send an email alert using mail. The important thing is that the local backup will already have been created even if the remote transfer fails.

Do provider snapshots replace my own backups?

Not entirely. Snapshots are great for quick rollbacks after configuration changes, but they usually live on the same infrastructure as your VPS. A provider-level incident (mass failure, billing error) can affect both the VPS and its snapshots. Always combine both strategies.

Prefer it done for you? El Enlace handles hosting and professional web development.

Further reading

Other providers and guides worth comparing:

• HubSpot
• IONOS
• GoDaddy