Continuity / Backup

Your backups are in the same building as what they back up.

The backup runs every night and finishes fine. The problem isn't the backup, it's where it lives. A fire, a flood or ransomware spreading across the network reaches the production server and its copy on the same day, because they hang off the same switch.

Backup or recovery

You are here

Cloud backup

Gives you your data back.

The copy leaves the site without changing how you operate.

Disaster recovery

Gives you your operation back, running.

Compute to bring it up on, a network to connect it and names that resolve.

See details

Having the first without the second means you have your files and nowhere to bring them up.

What goes down when the copy is on the same site

Ransomware. The process that encrypts your files also encrypts the backup repositories mounted on the network. The copy disappears along with the original.
Physical disaster. Whatever happens to the site happens to both at the same time.
Retention. Keeping years of history on local disk is expensive, so retention gets cut. The day you need a version from several months ago, it no longer exists.
Restores never tested. A backup nobody has restored isn't a backup; it's an assumption.

Types of copy

What survives what

Type of copy	A failed machine	Losing the site	Ransomware	Deletion from a privileged account
Replica at another site	Survives	Survives	Doesn't survive	Doesn't survive
Local copy on the network	Survives	Doesn't survive	Doesn't survive	Doesn't survive
Copy in the cloud	Survives	Survives	Depends	Doesn't survive
Immutable copy in the cloud	Survives	Survives	Survives	Survives

The reference practice is the 3-2-1-1-0 rule: three copies, on two different media, one off site, one immutable and zero errors on restore. The last one can only be known by restoring.

How it works

The copy leaves the site without changing how you operate. Your backup software stays the same and your jobs keep running as they do. What changes is the destination: an intermediate component presents itself to your software as the storage it already knows how to use, and writes to the cloud behind the scenes.
Long retention at archive cost. Object storage has tiers designed for data that is almost never read, so keeping history stops being a budget decision and becomes a business decision again.
Immutability. The copy can be retained with a lock that prevents it from being deleted or overwritten for the period you define, even from a privileged account. It's the difference between a backup that survives ransomware and one that goes down with it.

What's in scope

Included. Integration with the backup software you already use, a secondary copy in the cloud with immutable retention, encryption in transit and at rest, and the first restore test, done with your team.
What we need from you. Your current backup policies and data volumes, a named owner for the backup platform and the network path from your site to the cloud.

How we work

We understand how you back up today
Which software you run, what goes into the jobs, how often they run and how much history you need to keep. The design comes from there, not from a catalog.
We size the path to the cloud
How much data changes between backups and how much link you have determine the size of the intermediate buffer and the local cache. Poor sizing at this point is the most common reason jobs stop finishing within their window.
We integrate and test by writing
The cloud destination is connected to your backup software and real jobs are run, not a connectivity test.
We test by restoring
The test that matters isn't that the backup goes up; it's that it comes back down. We restore against the environment to see the real behavior and measure the real time.

Why what happens next matters

A healthy backup gets sick quietly. A server gets added that nobody included in the jobs. A window starts not closing. Retention fills up.

None of that raises an alert the day it happens, only the day you need to restore. That's why backup verification is an ongoing function, done by restoring, not by reading a green check in a console. It's something our team can take on.

Questions

Do I have to change my backup software?

That isn't the starting point. The usual path is to keep what you already run and change the destination. If what you have today doesn't allow it, you'll know from the initial review.

Is cloud backup the same as a disaster recovery plan?

No. Backup gives you your data back. A recovery plan gives you your operation back, running. Having the first without the second means you have your files and nowhere to bring them up.

How fast can I recover from the cloud?

It depends on the volume, the storage tier the copy lives in and your link. It's one of the first things we calculate, because it decides whether cloud backup is your recovery mechanism or your last line of defense behind another one.

How often should restores be tested?

At least every quarter, and after any change to what gets backed up. A restore is the only proof that a backup works. A green check in a console only proves that a job finished.