No toda aplicación pertenece a la nube pública. Un control de máquinas que debe responder en el rango de los milisegundos, un sistema de gestión de mercancías con grandes conjuntos de datos locales, un procedimiento especializado con requisitos estrictos de soberanía de datos: tales cargas de trabajo se ejecutan por buenas razones allí donde surgen, en la propia casa. La latencia, el control sobre los datos y la estructura de costes con carga constante hablan entonces claramente a favor del servidor en local.
El problema no es el servidor local. El problema es el servidor local como único lugar. Una sala de servidores en un emplazamiento es una construcción con un único punto de fallo (single point of failure): frente a incendio, daño por agua, robo, corte de electricidad y, desde hace tiempo el caso más frecuente, frente a un atacante que cifra simultáneamente toda la red. Quien quiera conservar las ventajas de la operación local sin asumir su fragilidad no puede eludir una pregunta: ¿qué pasa si mañana esa única sala ya no está?
La falsa alternativa: o local o nube
El relato extendido dice que hay que decidirse: centro de datos o sala de servidores propia, nube o local (on-premises). Es una falsa alternativa. La operación local resuelve requisitos reales de latencia y soberanía de datos que una migración pura a la nube no elimina con palabras. A la inversa, el centro de datos externo resuelve el riesgo de emplazamiento que una operación puramente local no cubre estructuralmente. Ambos lados son fuertes para tareas distintas.
La respuesta viable no es un o lo uno o lo otro, sino un reparto de tareas: los sistemas productivos se ejecutan allí donde pertenecen —en local—. Su copia de seguridad y una vía de recuperación se ubican allí donde sobreviven a un evento local —en el centro de datos separado geográficamente—. Lo llamamos el puente híbrido: operación local y capacidad de recuperación externa como un modelo operativo continuo, no como dos contratos separados.
Qué permanece local y qué se replica
El reparto no sigue ninguna ideología, sino la pregunta de dónde despliega una carga de trabajo su utilidad y dónde se necesita una copia en caso de emergencia.
Local permanece la operación productiva. Todo lo que se beneficia de trayectos cortos y baja latencia, o necesita grandes volúmenes de datos permanentemente accesibles, se ejecuta en el servidor de la casa: hosts de virtualización, servicios de archivos y bases de datos, aplicaciones especializadas, cercanía a las máquinas y al emplazamiento. Aquí cuenta el tiempo de respuesta, aquí cuenta el control pleno sobre la ubicación física de los datos.
Se replica la capacidad de restauración. Al centro de datos externo no va la operación productiva, sino su aseguramiento: puntos de copia consistentes de las máquinas virtuales y de los datos, como copia replicada fuera de casa, separada geográficamente del original. Con ello, la última copia nunca está solo en un lugar, y la recuperación no depende exactamente del edificio que ha golpeado el incidente.
Que al menos una copia deba residir además de forma inmutable, para que sobreviva a un atacante con privilegios de administrador, es la segunda condición. Cómo funcionan técnicamente la inmutabilidad y la regla ampliada 3-2-1-1-0 lo hemos descrito en detalle en otro lugar; para este modelo operativo basta la máxima: la copia replicada en el centro de datos solo es una verdadera opción de repliegue si no puede borrarse ni modificarse desde la red comprometida.
La verdadera ganancia: recuperación centralizada
Una copia de seguridad fuera de casa es requisito, pero todavía no el valor completo. Lo decisivo es qué ocurre con esa copia en caso de emergencia.
Si la sala de servidores local cae —ya sea por incendio, avería total de hardware o cifrado— los servicios pueden volver a arrancarse de forma centralizada en el centro de datos a partir de la copia replicada, mientras el entorno local se restaura con calma. Esto desacopla dos relojes que de otro modo están inexorablemente acoplados: el tiempo hasta que la operación vuelve a funcionar y el tiempo hasta que la sala de servidores vuelve a estar en pie. Sin este puente, el negocio espera a la reparación del hardware. Con él, los servicios críticos siguen funcionando de forma centralizada, y la restauración local pasa de ser una emergencia a un trabajo planificado.
Justo aquí está la diferencia entre «tenemos un backup» y «volvemos a estar operativos». Un backup que está en la misma sala en llamas no responde a la segunda afirmación.
RTO y RPO: las cifras antes que la técnica
Con qué rapidez y con qué estado de datos debe volver a funcionar un servicio es una decisión de negocio, no técnica. Dos indicadores la hacen discutible:
- RTO (Recovery Time Objective): ¿cuánto tiempo puede estar parado un servicio tras un fallo? ¿Minutos, horas, una jornada laboral?
- RPO (Recovery Point Objective): ¿cuánta pérdida de datos es asumible? ¿El estado de hace una hora, de anoche, del fin de semana?
Estos valores resultan distintos para cada servicio, y ese es el punto en el que el puente híbrido gana su dinero. Un sistema ERP con un RTO de dos horas y un RPO de 15 minutos necesita replicación frecuente y una recuperación preparada en el centro de datos. Un archivo que, asegurado una vez al día, tolera un día de retraso, no lo necesita. Quien aplica a todo el valor más estricto paga por reservas que nadie necesita; quien aplica a todo el más laxo descubre la brecha solo en el incidente. El orden limpio es: primero priorizar los procesos y fijar sus objetivos de RTO/RPO, después dimensionar en consecuencia la frecuencia de replicación y la vía de recuperación.
Y como un plan de recuperación sin prueba es solo una afirmación, al puente híbrido pertenece la emergencia ensayada: las restauraciones se prueban, no se dan por supuestas. El marco estructurado para ello —desde la priorización de procesos hasta el plan de emergencia documentado— pertenece a un concepto de continuidad de negocio bien pensado y no a una corazonada.
Un modelo operativo, no un producto
El atractivo de esta arquitectura reside en que no fuerza nada que la operación no necesite de todos modos. Los servidores están allí donde la latencia y la soberanía de datos lo exigen. El aseguramiento está allí donde un evento de emplazamiento no lo alcanza. Y el reparto no está grabado en piedra: si cambia el requisito —una carga de trabajo se vuelve apta para la nube, otra debe volver a la casa por razones de compliance— la frontera se desplaza sin necesidad de reinventar el modelo. Lo único importante es que la copia replicada y la vía de recuperación centralizada estén planificadas desde el principio y no surjan como un reequipamiento caro tras el primer fallo.
Cómo apoya sector7
Planificamos, adquirimos y operamos servidores, almacenamiento y virtualización directamente en su casa —como partner de HPE a condiciones de partner, y en caso de necesidad justificada también Dell, Fujitsu o sistemas especiales a petición—. El aseguramiento lo implementamos sobre la base de Veeam y lo replicamos a nuestro propio parque de servidores geográficamente redundante en Alemania, para que la última copia nunca esté solo en un lugar y los servicios vuelvan a arrancar de forma centralizada en caso de emergencia, mientras restauramos su entorno en local. Los nuevos sistemas se integran documentados en la supervisión de nuestro NOC las 24 horas. Como casa de gestión propia en Solingen, certificada por el fabricante para Juniper, Cisco, HPE, F5, Fortinet y Palo Alto Networks, unimos cercanía local y centro de datos de una sola mano. Cómo construimos y aseguramos su infraestructura en local lo describimos en nuestra página Servidores y backup en local.