Using Backup Storage as a disaster-recovery target

What it is

Backup Storage is a remote, cloud-based target for backup data, sized around capacity rather than everyday speed. It isn't built to act as a file server or database storage, it's structured for archives: data you access infrequently but need to keep permanently and securely available.

What's included

• A remote target you point your own backup software at, rather than a replacement for your backup tooling itself.
• Retention policies and version control, so older backup versions stay available for as long as your policy requires.
• Capacity that scales, sized to how much backup data you're storing.

Backup Storage vs. the VPS Backups feature

These two share a name and cause real confusion, so it's worth being precise about which one you're looking at:

If you're already using the Backups feature inside Flexible VPS and want to know how that one works day to day, including retention schedules and the Restore/New VPS options, see Backups and snapshots: what's the difference. Come back to this article when you need a backup target that isn't tied to a single VPS.

When to use it

• You need a disaster-recovery target that lives outside the environment it's protecting.
• You need a remote backup target that isn't tied to a single Worldstream VPS.
• You need long-term retention and versioning for backup data.

Retention, capacity and pricing: For the current retention periods, capacity options and pricing for Backup Storage, open a support ticket in Portal or use one of the contact routes on the Worldstream support page.

RAID, replication and backup are not the same thing

These three get confused constantly, and the confusion matters because each one protects against a different failure. Mixing them up is how people discover, at the worst possible moment, that they weren't actually backed up.

• RAID is not a backup. RAID protects against a drive failure: lose a disk, and the array keeps running. It does nothing for accidental deletion, corruption, or ransomware. Delete a file on a RAID array and it's gone from every disk in the array at once.
• Replication is not a backup either. Replication keeps a second copy in sync with the first, which is good for availability but not for protection. If the primary copy gets corrupted or encrypted by ransomware, replication copies that corruption or encryption across just as fast as it copies anything else.
• A backup is a separate, independent copy, ideally on separate credentials and separate media from the system it protects. That independence is what RAID and replication don't give you.

In short: RAID keeps a single system running through a hardware fault, replication keeps two systems in sync, and only a real backup gives you a copy you can fall back on when the original is deleted, corrupted, or encrypted.

Why immutability matters against ransomware

Immutable (WORM, write once read many) backups can't be altered or deleted for a set retention period, even by someone with full administrative access to the system being backed up. That's precisely the scenario ransomware depends on: an attacker who has taken over your environment and tries to reach the backups too, to remove your way out. With immutability in place, the backup copies stay intact regardless. Immutability depends on how the target and your backup software are configured, so check what yours support before you rely on it as part of a ransomware recovery plan.

Test your restores: A backup you have never restored from is not a verified backup, it's an assumption. Build restore testing into a regular routine rather than waiting for an actual incident to find out whether it works. It's also worth checking that your backup storage has headroom for growth, not just for what you're using today, so sizing doesn't become the reason a restore falls short.