Cross-site backup copies are only as current as the network link between the sites allows. A second copy in another room, building or city is a sound design on paper. Whether it holds last night's restore points or last week's depends on how much data changes each day, how long the copy is allowed to run and how much bandwidth it is given. When the link is undersized, the copy falls behind quietly, and the gap is discovered during the incident the second site was built for.
This post walks through how to size a link for backup copies and what to do when the arithmetic does not work out.
A backup copy job transfers the restore points created since its last run. On most days that is an incremental: the blocks that changed in the protected systems, after compression and any deduplication the backup software applies. Periodically it is larger. New virtual machines arrive with a full backup, active fulls are taken on a schedule, and maintenance operations can rewrite data that then has to be sent again.
| Input | How to obtain it | Why it matters |
|---|---|---|
| Daily changed data after reduction | Backup job statistics over at least a month | Sets the routine transfer volume |
| Peak day | Largest incremental in the same period | Month-end and patch days can be several times the average |
| Copy window | Hours the copy may run each day | Shorter windows need more bandwidth |
| Share of the link available | Network team, quality-of-service policy | Backup rarely gets the whole circuit |
| Size of the first full | Repository usage for the jobs in scope | Determines how the copy is seeded |
| Acceptable lag | Recovery point objective for the second site | Defines what falling behind means |
The calculation is short. Divide the data to send by the seconds available and convert to bits. As a reference point, a sustained 100 Mbps moves about 45 GB per hour, or a little over 1 TB per day if it runs around the clock. A site that changes 300 GB a day and allows an eight-hour window needs roughly 85 Mbps of usable throughput, before any margin.
Usable throughput is lower than the nominal figure. Protocol overhead, encryption, latency on long routes and other traffic all take a share. Planning on 60 to 70 percent of the circuit's rated speed gives a figure that tends to hold in practice.
A link sized for the average day falls behind on every busy one. If the peak incremental is three times the average and peaks arrive weekly, the copy needs enough spare capacity on ordinary days to catch up before the next peak. A practical rule is that the link should clear the average day in half the window. That leaves room for peaks, retries and growth.
The measure to watch in operation is the age of the newest restore point at the second site. Backup copy job lag covers how to track it and where to set the alert.
The initial full is often tens of times larger than a daily incremental. Sending it over the production link can take weeks. Three approaches are common. The copy can run throttled in the background until it completes, accepting that the second site is not yet protected. The second site's storage can be placed next to the first for the initial copy and then moved. Or the first full can be carried on portable storage. Whichever is used, the seeding period should appear in the project plan as time during which the second copy does not yet exist.
Sizing usually considers only the outbound copy. A restore from the second site travels the other way, and it is a full, not an incremental. If the primary repository is lost and 20 TB has to come back over a 200 Mbps link, the transfer alone takes around ten days. Many designs avoid this by planning to recover at the second site instead of copying data back. Estimating a full-site restore applies the same reasoning to restores from a remote copy.
If the numbers do not fit, there are four levers. The copy window can be widened, including daytime hours with a lower throttle. The scope can be narrowed so that only the workloads that justify a second site are copied. The interval can be lengthened where a larger gap is acceptable. Or the link can be upgraded, which is often cheaper than it was when the circuit was first ordered. Reducing what is sent through better compression or by excluding swap and temporary data is also worth checking. Backup compression by workload shows where reduction is realistic.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It can be the repository at the second site that copy jobs write to over the link, through its S3 endpoint. 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, so the remote copy is protected even if the primary site's backup server is compromised.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
Daily change grows with the data it comes from. A link that had comfortable headroom when the second site was built can be at its limit two years later with no single event to mark the change. Repeating the calculation annually, using a fresh month of job statistics, keeps the second copy as current as the design intended.