How to Automate Daily and Weekly Backups on Your VPS Server

How to Automate Daily and Weekly Backups on Your VPS Server featured image - Onlive Server

Data loss can turn a routine server problem into a serious business issue. An accidental deletion, damaged database, failed storage device, ransomware attack, or faulty software update can make a website or application unavailable when you do not have a reliable recovery copy.

A practical VPS backup automation setup reduces this risk by creating backups on a regular schedule. The backup process can archive and encrypt your website files, databases, and configuration data before copying them to off-site storage.

If your applications run on VPS hosting plans, the following process gives you a practical starting point for building an automated backup and recovery workflow.

1. Start With the 3-2-1 Backup Rule

Before you create an automatic VPS backup script, decide where you will keep each backup. The 3-2-1 backup rule provides a useful starting point.

3 Copies of Data

Keep your production data and two additional backup copies.

2 Different Storage Types or Systems

Do not depend on one disk or storage system for both production data and every backup.

1 Copy Off-Site

Keep at least one backup outside your production server environment. You can use independent object storage, another backup server, or another suitable remote location.

The idea is simple. A problem with your production VPS should not destroy every recovery copy at the same time.

2. Decide What Your VPS Backup Should Include

A backup only helps when it contains everything you need to restore the service. For a typical web server, consider backing up:

  • Website and application files
  • MySQL or MariaDB databases
  • Application configuration files
  • Web server configuration
  • Important scheduled-job configuration
  • Other application-specific data required for recovery

Do not assume that copying /var/www/html/ gives you a complete recovery copy. A database-driven application normally needs both its files and database data.

3. Store Database Credentials Safely

Do not put a MySQL root password directly inside your backup script. Someone may copy, log, expose, or accidentally share a script that contains database credentials.

Instead, you can use a protected MySQL client configuration file for a dedicated backup account. For example:

MySQL client configuration
[client]
user=backup_user
password=YOUR_SECURE_PASSWORD

Give this file restrictive permissions. Also use a dedicated database account with only the privileges required for the backup task. The privileges you need will depend on the databases and objects you want to export.

Terminal
chmod 600 /root/.my.cnf

4. Create an Automatic VPS Backup Script

The next step is to automate the backup process. The example below creates a temporary directory, exports MySQL databases, archives website files, packages the backup, and encrypts it with GPG.

It then uses Rclone to copy the encrypted archive to remote storage. Finally, the script removes its temporary local files.

Important: Use this script as a starting template. Replace the example GPG recipient and Rclone destination with your own configured values. You should also test the paths, permissions, encryption keys, remote storage, and restore process before using the script on a production server.
automated_backup.sh
#!/bin/bash

set -euo pipefail

TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S")
BACKUP_DIR="/tmp/backup_$TIMESTAMP"
ARCHIVE="/tmp/vps_backup_$TIMESTAMP.tar.gz"
ENCRYPTED="${ARCHIVE}.gpg"
DEST_REMOTE="remote_s3:my-company-backups/daily"
GPG_RECIPIENT="backup@example.com"

mkdir -p "$BACKUP_DIR"

# Export MySQL databases
mysqldump \
  --defaults-extra-file=/root/.my.cnf \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  > "$BACKUP_DIR/databases_$TIMESTAMP.sql"

# Archive website files
tar -czf "$BACKUP_DIR/webfiles_$TIMESTAMP.tar.gz" /var/www/html/

# Package the backup
tar -czf "$ARCHIVE" -C "$BACKUP_DIR" .

# Encrypt before off-site transfer
gpg --batch --yes \
  --output "$ENCRYPTED" \
  --encrypt \
  --recipient "$GPG_RECIPIENT" \
  "$ARCHIVE"

# Upload encrypted backup
rclone copy "$ENCRYPTED" "$DEST_REMOTE"

# Remove temporary local files
rm -rf "$BACKUP_DIR" "$ARCHIVE" "$ENCRYPTED"

This workflow includes a real GPG encryption step before Rclone transfers the archive to off-site storage.

