Continuidad de negocio: qué pasa si cae el servidor un viernes

Viernes, 18:40. En muchas empresas de Tenerife alguien apaga la luz de la oficina y se lleva el móvil. En otras, la clínica aún cierra historiales, la asesoría aún lanza un envío y el almacén aún imprime albaranes. Entonces el servidor deja de responder. No hay un error elegante en pantalla: hay carpetas que no abren, un programa de gestión que se queda en blanco y esa frase peligrosa: «ya lo vemos el lunes». Si facturas, nóminas o la agenda del sábado dependen de esa máquina, el lunes no es una opción. Es una pérdida que ya empezó el viernes.

Este texto no es un manual de pánico ni un anuncio de hardware. Es continuidad de negocio en cristiano: qué es el RTO y el RPO cuando no eres consultor, quién llama a quién, qué significa restaurar de verdad y cuándo un híbrido (sede + nube) te deja trabajar aunque el torre no arranque. El servicio de servidores para empresas y el de copias de seguridad son las landings. Aquí va el escenario que usamos para que dirección entienda el contrato antes de firmarlo.

Horario real de una isla: Infofase atiende en Santa Cruz de lunes a jueves de 08:00 a 16:00 y los viernes de 08:00 a 14:00. Las 18:40 de un viernes caen fuera de ese reloj. Por eso el plan no puede ser «llamo al técnico de siempre y ya». El plan es saber qué está cubierto en el mantenimiento informático, qué se puede hacer en remoto, quién tiene llave del local y qué parte del negocio puede seguir en Microsoft 365 mientras el servidor duerme.

El escenario: viernes 18:40 y el servidor no responde

Empieza por describir lo que ves, no lo que temes. ¿No pinguea? ¿Hace ruido raro? ¿Huele a quemado? ¿Se fue la luz del cuarto y el SAI pitó hasta callarse? ¿Solo falla un programa y el resto de la red va? Esas distinciones cambian la noche. Un corte eléctrico con SAI agotado no se «repara» a martillazos: se espera corriente y se mira si los discos quedaron a medias. Un disco que cruje no se sigue encendiendo «a ver si arranca». Un ransomware que cifra el volumen de datos no se arregla restaurando encima sin aislar. Un switch de rack caído se disfraza de servidor caído: las carpetas no se ven, pero la máquina puede estar sana.

El error humano más caro de esa hora es el heroísmo. Reiniciar diez veces. Enchufar el disco a un portátil «para sacar lo importante». Dejar a un compañero «muy manitas» abriendo la caja. Cada una de esas acciones puede convertir un incidente de hardware en un incidente de datos. Si hay olor a electrónico o clic de disco, apagado limpio si aún puedes, y llamada. Si hay mensaje de rescate en pantalla, red fuera, no pagar a ciegas y el plan de respuesta a ransomware, que no es el mismo que un fallo de fuente.

El segundo error es el silencio organizado. Nadie avisa a dirección. Nadie avisa a quien abre el sábado. El WhatsApp del equipo se llena de «a mí no me va» sin un único interlocutor. A las 19:10 hay tres versiones de lo ocurrido y ninguna foto del display del SAI. La continuidad empieza por un canal: una persona cuenta hechos al partner o al técnico de guardia. El resto deja de experimentar.

El tercer error es asumir que «en la nube estamos cubiertos». Si el programa de gestión es un ejecutable contra una base en el servidor, OneDrive no te salva la factura del viernes. Si el correo ya está en Microsoft 365, el correo sí sigue. Esa diferencia —qué es local y qué no— debería estar escrita en una hoja de una página, no en la cabeza de quien está de vacaciones. El viernes a las 18:40 no se inventa el mapa: se consulta.

En Canarias el contexto suma: recambio que no vuela solo, un puente, un técnico que no está en el municipio. Por eso el escenario no es «el fabricante envía una pieza el lunes». Es «qué hacemos las siguientes doce horas con lo que hay en isla». Stock de disco, imagen de recuperación, o trabajo en modo degradado. Quien no ha pensado eso no tiene plan de continuidad: tiene esperanza.

RTO y RPO en cristiano (sin slide de consultora)

RTO es cuánto tiempo puedes estar sin el servicio. No «sin el servidor» en abstracto: sin facturar, sin ver la agenda, sin entrar al ERP, sin el historial. Si tu RTO real es «el lunes a primera hora», entonces un viernes 18:40 te cabe en el colchón… siempre que el sábado no exista y que el lunes el restore funcione a la primera. Si tu RTO real es «cuatro horas porque el sábado hay citas», el contrato de backup que restaura en dieciséis horas es teatro.

