Copias de seguridad y recuperación ante desastres en ayuntamientos: cómo contratar backup y DR
Las copias de seguridad en ayuntamientos son una pieza crítica de continuidad. No basta con tener una tarea programada que indique “backup completado”: la entidad necesita saber qué se copia, cada cuánto, dónde se guarda, cuánto tiempo se conserva y, sobre todo, si puede restaurarse dentro del tiempo que exige el servicio.
El riesgo aumenta cuando conviven gestor de expedientes, sede electrónica, bases de datos, servidores de archivos, aplicaciones a medida, servicios cloud e integraciones. Una estrategia de backup mal diseñada puede dejar fuera justo el componente que hace posible reconstruir un sistema completo.
La contratación debe alinearse con el Esquema Nacional de Seguridad y con la planificación de adecuación ENS del ayuntamiento. También debe integrarse con la ciberseguridad gestionada municipal, porque la recuperación forma parte de la respuesta ante incidentes.
Backup no es lo mismo que continuidad
Una copia de seguridad conserva información para recuperarla. La continuidad define cómo sigue funcionando la organización cuando un servicio falla. La recuperación ante desastres, o disaster recovery, establece cómo volver a levantar sistemas, datos, comunicaciones y dependencias tras una interrupción grave.
Un ayuntamiento puede tener backups correctos y no disponer de un plan de recuperación usable. Si nadie conoce el orden de restauración o las credenciales necesarias, el tiempo real de recuperación puede ser muy superior al esperado.
Por eso el contrato debe unir tecnología, procedimientos y responsables.
Inventario de sistemas que deben protegerse
La primera tarea consiste en identificar servidores, bases de datos, carpetas, aplicaciones, máquinas virtuales, repositorios, configuraciones, certificados, dispositivos y servicios cloud.
Una auditoría tecnológica municipal ayuda a detectar dependencias y activos que no aparecen en inventarios formales.
También es importante incluir configuraciones de red, scripts, automatizaciones y documentación necesaria para reconstruir servicios.
Clasificar por criticidad
No todos los sistemas necesitan el mismo nivel de protección. El gestor de expedientes o la infraestructura de identidad pueden requerir tiempos de recuperación menores que un archivo histórico de consulta ocasional.
La clasificación debe considerar impacto, dependencia de otros procesos, horario de uso y dificultad de reconstrucción.
El resultado permite definir prioridades y evitar sobredimensionar toda la infraestructura.
RPO: cuánto dato puede perderse
El Recovery Point Objective indica cuánto retroceso de información puede aceptar el servicio. Si el RPO es de una hora, la arquitectura debe permitir recuperar una versión con una antigüedad máxima aproximada de ese intervalo.
No conviene asignar RPO arbitrarios. Deben basarse en la frecuencia con que cambian los datos y en el impacto de perderlos.
Una base de datos transaccional puede necesitar una estrategia distinta de un repositorio documental que cambia con menor frecuencia.
RTO: cuánto puede tardar la recuperación
El Recovery Time Objective establece el tiempo máximo objetivo para recuperar el servicio.
El RTO debe incluir restauración, validación, reconfiguración y comprobación de dependencias, no solo el tiempo de copiar archivos desde un backup.
Definir RTO medibles facilita convertir la continuidad en un SLA contractual.
La regla 3-2-1
Una referencia habitual consiste en mantener varias copias de la información, utilizar más de un tipo de soporte y conservar al menos una copia separada del entorno principal.
El objetivo no es cumplir una fórmula de manera literal, sino evitar que un único fallo, ataque o error humano destruya simultáneamente producción y backup.
El pliego debe explicar separación lógica, física o administrativa entre copias.
Copias inmutables
Una copia inmutable no puede modificarse durante un periodo definido. Esta característica resulta especialmente útil frente a ransomware y borrados maliciosos.
La inmutabilidad debe combinarse con separación de credenciales y políticas de retención.
Si el mismo administrador comprometido puede borrar todas las copias, la protección es insuficiente.
Copias offline
Algunos entornos mantienen copias desconectadas o sin acceso permanente desde producción.
Este enfoque puede reducir el riesgo de propagación de ransomware, aunque aumenta complejidad operativa.
El contrato debe valorar frecuencia, automatización y procedimiento de acceso en una emergencia.
Cifrado
Las copias pueden contener información especialmente sensible. Deben protegerse en tránsito y en reposo cuando corresponda.
También es necesario definir quién controla las claves y cómo se recuperan si cambia el proveedor.
Una copia cifrada sin acceso a la clave de recuperación es tan inútil como una copia inexistente.
Backups de bases de datos
Las bases de datos necesitan estrategias consistentes con su tecnología. No siempre basta con copiar los archivos del servidor.
Pueden utilizarse backups completos, incrementales, logs de transacciones o snapshots coordinados según el motor.
Las pruebas deben comprobar que la base restaurada abre correctamente y conserva consistencia.
Gestor de expedientes y documentación
Los expedientes combinan metadatos, documentos, firmas e índices. La estrategia debe proteger todos los componentes necesarios para reconstruirlos.
La guía de migración de gestor de expedientes muestra la importancia de reconciliar documentos y datos al mover sistemas.
Una restauración debe comprobar no solo que aparecen archivos, sino que siguen vinculados al expediente correcto.
Archivos y repositorios documentales
Los servidores de archivos suelen acumular grandes volúmenes y versiones duplicadas. El backup debe adaptarse al patrón de cambio y al valor real de la información.
La guía sobre archivo electrónico único ayuda a distinguir preservación documental y copia operativa.
No todo lo que se conserva a largo plazo debe recuperarse con el mismo RTO.
Aplicaciones a medida
Una aplicación propia necesita algo más que datos. Puede requerir código, variables de entorno, certificados, colas, almacenamiento, dependencias y configuración de despliegue.
La contratación de software a medida debe prever qué activos permiten reconstruir el servicio.
Los repositorios institucionales reducen el riesgo de depender de una única copia gestionada por el proveedor.
Backups en cloud
Los servicios cloud ofrecen herramientas de backup y snapshot, pero la responsabilidad sigue necesitando definición.
La migración a la nube en ayuntamientos debe contemplar retención, regiones, costes y salida del proveedor.
También conviene evitar que las copias dependan exclusivamente de la misma cuenta comprometida que producción.
SaaS y responsabilidad compartida
Utilizar una aplicación SaaS no significa que exista automáticamente una política de backup adecuada a las necesidades municipales.
La entidad debe conocer qué conserva el proveedor, durante cuánto tiempo y qué capacidad de exportación o restauración ofrece.
Para información crítica puede ser recomendable una copia adicional o un mecanismo de exportación independiente.
Microsoft 365 y servicios colaborativos
Correo, archivos compartidos y documentos colaborativos pueden contener información operativa relevante.
El ayuntamiento debe decidir qué datos necesitan backup adicional, retención específica o protección frente a borrado.
Las políticas de la plataforma y las necesidades de continuidad deben revisarse conjuntamente.
Ransomware y copias de seguridad
Un ataque de ransomware suele intentar cifrar producción y destruir o inutilizar backups.
Por eso las copias deben utilizar credenciales separadas, inmutabilidad cuando proceda y monitorización de borrados o cambios anómalos.
El servicio de SOC y ciberseguridad gestionada puede alertar de comportamientos que afecten a repositorios de backup.
Restauraciones periódicas
Una copia no está validada hasta que se restaura. El contrato debe incluir pruebas programadas y evidencias.
Las pruebas pueden realizarse sobre muestras, sistemas completos o escenarios críticos según alcance.
Conviene registrar duración, incidencias y diferencias respecto al RTO previsto.
Pruebas de disaster recovery
La recuperación ante desastres debe ensayarse de extremo a extremo. El ejercicio puede simular pérdida de un servidor, caída de un CPD, corrupción de datos o indisponibilidad de un proveedor.
El objetivo es comprobar orden de recuperación, comunicaciones, dependencias y tiempos.
Después del ejercicio deben actualizarse procedimientos y responsables.
Runbooks de recuperación
Los runbooks describen paso a paso cómo restaurar cada servicio. Deben incluir requisitos previos, credenciales, dependencias, orden, validaciones y contacto con proveedores.
La documentación debe almacenarse en un lugar disponible incluso si el sistema principal está caído.
Una oficina técnica de transformación digital puede coordinar estos procedimientos entre varios adjudicatarios.
Monitorización de backups
El proveedor debe vigilar fallos, capacidad, tiempos y copias incompletas.
No basta con enviar un correo automático que nadie revisa.
El cuadro de mando debería mostrar cobertura, última copia correcta, errores y restauraciones realizadas.
Alertas de capacidad
Los repositorios pueden llenarse por crecimiento de datos o cambios en retención.
El servicio debe anticipar capacidad disponible y evitar fallos silenciosos por falta de espacio.
El coste de almacenamiento también debe incluirse en previsiones presupuestarias.
SLA del servicio
El pliego puede definir tiempos para atender fallos de backup, iniciar restauraciones y recuperar sistemas según criticidad.
Estos tiempos deben relacionarse con RPO y RTO.
La guía sobre mantenimiento de software municipal ofrece criterios complementarios para estructurar SLA.
Responsabilidades
Cuando intervienen proveedor cloud, mantenedor, fabricante y equipo municipal debe quedar claro quién copia, quién supervisa y quién restaura.
Las zonas grises suelen aparecer precisamente durante una emergencia.
El contrato debe asignar responsables por componente y canal de escalado.
Protección de credenciales
Las cuentas de backup suelen tener privilegios elevados. Deben protegerse con mínimo privilegio, MFA y separación respecto a cuentas de uso diario.
También conviene limitar quién puede borrar repositorios o reducir retención.
Los cambios críticos deberían quedar registrados.
Retención
La retención debe ajustarse a necesidades operativas, legales y de capacidad. Conservar todo indefinidamente puede elevar costes y riesgos.
El ayuntamiento debe diferenciar recuperación a corto plazo, históricos y conservación documental.
La política debe quedar documentada por sistema.
Borrado y fin de vida
Cuando se retira un sistema o termina un contrato, hay que decidir qué ocurre con sus copias.
El proveedor debe poder certificar eliminación cuando corresponda y entregar información que deba conservar la entidad.
La reversibilidad forma parte de la continuidad.
Plan de recuperación ante desastres
El DR plan debe contener escenarios, responsables, contactos, orden de recuperación, infraestructura alternativa y criterios de retorno a normalidad.
No debería ser un documento estático. Debe actualizarse cuando cambian aplicaciones o proveedores.
La integración de sistemas municipales obliga a revisar dependencias antes de cada ejercicio.
Escenario de caída total
El ayuntamiento debería saber qué haría si pierde acceso al CPD, a la red principal o a un proveedor clave.
La recuperación puede requerir infraestructura alternativa, prioridades por fases y procedimientos manuales temporales.
El ejercicio ayuda a detectar componentes olvidados antes de una emergencia real.
Escenario de corrupción de datos
No todos los desastres son indisponibilidad total. Una actualización defectuosa o error humano puede corromper información sin detener el sistema.
Las copias deben permitir volver a un punto anterior y comparar qué cambios se perderán.
La reconciliación posterior debe documentarse.
Escenario de pérdida de credenciales
También debe contemplarse la indisponibilidad o compromiso de cuentas administrativas.
Las credenciales de emergencia deben protegerse y probarse.
El objetivo es evitar que toda la capacidad de recuperación dependa de una única identidad.
Cómo preparar el pliego
El pliego debe definir sistemas incluidos, RPO, RTO, retención, cifrado, inmutabilidad, monitorización, restauraciones, pruebas de DR, SLA y reversibilidad.
La guía de pliego técnico municipal ayuda a convertir estos requisitos en entregables verificables.
También debe incluir qué infraestructura aporta cada parte y cómo se controlarán costes.
Criterios técnicos de adjudicación
Puede valorarse arquitectura, separación de copias, automatización, monitorización, pruebas, seguridad, metodología de DR y transferencia de conocimiento.
La propuesta debe demostrar capacidad para recuperar, no solo para almacenar.
Solicitar evidencias de pruebas y un ejemplo de runbook puede ser más útil que una descripción comercial.
Qué puede aportar BlackHold Consulting
La continuidad requiere conectar infraestructura, aplicaciones y procesos. BlackHold Consulting trabaja en digitalización e integración de procesos, automatización de procesos, automatización administrativa y gestión documental automatizada.
También dispone de capacidades en procesos tecnológicos complejos, consultoría tecnológica, agentes e integraciones y servicios de automatización. En un proyecto público estas capacidades pueden complementar backup, monitorización, integración y recuperación mediante el procedimiento contractual correspondiente.
Checklist antes de contratar backup y DR
Inventario
¿Está claro qué sistemas y datos se protegen?
RPO
¿Se ha definido cuánto dato puede perderse?
RTO
¿Se conoce cuánto puede tardar cada recuperación?
Inmutabilidad
¿Las copias resisten borrado o ransomware?
Restauración
¿Se prueban periódicamente?
Monitorización
¿Alguien revisa fallos y capacidad?
DR
¿Existe un plan de recuperación completo?
Salida
¿La entidad puede recuperar sus datos si cambia de proveedor?
Preguntas frecuentes
RPO indica cuánto dato puede perderse; RTO, cuánto tiempo puede tardar la recuperación.
No necesariamente. Debe analizarse separación, retención, credenciales, inmutabilidad y capacidad de restauración.
Depende de criticidad y arquitectura, pero conviene evitar cualquier diseño en el que un único fallo pueda destruir producción y todas las copias.
Sí. Una copia no puede considerarse fiable si nunca se ha recuperado.
Escenarios, responsables, orden de recuperación, dependencias, infraestructura alternativa, comunicaciones y criterios de retorno a normalidad.
No. El backup busca recuperación operativa; el archivo responde a conservación y gestión documental.
Conclusión
Las copias de seguridad municipales deben diseñarse desde la recuperación, no desde el almacenamiento. RPO, RTO, inmutabilidad, monitorización y pruebas convierten un backup técnico en una verdadera capacidad de continuidad.
El ayuntamiento debe saber qué ocurre si pierde una base de datos, un servidor, un proveedor o una sede completa. Esa respuesta debe estar documentada y probada antes de necesitarla.
Un servicio bien contratado permite reducir tiempos de parada, proteger datos frente a ransomware y mantener control sobre la recuperación incluso cuando cambian aplicaciones, infraestructura o proveedores.
La continuidad del servicio no depende solo del backup: un software mal mantenido también es un punto de fallo. BlackHold Consulting explica cómo un plan de mantenimiento evolutivo reduce ese riesgo en el sector privado.
Fotografía: Jakub Zerdzicki / Pexels.
