// server management

How to Configure Automatic Backups on a Linux VPS: Complete Guide

August 05, 2026 · by CLIQHOST

How to Configure Automatic Backups on a Linux VPS: Complete Guide

One of the most common mistakes both beginner and experienced server administrators make is postponing backup configuration. "I'll do it tomorrow" too easily becomes "I lost everything yesterday." On a Linux VPS, there is no magic button that automatically saves your data — you have to set it up yourself. The good news: the process is simpler than you think, and this guide walks you through everything step by step.

Why You Need Automated Backups on a VPS

Before diving into the technical details, let's clarify why manual backups simply aren't enough:

  • Human error — An accidentally deleted file, a mistyped command (rm -rf without the correct path), or a failed update can wipe critical data in seconds.
  • Cyberattacks — Ransomware and website defacement are real threats. Without a backup, there's no way to recover.
  • Hardware failures — Even on high-quality SSD VPS servers, infrastructure issues can and do happen.
  • Failed software updates — A kernel or application update can break the entire system.

A solid backup strategy follows the 3-2-1 rule: 3 copies of your data, on 2 different storage types, with 1 copy stored off-site.

Required Tools

This guide uses native Linux tools available on any distribution (Ubuntu, Debian, CentOS, AlmaLinux):

  • tar — for archiving directories
  • rsync — for efficient incremental synchronisation
  • cron — for automatic task scheduling
  • mysqldump — for exporting MySQL/MariaDB databases
  • (Optional) rclone — for automatic cloud upload (Google Drive, S3, Backblaze)

Step 1: Create the Backup Directory Structure

Connect to your VPS via SSH and create an organised structure:

mkdir -p /backup/{files,databases,logs}
chmod 700 /backup

The /backup directory will contain:
- /backup/files — archived server files
- /backup/databases — MySQL dumps
- /backup/logs — backup operation logs

Step 2: File Backup Script Using tar

Create the file /usr/local/bin/backup-files.sh:

nano /usr/local/bin/backup-files.sh

Add the following content:

#!/bin/bash

DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backup/files"
SOURCE_DIRS="/var/www /etc /home"
LOG="/backup/logs/files-$DATE.log"
RETENTION_DAYS=7

echo "[$(date)] Starting file backup..." >> "$LOG"

tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" $SOURCE_DIRS 2>> "$LOG"

if [ $? -eq 0 ]; then
  echo "[$(date)] Backup successful: files-$DATE.tar.gz" >> "$LOG"
else
  echo "[$(date)] ERROR during backup!" >> "$LOG"
fi

# Remove archives older than $RETENTION_DAYS days
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
echo "[$(date)] Old archive cleanup complete." >> "$LOG"

Save and make the script executable:

chmod +x /usr/local/bin/backup-files.sh

What this script does:
- Archives /var/www, /etc, and /home — where websites, configurations, and user data live
- Saves the archive with the date in the filename (e.g., files-2025-01-15.tar.gz)
- Automatically deletes archives older than 7 days to save disk space
- Logs every operation to a log file

Step 3: MySQL Database Backup Script

Create /usr/local/bin/backup-databases.sh:

#!/bin/bash

DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backup/databases"
DB_USER="root"
DB_PASS="your_mysql_password"
LOG="/backup/logs/db-$DATE.log"
RETENTION_DAYS=7

echo "[$(date)] Starting database backup..." >> "$LOG"

# Export each database separately
for DB in $(mysql -u"$DB_USER" -p"$DB_PASS" -e "SHOW DATABASES;" 2>/dev/null | grep -Ev "(Database|information_schema|performance_schema|sys)"); do
  mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB" 2>> "$LOG" | gzip > "$BACKUP_DIR/$DB-$DATE.sql.gz"
  echo "[$(date)] Backup complete for: $DB" >> "$LOG"
done

find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete
echo "[$(date)] Old dump cleanup complete." >> "$LOG"

Security tip: Avoid storing the MySQL password in plain text in the script if the server has multiple users. Use the ~/.my.cnf file with restricted permissions instead:

