Skip to main content

Recovery Points and Replication

Recovery Point Management​

Check Recovery Point Health Regularly​

Make it a weekly habit to check that recent recovery points are in SUCCESSFUL status. A run of consecutive SHIPPING FAILED points indicates a replication problem that needs attention before you need to rely on them.

Watch for:

  • Recovery points stuck in SHIPPING for more than 20 minutes
  • Multiple consecutive SHIPPING FAILED statuses
  • Large gaps in the timeline where no successful recovery point exists

Create Manual Recovery Points at Key Moments​

The scheduled RPO creates recovery points automatically, but the timing may not align with your operational events. Create a manual recovery point before:

  • Any deployment to production (code releases, database schema changes)
  • Infrastructure changes (adding volumes, resizing VMs)
  • Scheduled maintenance windows
  • Quarter-end or significant business milestones

Wait for the manual recovery point to show SUCCESSFUL status before proceeding with the risky change.

Do Not Hoard Recovery Points Beyond Your Needs​

More recovery points stored = higher costs. Let the automatic retention cleanup do its job. The correct response to wanting "more history" is to increase the retention period, not to create excessive manual recovery points.

Know Which Recovery Points to Use in Each Scenario​

ScenarioWhich Recovery Point to Choose
Full region outage — need fastest recoveryMost recent SUCCESSFUL recovery point
Ransomware detected — need clean stateOldest SUCCESSFUL recovery point before infection was introduced
Bad deployment — application brokenThe manual recovery point created before the deployment
Data corruption noticed days laterThe most recent SUCCESSFUL recovery point from before the corruption window

Monitor Plan Status Proactively​

Do not wait for an email alert. Build a habit of periodically reviewing your DR plans:

  • Weekly: Check that each plan is in Active status and recent recovery points are SUCCESSFUL
  • Monthly: Review recovery point counts — are you getting the expected number per RPO interval?
  • Quarterly: Run a DR drill

Handle SHIPPING FAILED Gracefully​

A single SHIPPING FAILED recovery point is not an emergency — DRaaS will retry automatically. However:

  • Two or more consecutive failures: Investigate. Check if the source VM's disk is healthy and that the VM is still running.
  • Persistent failures spanning multiple RPO cycles: Contact E2E Networks support. Do not wait until you need to fail over.
  • Failure during a high-risk period (e.g., after a major deployment): Create a manual recovery point once the failure clears to establish a clean known-good point.

Know When to Pause Replication vs. When to Keep It Running​

Use the Stop action only when your source VM needs temporary maintenance that would interfere with replication (e.g., the VM will be powered off for an extended period).

Do not leave plans in a Stopped state indefinitely. A stopped plan creates no new recovery points. If a disaster occurs while the plan is stopped, your most recent recovery point may be days or weeks old.

If you are performing maintenance that keeps the source VM running, do not stop the DR plan. Allow replication to continue.

Common Mistakes to Avoid​

Mistake 1: Ignoring SHIPPING FAILED Alerts​

A shipping failure email is easy to dismiss as a transient glitch. Persistent failures mean your recovery points are not advancing — in a real disaster, you may be forced to restore from a much older point than expected.

Best practice: Treat consecutive SHIPPING FAILED events as an incident. Investigate within one business day. Contact E2E support if failures persist beyond two consecutive RPO cycles.

Mistake 2: Attempting Recovery While Data is Being Shipped​

DRaaS blocks a recovery attempt when data is actively being shipped. Attempting it under time pressure and receiving an error can cause confusion during an incident.

Best practice: Before initiating a recovery, check whether any recovery point is in SHIPPING status. If so, wait for it to complete (typically a few minutes) before proceeding.

Mistake 3: Leaving Plans in Stopped State​

Teams sometimes stop a DR plan during maintenance and forget to resume it. The plan silently collects no new recovery points. Weeks later, the most recent available recovery point may be unacceptably old.

Best practice: Set a calendar reminder whenever you stop a plan. Resume it immediately after maintenance is complete. Aim for plans to be in Stopped state for no more than the duration of a single maintenance window.