The add-on that answers what happens next.
DR Management defines, documents, maintains, and operates the recovery capability for the servers or clusters listed under one proactive scope. It answers four questions: what is protected, how quickly it can be recovered, where it recovers to, and who performs each step.
That means a written runbook, recovery targets agreed per environment, regular proof that the backups restore, oversight of whichever replication we manage, and a periodic report on where you actually stand.
It is the preparation, the documentation, the validation, and the testing. Engineering work during a declared disaster is billed as the reactive work it is, rather than pretending a recovery fits a monthly line item.
Keeps the covered servers or clusters healthy and taking backups: patching, monitoring, and the backup jobs themselves. DR Management attaches to exactly one of these scopes and covers only what that scope lists.
Read about ProactiveTurns those backups into a recovery someone can follow: runbook, agreed targets, validation, failover and failback steps, and a readiness report. Server builds cover backup servers and replication. Cluster builds cover the configuration backup platform and replicas.
Why teams add DR Management
A recovery you can hand to someone else
- The sequence, dependencies, and owners are written down, not in one engineer's head
- Reviewed at least annually and after any material change
- Failover and failback have named decision points, not a late-night guess
Proof the backups actually restore
- Periodic verification that backups complete, restore, and meet retention
- Failures get escalated outside the reporting cycle, not buried in a monthly PDF
- You know how long a restore takes because someone has done one
Numbers everyone is working to
- RTO and RPO agreed per covered environment and written down
- Stated as objectives, not guarantees, with no service credits for missing them
- An auditor, insurer, or board can be shown the same document you operate from
A standing read on readiness
- Periodic written report on validation, replication health, gaps, and what to do next
- Where we manage the pipeline, we watch replication rather than discovering drift at restore time
- Testing is either a frequency you buy or drawn from reactive hours. The agreement says which
When this add-on makes sense
Always included, then what your setup needs.
Every DR Management add-on includes the five things on the left. The rest depends on how the environment is built, which we establish before we quote rather than after.
How quickly you come back depends on what is standing by.
This is the trade-off worth deciding deliberately rather than discovering during an incident. Creating, licensing, and hosting the recovery environment is quoted separately unless a flat fee names it.
Infrastructure is available but systems are not pre-provisioned or running. Recovery is provision, restore, configure. Lowest cost, longest RTO. This is our default.
Systems are pre-provisioned and kept current by replication or scheduled restore. The event is an activation and cutover rather than a rebuild. Higher cost, shorter RTO.
We copy backup data off-site so it survives losing the primary. That is not the same as a running VM replica you can start in place. VM replication is not included unless the agreement says so.
RTO and RPO are design and validation targets. They are not service level commitments and carry no service credits. Default backup retention is 90 days, subject to capacity.
What sits outside the add-on.
Said here so it is not a discovery during an incident. Anything below can be added, but it is scoped and priced on its own.
What this add-on layers onto
DR Management is not a standalone product. It attaches to one proactive scope. Declared-disaster work needs a reactive agreement. 24/7 alerting on DR components is a separate NOC add-on unless it is bundled into the DR fee.
The backups and the covered servers or clusters live here. Without this, there is nothing for DR Management to attach to.
Read about TLC ProactiveRecovery work on the day is billed as reactive engineering, not absorbed into the monthly DR fee.
Read about TLC Reactive Flex TimeDR servers are not on 24/7 alerting unless they are listed under the NOC add-on or bundled into the DR fee. NOC credits never apply to recovery time or data loss.
Read about NOC AccessRecovery takes time by definition. If the requirement is staying served through a failure rather than coming back after one, that is high availability. You may want both.
Read about High AvailabilityExplore our other engagements.
There are a few different ways to work with us. Here are the other engagements you can explore.
Continuous, scheduled care of your Linux: monitoring, patching, backups, and maintenance across Basic, Standard, and High-Security tiers.
Read about TLC Proactive On-demand · block of hours TLC Reactive Flex TimePre-purchase senior Linux hours and draw from them for projects, troubleshooting, migrations, or emergencies.
Read about TLC Reactive Flex Time One-time · flat fee Get Me Out Of TroubleFast, best-effort help for an urgent one-off problem at a fixed price, with no ongoing commitment.
Read about GMOOT Add-on · 24×7 24×7 NOC AccessRound-the-clock emergency response with a 1-hour SLA on critical issues. Layers on top of Proactive and Reactive coverage.
Read about NOC Access Ongoing · clusters Cluster ManagementProactive management of your container platform clusters: upgrades, node ops, observability, and incident response.
Read about Cluster Management For partners White LabelLinux engineering delivered behind your brand for MSPs and IT firms. You own the client relationship; we do the work.
Read about White LabelWant to know how long a real recovery would take?
A 30-minute conversation is enough for us to understand what you are protecting, where it would need to come back, and whether your current backups could get you there.