RPO es cuánta información puedes permitirte perder, medida en tiempo. Una copia de cada noche significa que, si el servidor muere a las 18:40, puedes perder todo lo tecleado desde las 22:00 del jueves (o desde cuando se hizo la última copia buena). Si alguien pasó la tarde cargando albaranes, ese trabajo no está en la cinta de anoche. Un RPO de 24 horas es aceptable para un archivo muerto. Es cruel para un mostrador que factura en continuo. Ahí hacen falta copias más frecuentes, réplica o un NAS con snapshot, no un disco USB que alguien «ya acordará».

La forma de hablarlo con gerencia es una mesa de tres columnas: proceso de negocio, horas máximas parado, datos máximos que se pueden rehacer a mano. Facturación. Nóminas (que suelen tolerar más RTO salvo fin de mes). Correo (si ya está en M365, el RTO del servidor no aplica). Históricos. El número que sale no es un SLA de marketing: es el diseño de la copia y del recambio. Pedir RTO de una hora con una sola copia semanal en el mismo armario es pedir un milagro.

Hay que decir en voz alta la mentira del «tenemos backup». Tener un NAS no es tener continuidad. Tener un NAS en el mismo rack que el servidor es tener dos huevos en la misma cesta. Tener una copia en la nube que nadie ha restaurado nunca es tener una hipótesis. La regla que lo explica sin jerga está en la regla 3-2-1 para gerentes. El viernes no se estudia la regla: se comprueba si se cumplió.

RTO y RPO no son simétricos. Puedes restaurar rápido (buen RTO) y aun así perder el día entero de datos (mal RPO). Puedes no perder casi nada (buen RPO, réplica continua) y tardar un día en tener sitio donde montarlo (mal RTO: no hay hardware de recambio). El plan honesto ataca los dos. El presupuesto honesto también: la réplica y el segundo disco cuestan menos que rehacer a mano una semana de trabajo… hasta que no lo has calculado.

Una frase que dirección puede repetir

«Si esto se cae un viernes a última hora, volvemos a facturar en X horas y podemos perder como mucho Y horas de tecleo.» Si nadie en la empresa puede completar X e Y, no hay continuidad: hay improvisación. Completarlos es el trabajo previo, no el de las 18:41.

Quién llama a quién y en qué orden

Escribe los nombres antes del incidente. No «informática». Personas y teléfonos. En una PYME típica la cadena cabe en un folio.

1. Quien detecta: deja de tocar, anota hora y síntomas, foto del SAI o de la pantalla si es seguro, avisa a la persona de continuidad (suele ser gerencia o administración, no el becario).
2. Persona de continuidad: decide si se cierra el local, si se avisa a clientes del sábado, y llama al partner o al técnico de guardia. Un solo relato.
3. Partner / guardia: clasifica (luz, red, hardware, ransomware, almacenamiento). Da la primera instrucción: no encender, no conectar discos, no pagar, desconectar switch, etc.
4. Dueño de la llave del rack: si hace falta presencia, alguien abre. Un contrato de mantenimiento sin llave ni acceso al cuarto es un contrato de consuelo.
5. Dueño de las copias: confirma la hora de la última copia buena y dónde está (NAS, nube, disco offsite). Si esa persona está en La Gomera sin cobertura, el plan ya falló.

El teléfono 922 276 335 y el WhatsApp +34 653 551 192 existen para el horario de oficina. Fuera de él, lo que vale es lo que hayáis pactado: extensión de guardia, respuesta al día siguiente, o un procedimiento de «modo degradado» hasta el lunes. Ninguna de las tres opciones es inmoral. Lo inmoral es no decirlo. Si tu negocio no aguanta hasta el lunes, el contrato tiene que decir cómo se cubre la noche del viernes. Eso cuesta dinero. El técnico interno de plantilla tampoco está 24×7: se va de puente, se pone enfermo, no coge el teléfono. El debate de costes está en outsourcing IT frente a técnico interno. El viernes solo pregunta: ¿hay alguien obligado a coger esa llamada?

Comunicación hacia dentro: un mensaje único. «Servidor fuera de servicio. No reiniciéis por vuestra cuenta. Correo y Teams siguen. Gestión local no. Os actualizamos a las 20:00.» Comunicación hacia fuera: solo si el cliente nota el fallo (citas, pedidos). No hace falta un comunicado épico. Hace falta no dejar a la recepcionista inventando excusas técnicas.

Lo que no se llama a las 18:40: el comercial del hosting, el primo, el foro, el fabricante del ERP para «ver si es cosa suya» antes de saber si la máquina tiene pulso. Se puede escalar después. Primero, clasificación.

