In Core Strategies for Data Resilience: A Practical Guide, we covered how to set recovery targets for mission-critical workloads. This article picks up where that guide left off, with the next question: what recovery architecture should you plan for, and how much secondary infrastructure, if any, should you maintain?
Should the DR site run a second server holding a full copy of the data, or will a lighter standby do? Some organizations keep no standby at all and provision a new server only after a failure. Whichever path you take, the decision must be made before the primary server or site becomes unavailable.
Below, we compare these approaches from an infrastructure perspective and show how Tiger Bridge supports the approach we recommend.
From recovery targets to recovery architecture
Not every workload needs the same recovery target. For active project files that people edit all day, losing much data may be unacceptable. An archive of projects closed five years ago can tolerate a longer recovery time. The first guide covers how to set those targets, including when continuous protection takes precedence over scheduled backup.
What the guide leaves open is what recovery environment to maintain before a failure, or whether to maintain one at all. Even with a target in hand, someone still has to decide how much of that environment should be ready on an ordinary day, when nothing has gone wrong. Anything set up in advance cuts the work left to do during an outage. It also has to be paid for and maintained for years, whether or not a disaster ever comes. The three approaches below handle that trade-off differently.
Three DR infrastructure approaches: full mirror, metadata standby, or no standby
None of these approaches is right for every workload. The RPO and RTO a workload needs, along with the level of risk the business is willing to accept, will rule out some options. Whatever remains is then weighed against the amount of secondary infrastructure each option requires.
Full active-passive mirror. In this setup, the DR site runs a second server holding a complete copy of the data, kept up to date through full synchronization. If the primary fails, the file data is already local on the secondary, so recovery does not depend on retrieving file content from the protected target on demand. The downside is storage. A 100 TB production server needs roughly another 100 TB at the DR site, and that capacity must be bought and maintained alongside production as long as the setup is in place. This makes it the most expensive of the three approaches.
Smaller metadata/stub-based standby. This standby server is much lighter. Instead of a full copy, it holds metadata/stub files. These are small placeholders that look like real files but point to the protected data on the target, which can be public cloud or on-premises object storage. Because folders and file names are already in place, users don't have to wait for a full data restoration before starting work. When they open a file, its content is retrieved from the target on demand. This gets people back to work sooner than having no standby, while the server needs far less storage than a full mirror.
No standby. At the other end, no server waits at the DR site. After a failure, an administrator provisions a new physical or virtual server, connects it to the existing protected target, and imports or restores metadata and data as needed. Because the recovery environment itself has to be provisioned after the failure, this approach has the longest downtime. In return, it is the most cost-effective option. It fits workloads where the business can tolerate a longer recovery time and does not want to maintain standby infrastructure year-round.
Here's how the three compare:
| Approach | Secondary environment | In place before failure | Infrastructure burden | Recovery trade-off |
|---|---|---|---|---|
| Full active-passive mirror | Second server with full local storage | A complete, synchronized copy of the data | Highest | Data already local; highest cost |
| Metadata/stub-based standby | Smaller server | The file structure, as metadata/stub files | Moderate | Content retrieved on demand |
| No standby | None until after a failure | Nothing at the DR site; the protected copy sits on the target | Lowest | Longest downtime |
The case for a smaller standby server
We recommend this approach as a middle ground: it keeps a recovery environment ready without maintaining a second full production-scale local storage mirror. In a hybrid setup, a protected copy already sits on the target. A full mirror adds another complete copy on local storage at the DR site, which grows every time production does. The metadata/stub-based standby skips that extra copy and relies on the existing protected data instead.
The trade-off is potentially slower access during DR. Because file content is retrieved on demand, users depend on the network connection between the standby and the target and on how quickly the target storage tier returns data. Frequently accessed cloud tiers respond faster than archive tiers, which can take considerably longer to return content.
Both factors can be planned for. Where the target provides multiple storage tiers, that means placing the files people are most likely to need during an outage in a tier that returns data quickly. A firm might keep the shares its teams work in every day in a frequently accessed tier, for example, and leave files that are rarely opened in archive storage, where slower retrieval matters less. It also means checking that the DR site's connection to the target can handle the load once users start opening files. With that groundwork in place, here is how Tiger Bridge handles replication and recovery.
How Tiger Bridge supports this setup
Tiger Bridge runs on your existing file servers. It continuously replicates new and changed file data to the protected target according to the configured replication policy. This can support near-zero RPO in the recommended architecture, limiting potential data loss to changes that have not yet been successfully replicated.
Here is what recovery looks like, starting with the part that happens before anything goes wrong:
- Before any failure, the standby automatically syncs the metadata/stub files for everything the primary replicates to the target, which keeps its file structure current.
- The primary fails. An administrator points client machines to the standby server.
- People open their files the way they normally would, and Tiger Bridge fetches each file's content from the target storage as it is opened.
- New files and edits made during the outage are replicated to the target as well.
- Once the primary server is repaired, or a new server takes its place, it syncs the new and modified items placed on the target during DR.
- The administrator points clients back to the primary server.
Client redirection is an administrator action at both failover and failback. At failback, timing matters: work done during the outage lands on the target, so the returning primary needs to finish syncing those changes before the administrator moves anyone back.
Replicated files remain in native, non-proprietary format on the target storage and can be accessed without a proprietary restore process. Setting this up doesn't require a wholesale rip-and-replace project. Tiger Bridge is added to the existing servers and storage, and in normal operation, people continue working in their usual shares. At the DR site, IT does not have to maintain a second full production-scale storage estate.
Continuous data protection beyond a site outage
DR planning tends to focus on the day a server or whole site goes dark. File data can also be damaged while servers are running. A folder may be deleted by accident, or a file can be corrupted without anyone noticing for a while. In a ransomware attack, the server stays up while malware works through one share after another. Without additional safeguards, replication can also pass unwanted changes, including corruption or encryption, on to the target. Tiger Bridge pairs replication with the safeguards below.
1. Versioning and soft delete
With versioning enabled in Tiger Bridge on a supported target storage, replicated file versions are retained, and modified files can be restored to an earlier point in time. Deleted files or folders can be recovered for a given period of time when soft delete is enabled.
Tiger Bridge can also serve as a backup for the files it manages, if replication and versioning are both configured. Teams that already use Veeam for backing up virtual machines can keep using it. Tiger Bridge will replicate the Veeam backup files to the target, and after that it will upload only the changes Veeam makes to them.
2. Ransomware protection
Encrypted files reach Tiger Bridge as ordinary file changes, which makes ransomware a harder case. The policies and settings below can be used on their own or together.
One option is to wait. With a longer replication policy, Tiger Bridge waits for a set time after a file changes before replicating it. Changes remain queued during that delay, which creates a window to detect an attack before those changes are replicated. The trade-off is a longer protection-point delay, so this approach suits data that can tolerate it and is not appropriate where near-zero RPO is required.
The ransomware protection mechanism monitors the queue of modified files awaiting replication. When ransomware modifies many files, that queue can grow quickly. The fuse-like defense mechanism pauses further replication when the number of modified files reaches the configured threshold. After the attack, a command in the Tiger Bridge context menu reverts the file to its last replicated state. In addition, versioning provides a recovery path to known-good earlier versions, in case an encrypted or corrupted version has already reached the target.
3. Immutability
Tiger Bridge Compliance provides source-side retention enforcement for a defined period. To protect the replicated copy as well, the target needs matching retention/immutability controls, such as Object Lock where supported.
A Middle East construction firm featured in our Resource Center demonstrates the results of a completed deployment: Tiger Bridge CDP protected the entire dataset with versioning and undelete, while archiving and backup were fully automated across seven global offices. The cloud-based architecture simplified disaster recovery, and local storage needs fell by 95%.
Match the DR architecture to the recovery targets
Each approach in this article suits a different set of recovery targets. Once the targets for each workload are settled, comparing the three means weighing cost against downtime. For many workloads, a metadata/stub-based standby may be enough.
To see how this setup would work with your own servers and storage, book a demo with our team. You can also use our Cost Savings Calculator to estimate what you could save on storage.