Backup Strategy for Offshore Servers: What to Automate

Step-by-Step Tutorial

What you will set up

By the end, you will have automatic daily backups of your offshore server — your database and your website files — saved on the server and copied safely off it.

Do one step at a time. Finish a step, check it works, then move on. The goal is simple: if your server breaks tomorrow, you can get your website back.

LevelSome command-line use needed.

Where you workYour server over SSH.

Why do itGet your site back fast if anything fails.

In this tutorialBefore you start The 3-2-1 idea The steps Extra commands Testing FAQ

Before you start

The goal: make backups happen on their own, every day, without you remembering to do it.

A backup is just a copy of your important data. If a server crashes, a hacker gets in, or you delete the wrong thing, a backup is what saves you. The trick is to make the copies happen automatically, so they are always recent.

Keep your server IP, username, and password (or SSH key) ready.
Know the name of your database (you set this when you installed the site).
Make a folder to hold the backups, for example /backups.
Open a notes file and write down your database name and file paths.

The 3-2-1 idea, made simple

You will hear people talk about the “3-2-1 rule.” It sounds technical, but it just means two easy things:

Keep more than one copy. One backup is good. A few recent backups are better — if the latest one is broken, you still have an older one.
Keep them in more than one place. A backup that only lives on the same server is risky. If that server dies, your backups die with it. So always copy a backup somewhere else too.

Backup flow: database and files copied to the server then off the server — Two copies, in two places: on the server, and safely off it.

The steps

Step 1: Back up the database

Your database holds your posts, pages, users, and settings. The mysqldump tool saves all of it into one file. Replace yourdb with your real database name.

mysqldump -u root -p yourdb > /backups/yourdb.sql

It will ask for your database password. The result is one file, /backups/yourdb.sql, that contains your whole database.

Check: run ls -lh /backups — the .sql file should be there with a real size (not 0 bytes).

Step 2: Back up the website files

Your files are the other half: images, themes, plugins, and uploads. The tar command packs the whole website folder into one compressed file. Replace yourdomain.com with your real folder.

tar -czf /backups/site-files.tar.gz /var/www/yourdomain.com

Check: run ls -lh /backups again — you should now see site-files.tar.gz with a real size.

Step 3: Automate it with a cron job

Doing this by hand is easy to forget. A cron job is a built-in timer that runs a command for you on a schedule. Put your backup commands into a small script called /root/backup.sh, then schedule it. This example runs it every day at 2am.

crontab -e
0 2 * * * /root/backup.sh

The line means: at minute 0, hour 2, every day, run /root/backup.sh. Save and close the editor.

Check: run crontab -l — you should see the line you just added.

Step 4: Copy the backups off the server

This is the most important step. If a backup only sits on the same server, a server failure takes your backups with it. So copy them somewhere else — remote storage like an S3 bucket or another disk. The rclone tool does this. (Set up your remote once with rclone config, then this command copies the folder.)

rclone copy /backups remote:offshore-backups

Add this same line to /root/backup.sh so it runs right after the backups are made.

Check: after it runs, log in to your remote storage and confirm the files are there.

Extra commands you may need

Run these only on your own server. If your server uses a managed panel, check with support before changing system-level settings.

Check the backups exist and have a real size

ls -lh /backups

A backup that shows 0 bytes is empty — that means something went wrong. A healthy backup has a real file size.

Confirm the cron job is scheduled

crontab -l

This lists your scheduled jobs. If your backup line is not there, it will never run.

Keep short notes as you go

While you work, jot down each thing: your database name, your website folder path, where the backups go, and the time the cron job runs. For example: “DB = yourdb, files = /var/www/yourdomain.com, backups = /backups, copied to remote:offshore-backups, runs 2am daily.” It sounds small, but it saves a lot of confusion if you ever need to restore in a hurry.

If a command shows output or an error, paste it into your notes too. Then if you ask support for help, you can show the exact command, the exact error, and the exact time.

Always test a restore before you trust it

A backup you have never restored is only a hope, not a safety net. Once in a while, take a backup and restore it onto a staging site (a test copy), never your live site. If the restored site opens and looks right, your backups are real. Don’t wait for a real disaster to find out a backup was broken.

Final checklist after setting up automatic offshore server backups — The final backup checklist.

How to test after setup

Run ls -lh /backups and confirm both files exist with a real size.
Run crontab -l and confirm the daily job is listed.
Run /root/backup.sh by hand once to make sure it works end to end.
Check your remote storage and confirm the copied files arrived.
Wait until after the scheduled time (2am) and check the backups are fresh and dated today.
Restore one backup onto a staging site to confirm it actually works.

Quick troubleshooting

Problem	Likely reason	What to do
Backup file is 0 bytes	Wrong database name, or no permission to read it	Recheck the DB name and your `mysqldump` login details
Cron job did not run	Paths are not absolute, or the script could not be found	Use full paths like `/root/backup.sh`, and check `/var/log/syslog`
Restore test fails	Backup was incomplete or corrupted	Always test a restore on a staging site, not live, and keep older backups too

Final checklist

Database backup works (mysqldump).
File backup works (tar).
Cron job is scheduled and listed.
Backups are copied off the server.
A restore has been tested on staging.

Need a server you can fully control?

OffshoreKaka offers privacy-friendly VPS plans with root access, so you can set up backups exactly like this.

View OffshoreKaka VPS plans

FAQ

How often should backups run?

Daily works well for most sites, like the 2am example here. If your site changes a lot every day — say a busy shop — run them more often and keep several recent copies.

Will good backups improve my Google ranking?

Not directly. But backups keep your site online and let you recover fast after a problem, and a site that stays up and stable is good for SEO. Your content and links still decide your ranking.

What should I send to support if a backup fails?

Send the exact command you ran, the full error message, the output of ls -lh /backups and crontab -l, and the time it ran. That helps support find the cause fast.