Branch office backups raise a placement question that a single-site organization never has to answer. Each branch has a few servers, some local file shares and perhaps a line-of-business database. The data is small compared with headquarters, but there are many branches, no IT staff on site and a network link that was sized for daily work. The choice is whether backups stay in the branch, go to a central site, or both.
This post compares central and local copies for branch offices and describes the combinations that tend to work for small IT teams.
Three constraints shape branch backup design. Bandwidth is limited and shared with users, so large transfers have to fit into the night or be throttled. Nobody on site can swap a disk, restart a device or notice a warning light. And physical security is weaker than in a data center: a backup device in a cupboard can be stolen, unplugged or damaged along with the servers it protects.
| Consideration | Local copy in the branch | Central copy at a main site |
|---|---|---|
| Restore speed for local servers | Fast, over the local network | Limited by the branch link |
| Protection from a branch incident | Shares fire, theft and power risks with the servers | Unaffected by what happens in the branch |
| Hardware to maintain | One device per branch | One repository for all branches |
| Dependence on the link | None for backup or restore | Backups and restores both need it |
| Immutability | Depends on the device in each branch | Enforced once, at the central repository |
| Visibility for the IT team | Many devices to monitor | One place to check |
A local copy exists for restore speed. If a branch file server fails on a Monday morning, restoring a few hundred gigabytes from a device in the same room takes an hour or two. Pulling the same data over a modest link can take a day or more. For branches that cannot work without their local systems, that difference justifies some hardware on site.
The local copy should be treated as a convenience, though. It sits in the same building as the systems it protects and is usually administered with the same credentials. It should hold a short retention, a week or two, and never be the only copy.
A central copy is what survives when the branch does not. Flood, theft, a ransomware incident that reaches every device on the branch network or a simple hardware failure with no local spare all leave the central copy untouched. It is also where long retention and immutability belong, because one well-run repository is easier to secure than twenty small ones. Backup storage consolidation covers the benefits and the concentration risk of bringing targets together.
The cost is dependence on the link. After the first full backup, daily incrementals are usually small enough to send overnight. The first full and any large restore are the transfers that need planning.
Most organizations settle on one of three arrangements. Small branches with little local data back up directly to the central repository and accept slower restores. Branches with important local systems keep a short local copy and send a second copy to the center. Branches whose workloads have moved to central or cloud-hosted applications need little more than endpoint protection, since there is no server left to restore.
The choice can differ by branch. Sorting branches by how long each could operate without its local systems, and by how much data it holds, usually produces two or three groups that each get one standard design.
The daily incremental has to finish inside the transfer window with room to spare. A branch that changes 20 GB a day needs roughly 5 Mbps sustained over ten hours once protocol overhead is counted. The first full backup is a separate problem. Options include throttled transfer over several nights or weekends, seeding the copy from a device brought to the main site, or temporarily raising the link capacity. Backup copy job lag explains how to tell when the link has stopped keeping up.
A central copy also changes how a branch can be recovered. If the building is unusable, servers can be restored at the main site or onto replacement hardware shipped to a temporary location, without retrieving anything from the branch. That plan should be written down and tested for one representative branch, including how users will reach the restored systems. Recovery runbooks for on-call staff describes what such a procedure needs to contain.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. In a branch design it is typically the central repository: an S3 endpoint that backup jobs or copy jobs from every branch write to, with separate buckets per branch if required. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB, so branches can be added without a new repository each time. It is used as a target for Veeam and other backup software.
The designs that last are the ones with the fewest variations. Two standard branch types, one central repository, one monitoring view and one restore procedure per type is a workload a small team can sustain. Every exception added for a single branch is another thing to remember at three in the morning.