5. Schedule VPS Backups With Cron

Test the backup script manually first. Once you know it works correctly, use Linux cron to run it automatically.

For example, the following cron job runs the script every day at 2:00 AM:

root crontab
sudo crontab -e

0 2 * * * /opt/scripts/automated_backup.sh >> /var/log/backup_cron.log 2>&1

Choose the backup frequency according to how often your data changes. An online store that receives orders throughout the day may need more frequent backups than a mostly static business website.

Practical tip: Run resource-intensive backups during quieter periods when possible. However, your recovery requirements should determine the backup frequency.

6. Keep an Off-Site Backup Copy

Keeping every backup on the same VPS creates a single point of failure. A serious server or storage problem could affect both your live data and local backup files.

Off-site storage gives you an independent recovery copy. Depending on your requirements, you can use object storage, another backup server, or a separate private cloud storage system.

If you want to build a separate storage environment, this guide to storing backups on private cloud storage provides additional information.

7. Set a Backup Retention Policy

Automated backups can consume a large amount of storage if you keep every archive forever. A retention policy tells your backup system which copies to keep and when to remove older ones.

For example, you may keep several recent daily backups, fewer weekly copies, and selected monthly archives for longer-term recovery.

There is no single retention period that works for every VPS. Choose one based on your available storage, recovery needs, compliance requirements, and how often your data changes.

8. Test the Restore Process

A successful backup upload does not prove that you can recover the application.

Restore a backup periodically in a separate test or staging environment. Check that you can decrypt the archive, extract the files, import the database, and start the application with the restored data.

A useful backup is one you can successfully restore. Restore testing can reveal missing files, damaged archives, incorrect permissions, forgotten encryption keys, and incomplete database exports before an emergency occurs.

9. Monitor Your Automated Backup Jobs

Do not treat cron backups as a “set it and forget it” process. A job may fail because the server runs out of storage, credentials change, the remote destination becomes unavailable, or one of the backup commands returns an error.

Check your backup logs regularly. You can also configure monitoring or notifications to alert you when a job fails.

Check the remote storage as well. Make sure new backup archives arrive according to your expected schedule.

Backup planning should also work alongside good server security. This guide to VPS server hardening covers additional steps for protecting an internet-facing VPS.

Frequently Asked Questions

Why shouldn’t I keep every backup on the same VPS?

A server or storage failure could damage both your production data and local backups. Keeping an independent off-site copy gives you another recovery option.

How often should I test VPS backups?

Test restores regularly and whenever you make a major change to your application or backup process. Critical systems usually need more frequent recovery testing than low-risk workloads.

Does mysqldump –single-transaction prevent database downtime?

For transactional tables such as InnoDB, --single-transaction can create a consistent dump without holding a global read lock for the entire export. The exact behavior still depends on the database engine, workload, and options you use.

Can Rclone be used for encrypted cloud backups?

Yes. Rclone supports encrypted remotes through its crypt backend. You can also encrypt an archive before Rclone transfers it, as shown in the example above. Whichever method you choose, test the decryption and restore process.

Are VPS snapshots the same as backups?

Not always. A snapshot records the state of a virtual disk or machine at a specific point in time. File and database backups can provide more granular recovery. Snapshots are useful, but they should not automatically replace an independent off-site backup strategy.

How long should VPS backups be retained?

Your retention period should match your recovery needs, available storage, and compliance requirements. Many environments keep recent daily copies plus selected weekly or monthly restore points.

Conclusion

Reliable VPS backup automation involves more than running a script every night. A practical strategy combines scheduled file and database backups, secure credential handling, encryption, off-site storage, sensible retention, monitoring, and regular restore tests.

The 3-2-1 rule provides a solid foundation. Cron can handle the schedule, while tools such as Rclone can move backup archives to remote storage. However, automation only helps when you monitor the jobs and confirm that the backups actually work.

Most importantly, test the complete recovery process before an emergency happens. A backup becomes valuable when it gives you a reliable way to bring your website or application back online.