Servidor de disaster recovery: qué es y cuándo lo necesita una PYME

Hay una pregunta que deja callada a mucha gente en mitad de una avería. Las copias están bien, se han localizado, incluso se han verificado. Y entonces alguien dice lo evidente. Vale, ¿y esto dónde lo arrancamos?

Ahí es donde entra el servidor de disaster recovery. Es la pieza que casi nunca se presupuesta y la que decide si una restauración dura una tarde o una semana, porque restaurar sin destino no es restaurar, es esperar a que llegue hardware.

¿Qué es un servidor de disaster recovery?

Un servidor de disaster recovery es una máquina, física o virtual, preparada de antemano para asumir el trabajo del servidor de producción cuando este cae. No guarda copias sin más, tiene la capacidad, la configuración y las licencias necesarias para poner los sistemas en marcha. Su única razón de existir es recortar el tiempo que la empresa está parada.

La diferencia con una copia de seguridad es de naturaleza, no de tamaño. La copia contiene los datos. El servidor de recuperación es el sitio donde esos datos vuelven a ser una empresa que factura. Uno sin el otro deja el trabajo a medias, y es la razón por la que muchas recuperaciones se cuentan en días mientras el plan hablaba de horas. Lo vemos con números en el artículo sobre cómo montar un plan de disaster recovery.

Los tres niveles: standby frío, templado y caliente

"Standby" significa que la máquina está a la espera. Lo que cambia entre los tres niveles es cuánto tarda en despertarse y cuánto cuesta tenerla ahí.

• Frío. Hay hardware disponible, pero apagado y sin nada instalado. El día del incidente se instala sistema, aplicaciones y datos. Es lo más barato y lo más lento. Hablamos de días, no de horas.
• Templado. La máquina existe, tiene sistema y aplicaciones instaladas, y recibe los datos de forma periódica, por ejemplo cada pocas horas. Arranca en cuestión de horas y se pierde el trabajo desde la última sincronización. Es el punto donde encaja la mayoría de PYMEs.
• Caliente. El servidor replica de forma continua y está listo para asumir la carga en minutos. Se usa cuando parar cuesta demasiado, como en producción industrial o en clínicas con actividad asistencial.

La elección no es cuestión de gusto, sale de los números que ya deberías tener. Si tu tiempo objetivo de recuperación es de cuatro horas, un standby frío no vale por muy barato que sea. Si es de tres días, pagar un standby caliente es tirar dinero.

Dónde ponerlo, y por qué no vale la sala de al lado

El destino más común en una PYME es un equipo local de recuperación, lo que en el sector se llama un BDR. Es una máquina que se queda en la oficina recibiendo copias cada pocas horas y que, si el servidor principal muere, arranca sus sistemas virtualizados y aguanta la operativa mientras se repara el original. Es rápido, porque los datos ya están ahí y no hay que descargarlos.

Tiene un límite evidente. Si el incidente afecta al edificio, un incendio, una inundación o un robo, el equipo de recuperación cae con el original. Por eso lo razonable en la mayoría de casos es combinar dos destinos:

• El equipo local resuelve lo que pasa el 90% de las veces, una avería de hardware o un cifrado del servidor, y lo resuelve en minutos.
• La réplica en nube cubre el desastre del edificio y permite levantar los sistemas desde otro sitio, con el salto automático que en el sector se llama failover.

Si solo puedes tener uno, que no comparta con el servidor principal ni la sala, ni el SAI, ni el segmento de red. Un servidor de recuperación enchufado al mismo sistema de alimentación que el que quieres proteger no es un plan, es una copia del mismo riesgo.

¿Cuánto cuesta un servidor de disaster recovery?

Depende sobre todo del nivel de standby y de cuántos sistemas tiene que sostener. Un standby frío puede resolverse reutilizando hardware ya amortizado, uno templado suele implicar un equipo dedicado con disco suficiente para guardar varias versiones de tus datos, y uno caliente añade el coste de mantener recursos encendidos o reservados en nube.

Hay dos partidas que casi siempre se olvidan al pedir presupuesto. La primera son las licencias, porque el sistema operativo, el hipervisor que virtualiza las máquinas y algunas aplicaciones de gestión pueden necesitar licencia propia en el servidor de recuperación. La segunda es la línea de internet, que condiciona lo rápido que suben las copias y lo rápido que bajan el día que hacen falta.

Para saber si el número es alto o bajo, ponlo al lado del coste de una parada. Si una jornada sin sistemas te cuesta doce mil euros de actividad, discutir sobre unos cientos de euros al mes es discutir el problema equivocado. Los modelos de precio del mantenimiento los desglosamos en cuánto cuesta el mantenimiento informático de una PYME.

¿Hace falta si todo está en la nube?

Sí, aunque cambie de forma. El proveedor de nube garantiza que su plataforma funcione, no que tus datos vuelvan si alguien los borra o si un atacante entra con credenciales válidas. En ese escenario el destino de recuperación deja de ser una máquina en tu oficina y pasa a ser una copia independiente del proveedor, con capacidad para restaurar en otro entorno o en otra región.

Con Microsoft 365 pasa exactamente eso, y es el malentendido más caro que nos encontramos, porque la licencia no incluye copia de seguridad. Y si tienes servidores virtuales en nube, revisa si lo que has contratado es una copia real o solo una instantánea guardada en la misma infraestructura que quieres proteger.

Los fallos que más vemos en servidores de recuperación

• No cabe. El equipo se dimensionó hace cuatro años y los datos han crecido. Guarda menos versiones de las que dice el plan, o directamente ya no completa la copia.
• Faltan licencias. Los sistemas arrancan y se paran a las pocas horas pidiendo activación. Se descubre el día peor.
• La red no está pensada. Los sistemas levantan, pero nadie llega a ellos porque las direcciones, el DNS o la VPN siguen apuntando a la máquina que ya no existe.
• Nunca se ha arrancado. El equipo lleva dos años recibiendo copias sin que nadie haya encendido una sola máquina virtual desde él.

Los cuatro tienen el mismo origen, se compró el hardware y se dio por hecho todo lo demás. Un servidor de recuperación no se instala, se mantiene.

¿Cada cuánto se prueba el failover?

Al menos una vez al año conviene hacer un arranque completo desde el servidor de recuperación, y cada trimestre una prueba parcial de alguna máquina o servicio. También hay que repetirla después de cualquier cambio grande, un servidor nuevo, una migración o un cambio de aplicación de gestión.

La prueba no consiste en ver si enciende. Consiste en cronometrar cuánto tarda en estar disponible, comprobar que los usuarios trabajan de verdad contra él y anotar lo que ha fallado. Ese cronómetro es el único dato honesto que vas a tener sobre tu tiempo de recuperación, y casi siempre es mayor que el que la gente estima de memoria. Pasa lo mismo con las copias, que hay que probarlas para saber que existen.

Cómo saber si el tuyo serviría mañana

Tres preguntas rápidas. ¿Dónde arrancarían tus sistemas si el servidor principal no encendiera mañana? ¿Cuándo fue la última vez que alguien lo encendió para comprobarlo? ¿Y ese destino aguantaría también un problema del edificio, no solo una avería de disco?

En Nodetic el equipo local de recuperación y el salto a la nube van dentro de los planes de continuidad informática, con tiempos de recuperación por escrito y pruebas con fecha en el calendario. Si prefieres empezar por saber dónde estás, en una auditoría de continuidad informática revisamos tus copias, tu destino de recuperación y cuánto tardarías hoy en volver a trabajar.