Documentation / Platform glossary / Disaster Recovery
Disaster recovery is the planned capability to restore service after a significant failure — a region outage, data corruption, or a destructive incident. It is defined by two measurable objectives: how quickly service returns, and how much recent data is acceptable to lose.
Two objectives carry the definition.
Recovery time objective (RTO) is the maximum acceptable duration between failure and restored service. Recovery point objective (RPO) is the maximum acceptable amount of data loss, expressed as time — an RPO of one hour means up to an hour of recent work may be unrecoverable.
The two are independent and cost differently. Low RTO requires standby capacity ready to take over. Low RPO requires frequent or continuous replication. A system can restore quickly while losing recent data, or lose almost nothing while taking hours to return.
Disaster recovery is distinct from high availability, and the distinction is often blurred. High availability handles expected component failures automatically and continuously, within a single environment. Disaster recovery handles the loss of that whole environment, and generally involves a deliberate decision to invoke it. A system can be highly available and still have no disaster recovery capability.
The part that determines whether any of it works is testing. Backups that have never been restored are an assumption, not a capability, and untested failover procedures reliably surface undocumented dependencies at the worst moment. Restoration tests, not backup success rates, are the evidence that matters.
RTO and RPO are business decisions expressed in technical terms. Stating them forces an explicit answer to how much downtime and data loss the organization can absorb, rather than discovering the answer during an incident.
For an evaluator, the useful questions are what the stated objectives are, when recovery was last tested end to end, and what the test found.
QueryTek maintains recovery objectives and tests restoration rather than relying on backup completion alone. Public documentation describes the practice; specific objectives, topology, and runbooks are shared through direct engagement and contractual terms.
