Two-site backup operations double the number of things a small IT team has to keep healthy. A second site adds a second repository, a link between the two, copy jobs with their own schedules and a recovery procedure that is rarely exercised. The design may be simple. Keeping it working with two or three people, who also run everything else, depends on routine more than on architecture.
This post is about the recurring work of a two-site backup setup: what to check, how often, and how to keep the second site from drifting.
What a second site adds to the workload
With one site, the daily question is whether last night's backups succeeded. With two, there are further questions. Did the copies reach the second site? Is the second repository healthy and within capacity? Are its software and firmware current? Do its immutability settings still match the first site's? And could the team still recover from it if the first site were gone? Each has a different natural frequency, and none takes long if it is done regularly.
A routine that fits a small team
| Frequency | Check | Time needed |
|---|---|---|
| Daily | Backup job results at the first site, age of the newest restore point at the second | A few minutes |
| Weekly | Capacity and health of both repositories, link utilization during the copy window | Fifteen minutes |
| Monthly | Updates applied at both sites, immutability settings compared, alerts reviewed | One to two hours |
| Quarterly | Restore of one system from the second site only | Half a day |
| Yearly | Full exercise with the first site treated as lost, capacity and link re-sized | One to two days |
One number for the second site
If a small team tracks only one figure for the second site, it should be the age of the newest restore point held there. A copy job can report success while skipping machines, and a repository can be healthy while holding week-old data. The age of the newest restore point captures the outcome that matters. An alert when it exceeds the agreed limit, sent to more than one person, replaces a great deal of manual checking. Backup copy job lag explains how to set that limit.
Monitoring without a second console
A second site is easy to forget because nobody logs in to it. Its alerts should arrive in the same place as the first site's: the same mailbox, ticket queue or monitoring tool. Hardware faults, capacity thresholds and failed logins at the second repository deserve the same attention as those at the first. Monitoring backup storage lists the signals worth forwarding and the ones that only add noise.
Keeping the two sites in step
Drift is the main operational risk. The first site gets patched because people work with it every day, and the second falls a version behind. A retention change is made on the primary job and not on the copy. A new workload is added to backup and never added to the copy scope. A short monthly comparison catches all three: software versions, retention and immutability settings, and the list of protected systems at each site, side by side.
Updates at the second site should follow the first by a few days, not months. That keeps the two compatible while leaving a short interval to notice a problem with a new version before it is on both.
Covering for absence
In a team of two or three, one person is often the only one who has ever restored from the second site. Holidays and illness then become a recovery risk. The remedy is a written procedure that a colleague has followed at least once, credentials held where a second person can reach them under control, and the quarterly restore rotated between team members. Recovery runbooks for on-call staff describes what the document should contain.
When the second site is a second room
Many mid-sized organizations have no second data center. The second copy sits in another room, another building on the same campus or a colocation rack across town. The routine above applies unchanged. What differs is the range of events the second copy survives. A separate room protects against hardware failure, a localized fire and most ransomware scenarios, provided the repository is independently administered and immutable. It does not protect against the loss of the whole building, so a small third copy further away is worth considering for the systems that matter most.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. In a two-site setup it can be the repository at one or both sites, reached by the backup software through an 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.
ARTESCA can span several servers, so one can be taken out for maintenance without interrupting the repository, which simplifies monthly patching at a site nobody visits. It 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.
Small and regular beats thorough and rare
A two-site setup fails through neglect far more often than through bad design. Five minutes a day, fifteen a week and a restore every quarter keep the second site a working part of the backup system. Skipped for six months, the same site becomes an assumption nobody has verified.