ROBO Backup: Protecting Remote and Branch Offices

The real problem with ROBO backup 

Protecting one branch office is trivial. Protecting 500 is the actual problem. Most ROBO backup advice treats the first problem and ignores the second. The architectures that work at one branch break at 50, and the architectures that work at 50 require you to rebuild from scratch at 500. 

I have watched customers deploy backup appliances at every retail store for chains with hundreds of locations. Two years in, they have 400 backup boxes in the field, no consistent firmware version, no IT staff at the sites, and a quarterly travel budget for the one person who knows how to fix them. The backups technically run. The backups have never been tested at most locations. Nobody is confident a real recovery would work. 

This piece is about an approach that scales because it puts almost nothing at the branch. The branch keeps doing what branches do. The backup runs centrally. 

Why ROBO sites are harder than headquarters 

Headquarters has a data center, a fat pipe, and an IT team. ROBO sites have none of those, but the same business continuity requirements. Four specific challenges show up consistently. 

WAN bandwidth is the first one. A full backup over a typical branch link can blow the backup window and saturate the connection during business hours. Bandwidth adequate for daily operations is rarely adequate for nightly fulls. 

No local IT staff is the second. A retail store does not have a backup administrator. Whatever runs at the branch has to run autonomously, recover autonomously, and never require someone to drive out. 

Scale is the third. One branch is easy. 500, with identical policy and identical reporting, is the actual problem. 

And SLAs are the fourth. Customers and regulators do not care that your retail location has a 10Mbps link. If point-of-sale data is lost or systems are down, the business is down. ROBO backup has to deliver HQ-grade recovery without HQ-grade infrastructure. 

What downtime actually costs at branches 

Downtime cost varies, but the floor is high. Statista's research shows 24% of organizations report hourly downtime costs between $301,000 and $400,000 for critical servers, and 14% report costs greater than $5 million per hour. For retail or financial services with distributed point-of-sale or transaction systems, every branch hour offline multiplies the impact. 

The cost compounds at branches because failures are usually independent. A single branch outage does not trigger a corporate war room. It quietly bleeds revenue until someone notices. By the time central IT gets involved, the recovery clock has often been running for hours. 

Compliance regimes raise the floor further. GDPR requires careful management of customer data including timely deletion. HIPAA requires historical compliance proof for healthcare data. Branch-generated data is in scope for both, whether or not it has been backed up properly. 

What modern ROBO data protection actually needs 

Five requirements, and any architecture that misses one will hurt you within a year. 

WAN-efficient operation. Backup cannot saturate the branch connection during business hours. Full backups over the WAN are not acceptable. 

Zero local infrastructure. No dedicated backup server, appliance, or proprietary storage at the branch. The fewer moving parts at the site, the more reliable the system. 

Central management. Single pane of glass across every branch. Policy applied once, enforced everywhere. Reports rolled up to HQ. 

Recovery at both ends. Branch staff can recover deleted files without contacting central IT. Central IT can recover entire branches from HQ when needed. 

Granular and tenant-aware. Recovery at VM, application, or file level. Admin and tenant-level access so each branch manages its own data without seeing everyone else's. 

How 'backup from replica' actually works 

The architectural shift that makes modern ROBO backup practical is deceptively simple. Instead of running backup at every branch, replicate the branch data to the data center as part of normal DR operations, then perform the actual backup at the data center from the replica. 

What changes: the backup process consumes no compute, no storage, and no bandwidth at the branch. The branch ships changed data once, for replication. Backup happens at HQ on data that is already there. 

The flow is straightforward. Branch replicates to the data center continuously or on policy, using native replication. HYCU at the data center backs up from the replicated copy, not from the branch. Optional secondary backup copies are written to non-Nutanix storage at the data center for 3-2-1 compliance. Recovery runs at either end. 

For Nutanix-based ROBO specifically, this pairs with 1-or-2-node clusters that get provisioned at HQ in under an hour and shipped to the branch ready to run. Same Prism management plane. Same HYCU policies. No separate ROBO product. We also support ESXi ROBO sites, and recovery can move workloads between AHV and ESXi, or to Nutanix Clusters on AWS or GCP. 

Why replication alone is not disaster recovery 

Teams confuse these constantly. "We replicate from every branch to the data center, so we're covered." That is a serious mistake. 

Replication is a copy of current state. If the source becomes corrupted by ransomware, application bug, or an administrator's bad command, the corruption replicates too. The data center now has a perfect copy of the broken data with the original gone. Recovery has nowhere to go. 

Real ROBO data protection follows the 3-2-1 rule: at least three copies of data, on two different media types, with at least one copy off-site. Replication is one of the copies, not the whole strategy. Backup adds the point-in-time, recoverable copies that replication does not provide. Replication enables fast failover. Backup enables clean recovery. 

For ROBO this matters more than at HQ because branches often have a single replication target and no other protection layer. A ransomware attack on one branch can corrupt the replica before anyone at HQ notices. Backup from replica with retention solves this. The branch can be restored to a clean point-in-time even after the live replica is compromised. 

What ROBO recovery actually looks like 

Three scenarios cover most of what ROBO operations need. A single file or folder, when an employee deletes the wrong document. Branch staff perform self-service file-level recovery from the most recent backup. A single VM or application, when a point-of-sale VM fails or an application corrupts. One-click recovery restores the VM at the branch, or temporarily at HQ while branch hardware is replaced. Whole-branch failure, from fire, flood, ransomware, or hardware failure. The entire branch recovers to either a replacement site or to Nutanix Clusters on AWS or GCP for temporary operation. 

Across all three, recovery is admin or tenant-controlled. Branch staff recover what is in their scope. They do not have visibility into other branches. This matters in retail and franchise environments where multiple operators share infrastructure. 

Common questions on ROBO data protection 

Do I need backup infrastructure at every branch? 

No, and that is the point. With backup-from-replica, the branch replicates to the data center and the actual backup process runs centrally. No backup servers at the branch, no appliances, no proprietary storage. The branch ships changed data once for replication, and HQ does the rest. 

Is replication enough for ROBO disaster recovery? 

No. Replication copies current state, useful for failover but useless if the source is corrupted, because the corruption replicates too. ROBO needs both replication for fast failover and backup with retention for clean point-in-time recovery. The 3-2-1 rule applies to branches as much as to HQ. 

How does this handle whole-site loss? 

If a branch is unrecoverable on-site, from fire, flood, or prolonged hardware failure, workloads restore to Nutanix Clusters on AWS or GCP. Same policies, same recovery model. Operations continue from cloud-hosted infrastructure until the branch comes back online. Workloads move back later without changing settings. 

What about branches with bad connectivity? 

Replication is the only WAN-consuming activity. We have customers running on 5Mbps links. The replication is configured to fit available bandwidth, and the data center handles everything else. If the branch link is genuinely unusable, the architecture does not help, but neither does any other option short of mailing tapes. 

If you run more than 10 branches, this is worth a conversation 

Most ROBO architectures we replace are running between 20 and 500 branches with backup appliances at every site. The math of replacing those with backup-from-replica usually pays for itself in the first year through hardware refresh avoidance alone. The operational improvement is usually bigger than the cost savings, but harder to quantify in advance. Talk to your account team if this sounds like your environment.