ini [client] user=root password=your_mysql_password
Then run: chmod 600 ~/.my.cnf and remove the DB_USER/DB_PASS variables from the script.

Make the script executable:

chmod +x /usr/local/bin/backup-databases.sh

Step 4: Incremental Synchronisation with rsync (Optional but Recommended)

If you have a second server or a remote storage location, rsync is ideal for fast and efficient synchronisation — it only transfers changed files:

rsync -avz --delete /backup/ user@remote-server:/external-backup/

You can add this command to a third script or directly to crontab.

Step 5: Automation with cron

This is the step that turns manual backups into truly automated ones. Open the root crontab:

crontab -e

Add the following lines:

# File backup — daily at 02:00
0 2 * * * /usr/local/bin/backup-files.sh

# Database backup — daily at 03:00
0 3 * * * /usr/local/bin/backup-databases.sh

Cron syntax breakdown: minute hour day_of_month month day_of_week command

  • 0 2 * * * — every day at 02:00
  • 0 3 * * * — every day at 03:00

Backups are scheduled at night to avoid impacting server performance during peak hours.

Step 6: Automatic Cloud Upload with rclone

To properly follow the 3-2-1 rule, backups must also exist off-site. rclone supports dozens of cloud storage providers.

Install:

curl https://rclone.org/install.sh | sudo bash

Interactive setup (example for Backblaze B2 or Google Drive):

rclone config

Follow the wizard steps, select your provider and authenticate. Then add to crontab:

# Upload backups to cloud — daily at 04:00
0 4 * * * rclone sync /backup/ backblaze:vps-backup-bucket/ --log-file=/backup/logs/rclone.log

Step 7: Test Your Backups Regularly

A backup you've never tested is as good as no backup at all. Check monthly that:

  1. Archives exist and are not corrupted:
    bash tar -tzf /backup/files/files-$(date +%Y-%m-%d).tar.gz | head -20

  2. MySQL dumps can be restored:
    bash gunzip -c /backup/databases/dbname-$(date +%Y-%m-%d).sql.gz | mysql -u root -p test_restore

  3. Logs contain no errors:
    bash grep -i error /backup/logs/*.log

Monitoring Backup Disk Usage

Periodically check how much space your backups consume:

du -sh /backup/*
df -h /

If your VPS has limited disk space, reduce RETENTION_DAYS to 3–5 days and rely on cloud storage for longer retention.

Common Mistakes to Avoid

  • Storing backups on the same disk — if the disk fails, you lose both data and backups. Always sync off-site.
  • Backups without testing — a corrupted archive discovered during a disaster is useless.
  • Plaintext passwords in scripts — use ~/.my.cnf or secure environment variables.
  • Ignoring logs — scripts can fail silently. Check logs weekly.
  • Retention period too short — ransomware can go undetected for days. Keep at least 7 days of backups.

Conclusion

Setting up automatic backups on a Linux VPS doesn't require expensive or complex solutions. With tar, mysqldump, cron, and optionally rclone, you can build a robust system in under an hour that protects your data every single day.

The key is not to wait: every day without a backup is a day you risk losing everything.


If you manage a VPS and would rather focus on your business than handle backups manually, CLIQHOST offers SSD VPS plans with managed backup options and round-the-clock technical support.

SHARE
// what clients say

What Our Clients Say

Real reviews from customers who trust CLIQHOST for performance, reliability and expert technical support.

★★★★★

"We moved our online shop from a foreign host and the difference is night and day — pages load instantly and support replies in minutes, in Romanian."

AM
Andrei M.
eCommerce owner · Chișinău
★★★★★

"Migrated 12 client sites to CLIQHOST. Free migration, zero downtime, and the cPanel setup is exactly what my team needed. Highly recommend."

EV
Elena V.
Web agency · Bălți
★★★★★

"Our NVMe VPS handles traffic spikes without a sweat. Full root, local datacenter, and billing in MDL — everything we wanted from a provider."

DC
Dmitri C.
SaaS founder · Chișinău