To back up a VPS server, you need three things: a script that packages your files and database, a cron job that runs it automatically, and a remote or external destination to store the copies. That combination protects your data even if the server fails completely.
This guide gives you exactly that — a proven workflow to automate backups on any Linux VPS, without relying on control panels or paid tools.
Why Manual Backups Are Never Enough
A backup that depends on someone remembering to run it is a backup that will eventually be missing when you need it most. VPS servers can fail because of a broken update, a ransomware attack, or simple human error.
Automating the process removes that risk. Once configured, the system backs up without any intervention — you only need to worry if a failure alert comes in.
What to Back Up on a VPS
Before writing your first script, decide what data is critical. Most VPS setups need to protect:
- Website files — the
/var/www/folder or equivalent. - Databases — MySQL/MariaDB or PostgreSQL.
- Server configurations —
/etc/nginx/,/etc/apache2/,/etc/php/. - SSL certificates —
/etc/letsencrypt/if you use Certbot. - Cron files and custom scripts —
/etc/cron.d/and your own paths.
Only back up what you would need to rebuild the server from scratch. OS binaries don't need to be included — you can reinstall them in minutes.
A Bash Backup Script
The script below compresses web files and exports MySQL databases into a single dated .tar.gz archive:
#!/bin/bash
# /usr/local/bin/vps-backup.sh
DATE=$(date +%Y-%m-%d)
DEST="/home/backups"
DB_USER="backup_user"
DB_PASS="your_password"
DB_NAMES="db1 db2" # space-separated database names
mkdir -p "$DEST"
# Back up web files
tar -czf "$DEST/web-$DATE.tar.gz" /var/www/ 2>/dev/null
# Back up databases
for DB in $DB_NAMES; do
mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB" \
| gzip > "$DEST/db-$DB-$DATE.sql.gz"
done
# Back up server configs
tar -czf "$DEST/conf-$DATE.tar.gz" \
/etc/nginx/ /etc/letsencrypt/ 2>/dev/null
# Delete backups older than 7 days
find "$DEST" -mtime +7 -delete
echo "Backup $DATE complete."
Save the file, make it executable, and test it manually before scheduling it:
chmod +x /usr/local/bin/vps-backup.sh
/usr/local/bin/vps-backup.sh
Automating with Cron
Once the script works manually, schedule it with cron to run every night. Edit root's crontab:
crontab -e
Add this line to run the backup every day at 2:00 AM:
0 2 * * * /usr/local/bin/vps-backup.sh >> /var/log/vps-backup.log 2>&1
The >> /var/log/vps-backup.log 2>&1 redirection saves both standard output and errors to a log you can review anytime.
Sending Backups Off the Server
A backup living on the same disk as the original data is worthless if that disk fails. You need to copy backups to an external destination: another server, a cloud storage bucket, or a local NAS.
With rsync over SSH you can sync the backup folder to another server:
rsync -avz --delete /home/backups/ user@remote-server:/backups/my-vps/
Add this command at the end of your backup script, or as a separate cron job running a few minutes later. For passwordless operation, set up SSH public key authentication between the two servers.
If you prefer cloud storage, rclone supports Backblaze B2, S3, Wasabi, and dozens of other providers with a similar command.
For more context on choosing and configuring your VPS before reaching this stage, visit the VPS server guide where we cover everything from the basics to advanced administration.
Testing Your Restore Process
A backup that has never been restored is a backup you can't trust. Test the restoration at least once a month in a staging environment:
- Copy the
.tar.gzfile to a temp directory:/tmp/test-restore/ - Extract it:
tar -xzf web-2025-01-15.tar.gz -C /tmp/test-restore/ - Import the database into a separate schema:
mysql -u root test_db < dump.sql - Verify that files and data look correct.
The whole process takes under ten minutes and can save you hours of panic during a real emergency.
Key Takeaways
- Back up web files, databases, and critical configs; skip OS binaries.
- A bash script using
tarandmysqldumpcovers 90% of use cases. - Schedule the backup with cron and log the output for easy auditing.
- Always send backups off the server — via rsync SSH or rclone to the cloud.
- Test your restore process periodically; an unverified backup is not a real backup.
Need a VPS with enough space and bandwidth to run this strategy comfortably? Visit elenlace.com for hosting plans with automatic snapshots, included technical support, and datacenters in Mexico to keep your backups close to your production data.
FAQ
How often should I back up my VPS?
It depends on how much data you can afford to lose. For most websites, daily backups are sufficient. If you run a store or application with constant transactions, consider hourly database backups and daily file backups.
How much space do compressed backups take?
A tar.gz of web files typically lands at 30–50% of the original size. A compressed database dump can shrink to as little as 10%. Reserve at least twice the size of your data to store a full week of rotating backups.
Should I store backups on the same VPS?
Not as the only copy. The same disk holding your data can fail along with the backup. Always use at least one external destination — another server, a cloud bucket, or a local NAS device.
Do I need a dedicated MySQL user for backups?
It's a good practice. Create a user with only SELECT, LOCK TABLES, and SHOW VIEW privileges so the backup script doesn't have write access to the database. This limits the damage if the script were ever compromised.
Prefer it done for you? El Enlace handles hosting and professional web development.
Compare providers
Other providers and guides worth comparing:
