Mirroring and replication can shorten an outage, but a second live copy may also receive the change that caused the problem. Design recovery around specific failures, retained recovery points and a rehearsal that proves the application can work again.
Name the job of each copy
A local mirror maintains redundant data across devices within a system. Remote replication maintains another copy elsewhere. A snapshot captures a point-in-time view within the capabilities of its storage system. A backup preserves recoverable data under a separate retention and recovery process. Their protection depends on location, access controls and what failures they share.
Microsoft's redundancy, replication and backup overview explains the distinction between maintaining replicas and retaining recovery copies. A snapshot stored only on the failed array cannot help if the array and its snapshots are unavailable. A backup that an attacker can delete with the same compromised credentials has another shared failure risk.
On narrow screens, focus the table and use the arrow keys or swipe to see every column.
| Scenario | Potentially useful protection | What to prove |
|---|---|---|
| One storage device fails | A healthy supported local mirror | Monitoring detects the fault and the documented replacement process works |
| A folder is accidentally deleted | A retained snapshot or backup from before deletion | The selected point contains the needed files and permissions |
| A site becomes unavailable | A separate-site replica or backup plus replacement services | Network, identity, application and recovery staff can operate there |
| Malicious changes reach live copies | Protected recovery points beyond the affected access path | A suitable clean point can be identified and restored in isolation |
Understand acknowledgment and consistency
Synchronous and asynchronous replication differ in when the source can acknowledge writes relative to the destination. In Microsoft's Storage Replica implementation, synchronous operation waits for remote log commitment, while asynchronous operation permits replication lag. Its documented guarantees are specific to that implementation and its supported configuration.
Waiting for the remote side can affect write latency and makes network behavior part of the storage design. Asynchronous operation can leave recent writes missing after a source failure. Measure lag during the actual workload rather than assuming it always stays small.
Storage consistency also differs from application readiness. A database may require its documented recovery procedure even when a volume is available. Coordinate snapshots or backups with application requirements, and include configuration, keys, dependencies and licenses in the recovery inventory.
Set two measurable recovery goals
The recovery point objective (RPO) describes the acceptable age or amount of lost work. The recovery time objective (RTO) describes the acceptable time to restore the defined service. Write down what “working” means: opening a share is a weaker test than successfully completing an application transaction.
Rehearsal example: the simulated outage starts at 14:17. The latest usable recovered transaction is from 14:10, and users can complete the agreed test at 14:42. The observed data gap is seven minutes and service recovery takes 25 minutes. Against a five-minute RPO and a 30-minute RTO, the exercise misses the data objective but meets the time objective. The timestamps are fictional; the comparison is the point.
A replica status marked healthy does not answer either question by itself. Record actual recoverable data and the time the service passes its acceptance test.
Rehearse without endangering production
- Choose a scenario and a small representative dataset. Agree on owners, objectives, success checks and a stopping point.
- Use an isolated recovery environment or a documented non-disruptive product test. Prevent a recovered clone from taking over production names, addresses or scheduled jobs.
- Select a known recovery point and restore the required application components. Keep the source and independent backups protected.
- Verify files, permissions and a meaningful application operation. Record data timestamps, elapsed time and missing dependencies.
- Remove test resources through the approved process, confirm production monitoring is normal, and assign fixes for every failed check.
Use the recovery rehearsal worksheet to record the scenario and evidence. A planned production failover needs its own product-specific procedure, coordination and rollback plan.
Keep recovery independent and current
Repeat the exercise after changing the application, storage layout, identity system or backup policy. Include a person other than the original installer. Keep recovery documentation accessible when the primary system is unavailable, and store secrets through an approved separate process.
For local device redundancy, see the RAID guide. For shared storage setup and access, see the NAS guide. Neither replaces a demonstrated recovery workflow for the service people rely on.