How to move backups off your hosting account

Having a backup and having an off-site backup are two different achievements. A great many sites have the first and stop there, because a scheduled backup on the hosting account feels finished — the file exists, the job ran, the box is ticked. It is not finished until a copy of that file is somewhere the hosting account's own problems cannot reach. This guide covers the practical ways to actually get it there.

Manual: download it yourself

The simplest starting point, and worth doing even if you plan to automate later. Connect over FTP or SFTP and pull the latest backup archive down to your own machine. The limitation is entirely human — this only works as an off-site strategy if you actually repeat it on a schedule, which is precisely the kind of task that quietly stops happening once it stops feeling urgent.

Automated: rsync or scp to another server

If you have shell access on both ends and a second server — a VPS you also manage, or space with another provider — rsync over SSH copies only what has changed since the last run, which is efficient for repeated backups of the same growing folder:

rsync -avz -e ssh /home/user/backups/ user@otherserver:/backups/website/

For a one-off copy rather than an ongoing sync, scp does the same basic job more simply:

scp /home/user/backups/latest.tar.gz user@otherserver:/backups/website/

Automated: rclone to cloud storage

For most sites without a second server sitting idle, syncing to a cloud storage account is the more practical option. rclone is a widely used open-source command-line tool built exactly for this — it speaks the API of a large number of cloud storage providers through one consistent interface. After installing it and running rclone config once to set up credentials for your chosen storage account, copying a folder up is one command:

rclone copy /home/user/backups remote:website-backups

Run that on its own, or as the final step of the same script that creates the backup in the first place, so generation and transfer happen together without a separate task to remember.

Which of these to actually pick

They are not mutually exclusive, and running two in parallel is a reasonable way to get redundancy in the transfer method itself, not only in the backup content — if one destination becomes unreachable, the other keeps receiving copies regardless.

Putting it together in one scheduled job

A complete, automated off-site backup is usually three steps chained in one script, run on a cron schedule: dump the database, archive the files, then push the result off the server.

#!/bin/bash
mysqldump -u dbuser -p'dbpass' dbname | gzip > /home/user/backups/db-$(date +%F).sql.gz
tar -czf /home/user/backups/files-$(date +%F).tar.gz /home/user/public_html
rclone copy /home/user/backups remote:website-backups

Scheduled with cron, that removes every manual step from the routine. Automating your backups covers the cron syntax itself if you have not set up a scheduled job before.

Verify the copy that actually left, not just the one that stayed

How much history to keep off-site

Off-site storage, particularly cloud storage, is often cheaper and more durable than the disk your hosting account runs on, which makes it reasonable to keep more history there than you keep locally. A sensible default is to let the server-side backup rotate quickly to save space, while retaining a longer run of off-site copies for the times you need to go further back than the local rotation allows.

None of this needs to be elaborate to be effective. A single scheduled script and one destination you have verified actually receives files satisfies the off-site requirement of the 3-2-1 backup rule completely, and is a small amount of one-time setup compared with the alternative of discovering, during an actual emergency, that your only copy was never really separate at all.