Backups are the easy part.
Getting back up is the job.
Backup is the copies: the right method per workload, retention you can use, and a second copy that survives losing the original. Disaster recovery is the plan for using those copies: what is protected, how fast it comes back, where it comes back, and who does each step. We do both. Backups sit in proactive managed services. The recovery plan is the DR Management add-on.
Backup is one job.
Recovery is the other.
A green tick on a backup job is not a recovery plan. We take both seriously, and we sell them as the two layers they actually are.
File systems and databases are not the same job. Proactive managed services take incremental daily file-level backups and daily dumps of the supported database engines on the covered servers. Backup status is watched with the rest of the host, and backup results show up in the monthly report.
- Incremental daily file-level backups, 200 GB per included server
- Daily database dumps for supported engines on covered servers
- Up to 90 days retention, subject to available capacity
- Backup status monitored; failures escalated outside the monthly report
- VM-level backup where the estate is virtualized and a backup server is in scope
A backup on the same hardware as the original is a convenience, not protection. We get copies off the host and, where remote replication is in use, off the site. Backup replication (copying the backup data) is what we sell by default. A running VM replica you can start in place is a different thing, and is not included unless the agreement says so.
- Local backup server as the first source for a restore
- Remote backup server where an off-site replica is in use
- Replication health watched, where we manage the pipeline
- Data residency constraints kept in scope
- On a cluster scope, the configuration backup platform and replicas
Recovery is a procedure a person has to follow, often under pressure. DR Management is the add-on that writes that procedure down, agrees the targets, proves the backups restore, and reports where you actually stand. Running the recovery during a declared disaster is reactive work, not a monthly line item.
- A runbook: sequence, dependencies, credentials, and who does each step
- RTO and RPO agreed per environment, as objectives, not guarantees
- Periodic checks that backups complete, restore, and meet retention
- Failover and failback steps, with the decision points
- A readiness report, and tests where a frequency is purchased
How this usually
goes wrong.
Almost nobody discovers a backup or recovery problem on a quiet Tuesday. These are the ways it usually surfaces, and every one of them is avoidable with work done beforehand.
Backups ran for years, then a credential changed and they didn't. Nobody was watching the result, so the gap is only discovered when a restore is needed.
BackupThe files are there, but the database was copied mid-write and comes back inconsistent. A backup nobody has restored from is an assumption, not a copy.
BackupThe backup server sat on the same network with the same credentials, so it was encrypted alongside everything else. Distance and separation are the whole point.
BackupThe data survived, but pulling terabytes back over the available link and rebuilding hosts by hand takes far longer than the business assumed it would.
RecoveryServices come back in the wrong sequence, the application starts before its database is ready, and half the outage is spent working out dependencies under pressure.
RecoveryThe recovery plan lived in one engineer's head. When it's needed, the people in the room are reading configuration files and guessing at intent.
RecoveryWho needs backup and DR,
and who doesn't yet.
- Losing a day of data would mean re-entering work by hand, or losing it for good
- An hour of downtime costs you more than a month of protecting against it
- Your backups exist, but nobody has restored from them this year
- Nobody is watching whether the backup jobs still finish
- You answer to auditors, regulators, or a cyber insurer
- You run your own hardware, hypervisors, or a single site
- The recovery plan is one person who also takes holidays
- Everything that matters lives in SaaS you don't administer
- You could rebuild the environment from source and config in an afternoon
- The data is reproducible, or losing a week of it changes nothing
- You already have watched backup jobs, a tested runbook, and recent restore evidence
Worth separating two things people often merge: this is backup and recovery, not high availability. HA keeps you serving through a failure. DR gets you back after one. If downtime is the part you can't tolerate, you want both, and we'll say plainly which gap matters more for you.
Recovery targets are numbers we design and test against, not guarantees. Backups reduce risk; they do not eliminate it, they are not archival storage, and they are not a legal hold.
Speed depends on
what is standing by.
This is the trade-off worth deciding before an incident. Creating, licensing, and hosting the recovery environment is quoted separately unless a flat fee names it. RTO and RPO are objectives, not service credits.
Infrastructure is available, but systems are not pre-provisioned or running. Lowest cost, longest RTO. This is our default.
DefaultSystems are pre-provisioned and kept current by replication or a scheduled restore. The event is an activation, not a rebuild. Higher cost, shorter RTO.
FasterWe copy backup data off-site so it survives losing the primary. That is not a running VM you can start in place. VM replication is not included unless the agreement says so.
Default copyLinux backup and recovery,
done by Linux people.
Running production Linux for other people's businesses is the whole of what we do. Backup and DR are not products we resell. They are the part of the job where being specific about your stack matters most.
File-level and database backups are part of the proactive scope, not an extra vendor. Same engineers, same hosts, same report that already covers patching and monitoring.
- Incremental daily file-level backups
- Daily dumps of supported databases
- Backup results in the monthly report
The runbook is a deliverable, not tribal knowledge. It says what order things come back in, who is allowed to make each call, and where the credentials live. It stays useful when the person who built it isn't available.
- Recovery runbook, reviewed as the estate changes
- Failover and failback steps with named owners
- Targets agreed per environment, in writing
A plan written once and filed away decays as the estate changes. We verify the backups restore, watch the replication we manage, and report what we found, including the parts that need money or a decision from you.
- Regular restore verification, not just job status
- Recovery tests on an agreed schedule, or from reactive hours
- Readiness reporting with the gaps named
Backup in the scope.
DR as the add-on.
- Incremental daily file-level backups, 200 GB per included server
- Daily database dumps for supported engines
- Up to 90 days retention, subject to capacity
- Backup status watched with the rest of the host
The backups attach to the servers or clusters already under a proactive scope. There is no separate backup vendor to coordinate with.
Read about TLC Proactive- Runbook, RTO and RPO, backup validation, failover and failback, readiness report
- Attaches to exactly one proactive scope and covers only what that scope lists
- Replication, recovery environment, backup server, and tests only where the setup calls for them
- Declared-disaster recovery is reactive work, not in the monthly fee
One scope, one team. The add-on is preparation, documentation, validation, and testing, not the recovery itself.
Read about the DR Management add-on