How to Set Up Automatic Backups for Your Cloud-Hosted Site

Setting up automatic backups on a cloud server means copying your site files and database dump to a safe location outside the main server, on a schedule, without manual intervention. With a cron job, rsync, and mysqldump, you can have this running in under 30 minutes.

This guide shows you exactly how to do it, what retention strategy to use, and how to verify your backups actually work when you need them.

Why Cloud Server Backups Are Non-Negotiable

Many site owners assume their cloud provider handles everything. The reality is more nuanced:

• Provider snapshots are often billed separately by the hour or storage volume, and may not be included in basic plans.
• An automated snapshot taken today could include corrupted or malware-infected files.
• If you delete a file by mistake, relying solely on the provider may leave you with a 24-hour recovery window or longer.
• Running your own backups gives you full control over frequency, retention, and destination.

The golden rule is the 3-2-1 strategy: 3 copies of your data, on 2 different media, with 1 copy stored offsite.

What You Need to Back Up

A cloud-hosted website has two critical components that must be backed up separately:

Backing up only the files without the database — or vice versa — leaves you with a useless backup at restore time.

Step 1 — Create the Backup Script

Create the file /home/your_user/scripts/backup.sh with the content below, adjusting the variables at the top:

#!/bin/bash
# --- Set these variables ---
SITE_DIR="/var/www/html/my-site"
DB_NAME="my_database"
DB_USER="db_user"
DB_PASS="db_password"
BACKUP_DIR="/home/your_user/backups"
RETAIN_DAYS=14
# ---------------------------

DATE=$(date +%Y-%m-%d_%H-%M)
mkdir -p "$BACKUP_DIR"

# File backup
tar -czf "$BACKUP_DIR/files_$DATE.tar.gz" -C "$SITE_DIR" .

# Database backup
mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Remove old backups
find "$BACKUP_DIR" -type f -mtime +$RETAIN_DAYS -delete

echo "Backup completed: $DATE"

After saving, make it executable:

chmod +x /home/your_user/scripts/backup.sh

How to Store Passwords Securely

Never put plaintext credentials in scripts you might accidentally commit to version control. Use a ~/.my.cnf file with 600 permissions:

[client]
user=db_user
password=db_password

Then replace the mysqldump line in the script with:

mysqldump --defaults-file=~/.my.cnf "$DB_NAME" | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

Step 2 — Schedule the Cron Job

Open the cron editor with crontab -e and add the following line to run your backup every day at 2:00 a.m.:

0 2 * * * /home/your_user/scripts/backup.sh >> /home/your_user/logs/backup.log 2>&1

Save the file. Verify the cron was registered with crontab -l.

Recommended Frequency by Site Type

• Blog or static corporate site: daily is sufficient.
• E-commerce or SaaS: every 6–12 hours to avoid losing orders or user data.
• High-traffic site with critical data: consider real-time replication plus daily snapshots.

Step 3 — Copy Backups Off the Server (Offsite)

A backup stored on the same server as your site won't protect you from a disk failure, a hack that wipes everything, or accidental droplet deletion. Copy backups to an external destination.

Common options:

• Provider Object Storage (DigitalOcean Spaces, Hetzner Object Storage, Linode Object Storage) — affordable and easy to integrate with s3cmd or rclone.
• Backblaze B2 — very low cost (≈ $6 USD/TB/month) with S3-compatible API.
• A second server in a different region — use rsync over SSH to a secondary VPS.

Example upload to Backblaze B2 using rclone (pre-configured with rclone config):

rclone copy /home/your_user/backups b2:my-backup-bucket --transfers=4

Add this line at the end of your backup script, after the cleanup step.

If you want expert help designing a custom offsite backup strategy, the team at elenlace.com can design and implement the right solution for your infrastructure.

Step 4 — Verify That Backups Actually Work

A backup you've never tested is no backup at all. Verify your setup with these steps:

1. Run the script manually: bash /home/your_user/scripts/backup.sh and confirm that .tar.gz and .sql.gz files appear in the destination directory.
2. Check the cron log: the day after activating it, review /home/your_user/logs/backup.log to confirm it ran without errors.
3. Do a test restore: extract the tar into a temp directory and import the SQL into a test database. If the site works with those files, the backup is valid.

Run this verification at least once a month. Backup surprises only show up when you need them most.

Find more cloud server management guides in our cloud hosting blog section.

Key Takeaways

• Always back up both components: site files and the database, separately.
• A bash script plus a daily cron job is sufficient for most websites.
• Store database passwords in ~/.my.cnf (mode 600), not in the script itself.
• Copy backups off the server to object storage, Backblaze B2, or a secondary VPS.
• Test a full restore at least once a month to confirm your backups are valid.

Does your site still lack a solid backup strategy? Contact the team at elenlace.com and we'll help you implement an automated, tested system from day one.

FAQ

Does my cloud provider already back up my site automatically?

It depends on your plan. Many providers offer optional snapshots at extra cost, but they're often not enabled by default. Check your dashboard and never assume a backup exists until you've confirmed it. Running your own backups is always the safest practice.

How much storage space do backups take?

A compressed database dump using mysqldump + gzip is typically 10–20% of the original database size. Site files compressed with tar+gzip depend heavily on your image volume. For a typical 500 MB site, a daily backup takes between 50 and 200 MB.

How often should I run backups?

For a blog or corporate site, daily backups are enough. For e-commerce stores or apps with frequent transactions, consider every 6–12 hours to minimize data loss in case of an incident.

How do I restore my site from a backup?

Extract the .tar.gz to your site root (tar -xzf files_DATE.tar.gz -C /var/www/html/my-site) and import the SQL with mysql -u user -p database < dump.sql after decompressing it. Always test the restore in a staging environment first if you're unsure.

Compare providers

Other providers and guides worth comparing:

• Hostinger
• HubSpot
• IONOS