Quick answer: Create a dedicated user on the Storage VPS, install your SSH key, then run rsync from the production server on a cron schedule. A minimal working setup takes about ten minutes and gives you automated, incremental offsite backups every night.
Overview
This is the canonical Cloud2Y backup pattern: production pushes its data over SSH to a Storage VPS in another location. rsync only transfers changed files, so nightly runs are quick and bandwidth-friendly; a dated snapshot layout adds point-in-time restore on top.
Before you start
- A Storage VPS (how to order one) and root/SSH access to the production server being backed up.
- Enough free space on the target for at least the first full copy (see estimating size).
- An SSH key pair for automation — password prompts and cron do not mix.
Step-by-step guide
- On the Storage VPS, prepare a user and a target directory:
adduser backupuser mkdir -p /srv/backups/web1 && chown -R backupuser:backupuser /srv/backups - On the production server, create a key and install it:
ssh-keygen -t ed25519 -f ~/.ssh/backup_key -N "" ssh-copy-id -i ~/.ssh/backup_key.pub [email protected] - Test a manual sync of your data directories:
rsync -avz -e "ssh -i ~/.ssh/backup_key" /var/www/ [email protected]:/srv/backups/web1/www/ - Dump databases first, so backups are consistent:
mysqldump --all-databases | gzip > /var/backups/db.sql.gz - Put both steps in a script and schedule it with cron, e.g. daily at 03:30:
30 3 * * * /usr/local/bin/backup-to-storage.sh >> /var/log/backup.log 2>&1 - Verify the next morning: files present on the Storage VPS, log has no errors, sizes look right.
Common issues
- Cron job silently failing: use absolute paths in the script and log output as shown above — see automating backups with cron.
- Backups without databases: copying live database files is unreliable; always dump, then sync the dump.
- No history: a plain mirror overwrites yesterday's state — add dated directories or use restic/borg for real snapshots (see retention).
When to contact support
Cloud2Y supports the platform, and your backup jobs are your own to run — but if the Storage VPS itself misbehaves (disk errors, network drops during transfers), open a ticket with timestamps and logs.
Frequently asked questions
How long does the initial backup take?
The first run copies everything, so it depends on data size and bandwidth; subsequent rsync runs transfer only changed files and typically finish in a small fraction of that time.
Why dump databases instead of copying their files?
Live database files change mid-copy and often restore corrupted. A mysqldump or pg_dump produces a consistent snapshot that reliably imports on any compatible server.
How do I know the nightly backup actually ran?
Log every run to a file and check for the success line — for example a final "backup OK" entry with a timestamp. A missing line means the job failed or never started, so investigate.
Related articles
- How to back up a Linux server with rsync
- How to automate backups with cron
- Backup retention policy explained
- How to test backup integrity
Need reliable space for your backups? Order a Storage VPS at Cloud2Y →
