Choose the protection model for the recovery outcome you require
Native eEKAS site replication, scheduled mirroring and checkpoint-based S3 backup solve different problems. Select the model by availability, history and recovery requirements—not by the word “replication” alone.
Three transfer models, three operational outcomes
The right choice depends on whether the business needs a standby service, a current secondary copy or independent historical recovery points.
eEKAS to eEKAS sync
Continuous asynchronous replication between independent eEKAS installations. Use read-only disaster-recovery mode for a controlled standby site, or active-active where applications can tolerate asynchronous visibility.
External S3 mirror
Copy current objects one way to another S3-compatible service manually, hourly or daily. The destination does not need to be eEKAS.
S3 backup and archive
Export object generations, inventories and protection information to an external S3 archive. Completed checkpoints remain available when source objects are later changed or deleted.
Match the protection model to the event
| Question | eEKAS site replication | External S3 mirror | Backup and archive |
|---|---|---|---|
| Primary purpose | Maintain another operational S3 site | Maintain a scheduled current copy | Preserve recovery checkpoints and generations |
| Destination | Independent eEKAS installation | S3-compatible service | External S3-compatible archive |
| Write modes | Read-only DR destination or asynchronous active-active | One-way only | One-way protected export |
| Source deletions | Follow replication rules | Normally mirrored; policy can alter deletion handling | Do not remove completed archived generations |
| Historical checkpoints | Not by replication alone | No | Yes |
| Choose when | Service continuity at another eEKAS site matters | A current secondary copy is sufficient | Independent point-in-time recovery is required |
Disaster recovery or carefully designed active-active operation
Native eEKAS replication follows S3 changes rather than relying on a periodic full scan. Initial synchronisation, backfill and catch-up after an interruption still require time, bandwidth and capacity.
Read-only disaster-recovery site
The source accepts normal writes while the destination remains read-only. Promotion is an administrator-controlled recovery action that also requires application routing, DNS or load-balancer planning.
Active-active sites
Both sites may accept writes, but visibility is asynchronous. Applications should avoid competing changes to the same object key or be designed to handle them. This is not distributed file locking or transactional multi-site consistency.
Restore from completed, identifiable checkpoints
Backup and archive separates recovery history from the live namespace and provides an explicit preview-and-restore process.
Configure, monitor and recover without command-line prerequisites
eEKAS exposes the protection choices and recovery workflow in its administrative interface while keeping the underlying architectural differences visible.
Protect more than object bytes
Service routing
Document DNS, load-balancer and application endpoint changes for site recovery.
Credentials
Protect invitations, archive credentials and recovery bundles separately.
SMB gateways
Replication transfers S3 objects, not SMB share definitions, identities or distributed locks.
Recovery drills
Test the complete business path, including access, permissions and return to service.
Design protection around the recovery commitment
Compare site continuity, independent history, bandwidth, object growth and operational recovery before selecting a model.