Key takeaways
- A backup on the same server is not a backup: keep at least one copy somewhere else.
- Encrypt backups before they leave the server, and keep the passphrase away from both the server and the backup store.
- Immutable storage and a retention policy protect you from deletion, mistakes and ransomware.
- A backup you never restored is a guess, so schedule test restores and run one yourself.
Servers fail in dull ways: a disk, a provider account, a mistaken command. The only reply that always works is a copy of your data somewhere else, kept encrypted and proven by a restore. Here is what to set up.
Start with the 3-2-1 rule
The rule is commonly stated as three copies, on two kinds of storage, with one copy off site. For a hosting server that means the live data, a local backup for quick restores and an off site copy for the day the server is gone. The off site copy is the one that saves you from a lost machine or a provider problem.
Pick storage you already trust
RespireCloud connects to S3, Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, Azure Blob, Google Cloud Storage, SFTP, FTP(S) and WebDAV, tests each on save and rechecks it every 15 minutes. You can also run an S3 compatible store on a second server of your own. See storage and backups. Prices and limits are the provider's to state, so read their pages before you choose.
Encrypt, and guard the passphrase
Backups are encrypted restic repositories, so the storage provider sees only encrypted data. The key point is where the passphrase lives: not on the server and not in the same place as the backup. A backup that holds the key next to the data protects nothing. RespireCloud also writes a recovery bundle with the keys, encrypted with a passphrase you hold, and refuses to put it inside the repository.
Retention and immutability
Decide how many daily, weekly and monthly copies to keep. With S3 object lock, backups can be immutable for a set time, so an attacker or a mistake cannot delete them early. Databases are exported first, so a backup is never silently partial.
Test the restore
Restoring is the part that decides whether the plan was real. RespireCloud runs weekly integrity checks and monthly test restores on its own, and you can restore at several levels: files beside the originals, a database as a new one, a mailbox into a Restored folder or a whole account. In our recovery run, a blank node was rebuilt from a bundle in 312 seconds, with the items verified, on one Ubuntu 26.04 lab node and an S3 store. Other systems and real machines were not run. See whole server recovery for what does not come back, such as mail in the queue and container volumes, and note that point in time recovery is not built.
A short plan
Connect a store, set a schedule and retention, store the passphrase and bundle elsewhere, and do one restore this week. Then read the security checklist guide and our security posture. If you are moving from another panel, the cPanel guide covers backups on the way in, and the pricing page shows what each edition includes.
Questions
What is the 3-2-1 backup rule?
Commonly stated as three copies of your data, on two kinds of storage, with one copy off site. It is a good starting point, not a guarantee.
Is Backblaze B2 compatible with S3?
Backblaze B2 offers an S3 compatible interface, and RespireCloud also lists B2 as a connection type. Check the current details with the provider before you rely on a feature such as object lock.
How do I know my backups work?
Restore from them. Run test restores on a schedule, and restore a single file, a database and a mailbox yourself at least once.