Restaurar no es «darle al play»

Restaurar es una operación con orden, tiempo y criterios de éxito. ¿Restauras el servidor entero (bare metal / imagen) o solo el volumen de datos? ¿El Active Directory está en esa máquina y no hay segundo controlador? ¿La copia de anoche terminó bien o el log dice que falló el viernes a las 03:12 y nadie lo vio? ¿El NAS de backup está en el mismo SAI muerto? Cada «sí» alarga la noche.

El procedimiento mental, sin convertirlo en un runbook de película: 1) confirmar que no es ransomware ni sabotaje, o aislar si lo es; 2) confirmar que el hardware destino sirve (la misma máquina si solo fue software; otra si ardió la placa); 3) elegir el punto de restauración (última copia buena, no la más reciente si está corrupta); 4) restaurar primero lo que desbloquea el negocio (base del ERP, no la carpeta de ISOs de 2017); 5) verificar que la aplicación abre y que un usuario de prueba factura o consulta; 6) solo entonces abrir el grifo al resto. Quien restaura «todo» y reabre sin probar entrega un lunes de sorpresas.

Tiempos reales, no de brochure. Una imagen de 2 TB por un enlace de 100 Mbps no llega en una hora. Una restauración desde un NAS local a 10 Gb no se parece a una restauración desde un cubo en Fráncfort a través de la fibra de la oficina. Por eso el diseño de la copia incluye el camino de vuelta. Si tu única copia buena está a 40 ms y 20 Mbps de subida, tu RTO ya está escrito y no te va a gustar. Tener servicios de backup cloud tiene sentido como tercera copia, no como única vía de restore el viernes por la noche.

Prueba. La palabra aburrida que evita el teatro. Una restauración ensayada en enero te dice si el software de backup pide una licencia que nadie renovó, si el disco de destino es más pequeño, si el ERP necesita un dongle que está en un cajón. El ensayo no tiene que tumbar producción: se restaura a una máquina de prueba o se recupera un buzón / una carpeta testigo. Quien no ensaya, el viernes descubre el procedimiento.

Hay un límite ético y técnico: si el disco está crujiendo, no es un restore, es una decisión de recuperación de datos. Seguir encendiendo para «sacar una última copia» puede ser lo que mate el plato. El partner tiene que saber cuándo parar. Dirección tiene que aceptar que a veces el camino es laboratorio, no el botón de restore.

Híbrido: lo que puede seguir en la nube mientras el servidor duerme

El híbrido bien pensado no es una ideología. Es una lista. Correo en Exchange Online: sigue. Teams: sigue. SharePoint y OneDrive: siguen, si de verdad eran el sitio de trabajo y no un espejo abandonado. VPN a un firewall que sigue vivo: a veces sigue, aunque el servidor de ficheros no. El ERP en el servidor: no sigue, salvo que tengas terminales en Azure o una réplica. Las impresoras de red: depende del servidor de impresión. El fichero «contratos» en el NAS: no sigue.

Esa lista se redacta en frío. Se comunica al equipo: «si cae el servidor, trabajáis así». Un comercial puede seguir el hilo de un cliente por Outlook. Un administrativo no puede emitir la factura del software local. Entonces la continuidad híbrida es parcial, y hay que decirlo. Vender «estamos en la nube» cuando el núcleo sigue en un torre es crear una expectativa que el viernes se rompe.

El híbrido también es de identidad. Si las contraseñas y los permisos viven solo en un Active Directory sin segundo controlador y sin Azure AD, la caída del servidor no es solo de ficheros: es de login. Los equipos que ya tenían sesión abierta pueden durar un rato; los que se reinician, no. Un segundo DC, o identidades en Microsoft 365 con los PCs unidos de forma híbrida o cloud, cambia el RTO de «nadie entra» a «no vemos las carpetas de siempre». No es lo mismo.

Réplica: un NAS en otro local, un tenant con backup, o un host de virtualización que pueda levantar la VM. No todas las PYMES lo necesitan. Las que facturan el sábado o no pueden rehacer el día a mano, sí. El coste se discute en enero, no a las 19:00. En Tenerife, «otro local» puede ser otra oficina del grupo o un datacenter / nube con prueba de restore. Lo que no vale es la copia en el cajón del mismo fuego, del mismo robo y del mismo SAI.

Modo degradado honesto: papel, Excel en OneDrive, aplazamiento de lo que no es crítico. Da feo. Evita el caos de diez versiones. Alguien lidera qué se registra a mano para picarlo el lunes. Eso también es continuidad. No todo es tecnología.

Lo que hay que haber hecho el jueves

