La copia de seguridad automática llevaba funcionando dos años. El día de la interrupción, nadie sabía cómo restaurar: instantánea incorrecta, base de datos corrupta, DNS todavía apuntaba al servidor anterior. "Teníamos copias de seguridad", sí. Sin plan de recuperación.
Este escenario se repite en cuanto un equipo confunde copia y continuidad. Un PRA (plan de recuperación ante desastres) responde a preguntas específicas: cuánto tiempo puede estar sin servicio (RTO), cuántos datos puede perder (RPO), quién hace qué, en qué orden y cómo informar a los clientes y socios. Las copias de seguridad que ofrece el servidor son sólo un ladrillo, no el plan. Cruce con El mito del 99,99%: Los créditos SLA nunca reemplazan a una organización que sabe cómo recuperarse.
Definir RTO y RPO empresarial
RTO y RPO no se eligen basándose en sentimientos técnicos. Reflejan una tolerancia al riesgo empresarial: pérdida de ventas, imposibilidad de facturar, incumplimiento contractual hacia un cliente B2B. Comience con una tabla simple, validada con el gerente o gerente de producto.
| Sitio | RPO indicativo | RTO indicativo |
|---|---|---|
| Comercio electrónico | 15 minutos – 1 hora | 1 a 4 horas |
| SaaS B2B | 5 a 15 minutos | < 1 hora |
| Web corporativa | 24 horas | 4 a 24 horas |
| Blog | 24 horas | 48 horas |
Un RPO de una hora implica una copia de seguridad cada hora, o incluso registros binarios si la base de datos lo permite. Un RTO de cuatro horas requiere un procedimiento documentado y una restauración previamente probada, no un primer intento bajo estrés un domingo por la noche. Si nadie ha cronometrado una restauración completa, el RTO que se muestra es una suposición.
Arquitectura mínima y función del anfitrión.
La regla 3-2-1 sigue siendo la base: tres copias, dos medios, uno externo. Haz un inventario completo: código en Git, base de datos, archivos subidos, registros DNS, secretos y certificados. Escriba un runbook numerado: que llame al host, que cambie el DNS, que valide la base de datos restaurada; consulte redirects domaine para conocer las trampas de conmutación.
Prepare un entorno de recuperación: VPS frío, imagen lista o segundo host documentado. Planifique la comunicación externa a través de una página de estado y mensajes de incidentes escritos con antelación. El anfitrión suele proporcionar instantáneas; usted debe exportar la base de datos, cifrar una copia externa, probar la restauración y administrar una conmutación por error de DNS secundaria si el problema lo amerita.
Probar la restauración: la única prueba que cuenta
Una copia de seguridad que nunca se ha restaurado es una promesa. Cada trimestre, realizar un ejercicio completo: restauración en staging, verificación de cargas, prueba de conexión de aplicaciones, medición en tiempo real. Tenga en cuenta las diferencias entre la duración medida y el RTO anunciado.
Aquí aparecen fallas típicas: complemento de respaldo que excluye el directorio uploads, instantánea demasiado antigua, versión de PHP incompatible en el servidor de recuperación, secretos faltantes en la bóveda. Corrija el proceso después de cada ejercicio, no sólo el colapso imaginario.
Conmutación, DNS y segundo host
Para sitios críticos, un segundo host o una zona de recuperación preconfigurada reduce el RTO. El cambio de DNS sigue siendo el punto débil: TTL alto, caché de resolución, certificados vinculados al servidor antiguo. Documente la secuencia: reducción de TTL el día anterior a un cambio planificado, alternancia A/AAAA, verificación HTTPS, reversión si falla.
Un modo de espera en frío cuesta menos que un modo de espera en caliente, pero prolonga el tiempo para volver al servicio. La elección se basa en el RTO aceptado y el presupuesto, no en el ego técnico del equipo.
La cumbre: salvaguardar tranquiliza; sólo la restauración prueba
Decide y avanza sin puntos ciegos
Comience estableciendo un RTO y un RPO por servicio crítico, validados con la empresa. Luego automatice las copias de seguridad externas y mantenga un inventario de secretos y dependencias. Programe una prueba de restauración trimestral y registre la duración real observada. Compare los anfitriones que documentan sus instantáneas y procedimientos a través del directorio. Considere un segundo anfitrión o área de recuperación si el interés financiero o de reputación excede el costo del despido.
Preguntas frecuentes
¿Cuál es la diferencia entre plan de respaldo y recuperación?
Copias de seguridad de datos. El plan de recuperación define quién restaura qué, en cuánto tiempo, con qué pérdida aceptable y cómo continuar si el host no está disponible. Sin un procedimiento escrito y probado, la copia sigue siendo teórica el día de la crisis.
¿Son suficientes las copias de seguridad automáticas del host?
No, no solo. La frecuencia, la conservación y la restauración no siempre están garantizadas contractualmente. Se requiere una copia externa, una prueba trimestral y un procedimiento documentado; consulte alojamiento de CGV.
¿Qué RTO/RPO para un sitio de comercio electrónico?
Indicativo: RPO inferior a una hora para las órdenes, RTO inferior a cuatro horas para reanudar la negociación, que se calibrará en función del volumen de negocios perdido por hora. Un blog de exhibición suele tolerar veinticuatro horas; una cesta bloqueada durante el día cuesta mucho más.
¿Se necesita un segundo host?
Para sitios críticos, sí: conmutación por error de DNS, infraestructura en espera, runbook validado. El costo se compara con el riesgo. En los servicios compartidos, un segundo host no es obligatorio si un RTO prolongado sigue siendo aceptable, siempre que se asuma explícitamente.
Una copia de seguridad que nunca restauraste es una promesa. Una PRA es la promesa cumplida contra un cronómetro.