DRaaS vs backup: la diferencia que se descubre el peor día

"Tenemos backup, estamos cubiertos". Es una de esas frases que suenan razonables hasta el día en que un servidor crítico muere a media mañana y alguien pregunta cuánto va a tardar en volver todo. La respuesta —"unas horas, tal vez el día"— es cuando se descubre, demasiado tarde, que backup y recuperación ante desastres no son lo mismo.

Backup: te devuelve los datos

Un backup es una copia de tu información guardada para poder recuperarla más adelante. Es imprescindible: te protege contra borrados, corrupción, ransomware, y guarda el histórico que necesitas. Pero tiene una característica que a veces se ignora: restaurar toma tiempo. Recuperar los datos, levantar los servidores, reconstruir el entorno, verificar que todo hable entre sí. Según el tamaño, eso son horas o días de trabajo. El backup garantiza que no perdiste la información; no garantiza que sigas operando mientras la recuperas.

DRaaS: te devuelve la operación

DRaaS —Disaster Recovery as a Service— resuelve la otra mitad. En lugar de guardar solo copias, mantiene una réplica de tus sistemas lista para arrancar en un sitio alterno, normalmente en la nube. Cuando el entorno principal cae, haces failover: la réplica toma el relevo y sigues trabajando en minutos, no en días. No estás restaurando desde cero; estás encendiendo algo que ya estaba casi listo. La diferencia, en una línea: el backup protege tus datos; DRaaS protege tu continuidad.

Lo que decide cuál necesitas: el RTO

La pregunta no es cuál es "mejor" —resuelven cosas distintas— sino cuánto tiempo puede estar caído cada sistema. Ese número es el RTO, que explicamos en RPO y RTO en cristiano, y es el que manda:

• Si un sistema puede tolerar un día de recuperación sin que el negocio sufra de gravedad, un buen backup basta y es más económico.
• Si cada hora caído cuesta tanto que horas de recuperación son inaceptables, entras en terreno de DRaaS.

Casi ningún negocio necesita solo uno: la mayoría necesita ambos, aplicados a distintos sistemas según su criticidad. DRaaS para el puñado de servicios que no pueden parar; backup para todo lo demás y para la retención a largo plazo. No compiten: se complementan.

El detalle que la gente descubre tarde: hay que probar el failover

Igual que un backup sin probar no es un backup, una réplica de DRaaS que nunca se ha ejercitado es una promesa, no una garantía. El failover se ensaya: se simula la caída, se levanta en el sitio alterno, se mide cuánto tardó de verdad y se valida que las aplicaciones funcionen allí. Un DRaaS que solo existe en el papel suele fallar justo cuando se le necesita.

El trade-off honesto

DRaaS cuesta más que un backup, y es lógico: mantener una réplica lista para operar es más que guardar copias. La forma correcta de justificarlo no es el miedo, sino el número: cuánto te cuesta realmente una hora sin ese sistema. Cuando esa cifra —que puedes estimar con la calculadora de costos de downtime— supera con claridad el costo de la réplica, DRaaS deja de ser un lujo y se vuelve la decisión sensata. Dibujar qué sistemas van a DRaaS y cuáles a backup —y por qué— es el corazón de un plan de continuidad.

Visto de cerca, un DRaaS es un DR site en la nube: un sitio de recuperación que solo enciendes cuando lo necesitas. Y dónde encaja esa decisión dentro del conjunto lo explica la guía completa del DRP.