El jueves, no el viernes. Copia de anoche verificada (log leído, no icono verde de oídas). Una copia fuera del rack. Documentación de la última restauración de prueba (fecha). Inventario: qué VM o qué roles hay en esa máquina. Contraseñas de restore en un sitio que no sea el propio servidor. Firmware y parches al día, pero no «actualicé el hypervisor a las 17:50». Espacio libre en el destino de backup. SAI con batería que no tiene cinco años y nadie midió. Teléfonos del folio de continuidad actualizados (la persona que se fue en marzo ya no está).

Monitorización. Un servidor que muere «de repente» a menudo llevaba semanas avisando: disco predictivo, temperatura, RAID degradado, copia fallida. Quien no mira, el viernes cree en los milagros. El mantenimiento no es un técnico que viene cuando duele: es alguien que ve el aviso el miércoles y cambia el disco el jueves. Esa es la diferencia entre un incidente de dos horas y uno de dos días.

Acuerdos. Con el partner: tiempos, guardia, qué está incluido. Con el proveedor del ERP: si la licencia de restore o el dongle están documentados. Con el seguro: qué cubre un fallo de hardware y qué no cubre un ransomware. Con dirección: presupuesto de recambio. Un disco de servidor no se compra en el centro comercial a las 20:00 con la misma alegría que un pendrive.

Cultura. El equipo sabe que no se guarda «lo importante» solo en el escritorio del servidor. Sabe que el USB del cajón no es plan B. Sabe a quién escribir. Eso se entrena en cinco minutos de reunión, no en un máster.

Cómo ensayar el plan sin tumbar la oficina

Un simulacro no es apagar el servidor en producción un martes a las 11:00 para «ver qué pasa» salvo que tengas autorización, ventana y restaurador listo. Es más aburrido y más útil. Restaurar una carpeta testigo al mes. Restaurar una VM en un host de pruebas una vez al trimestre. Recorrer el folio de llamadas en voz alta (cinco minutos). Comprobar que el NAS offsite responde. Comprobar que MFA no bloquea al único admin el día que no está el móvil de siempre. Revisar que el backup cloud no está en la misma cuenta que un administrativo puede vaciar.

Apunta el tiempo. «La carpeta de facturas 2025 tardó 18 minutos desde el NAS.» Ese número alimenta el RTO. Si tardó tres horas, o el RTO es mentira o hay que cambiar el diseño. El ensayo que no se cronometra es teatro de calidad.

Cuenta a dirección el resultado en una frase, no en un PDF de 40 páginas. «En marzo restauramos; tardaríamos una tarde en volver a facturar; perderíamos como mucho el día en curso; el sábado no estaríamos cubiertos.» Si esa frase no gusta, se cambia el diseño. No se cambia la frase para que guste.

El ensayo también revela vanidad: copias de sistemas que nadie usa, y ningún backup del único Access que lleva el almacén. El inventario de lo crítico se corrige entonces, no a las 18:50.

Preguntas frecuentes

¿El viernes a las 18:40 en Tenerife tenéis a alguien al teléfono?

El horario de oficina termina antes. La guardia, si la hay, es un pacto del contrato de mantenimiento, no un supuesto. Pregúntalo antes. Si tu RTO no aguanta hasta el lunes, dilo en la primera reunión. Improvisar esa pregunta el viernes es tarde.

¿Cuánto se pierde si solo hay copia nocturna?

Todo lo tecleado desde esa copia. En un viernes a las 18:40, casi un día laboral. Si eso es inaceptable, hay que acortar el RPO: más frecuencia, snapshot, réplica. No hay truco de software que invente datos que no se copiaron.

¿Restaurar en la nube es más rápido que en el NAS de la oficina?

Casi nunca, si el NAS está sano y la red local es decente. La nube brilla como copia fuera del edificio y como origen si el local ardió o el NAS murió con el servidor. El camino de vuelta hay que medirlo.

¿Un segundo servidor en la misma sala resuelve el RTO?

Resuelve algunos fallos de máquina. No resuelve fuego, robo, rayo en el cuarto ni ransomware que cifra los dos. La 3-2-1 sigue aplicando.

¿Qué hago yo, que no soy técnico, a las 18:41?

Deja de experimentar. Anota. Llama al número del folio. Di si hay olor, luces del SAI, mensaje de rescate o solo carpetas inaccesibles. No conectes discos a otro PC. Avisa a quien abre mañana si el sábado importa.

¿El correo de Microsoft 365 sigue si cae nuestro servidor?

Si el correo ya vive en Exchange Online y la identidad no depende en exclusivo de un único DC caído, sí. El ERP local, no. Por eso el mapa híbrido se escribe antes.