Una copia de seguridad no es una garantía por el solo hecho de existir. Si nadie sabe qué contiene, si se puede borrar desde una cuenta comprometida o si nunca se restauró, puede fallar justo cuando más se la necesita.
El objetivo no es acumular archivos duplicados. Es poder restablecer información y servicios importantes dentro de un tiempo aceptable después de un ransomware, un error humano, una falla técnica o una eliminación accidental.
Un backup no se mide por cuánto espacio ocupa: se mide por la capacidad comprobada de volver a operar.
La guía #StopRansomware de CISA recomienda mantener respaldos críticos cifrados, fuera de línea y probados de forma periódica. También advierte que muchas variantes de ransomware intentan localizar, borrar o cifrar las copias a las que todavía pueden acceder. Por eso, la recuperación debe diseñarse como parte de la seguridad y no como una tarea técnica aislada.
1. Empezá por decidir qué necesitás recuperar primero
No todos los datos tienen la misma urgencia. Antes de elegir frecuencias o almacenamiento, hacé un inventario breve de los recursos que sostienen la operación.
- Datos operativos: clientes, pedidos, facturación, agenda, inventario, documentos o registros de producción.
- Sistemas y configuraciones: base de datos, aplicación, usuarios, permisos, integraciones y parámetros relevantes.
- Activos web: contenidos, formularios, archivos multimedia, configuraciones y datos recibidos desde el sitio.
- Material para reconstruir: código fuente, instaladores, licencias, documentación técnica y procedimientos.
Para cada elemento, definí dos respuestas concretas:
- ¿Cuánto tiempo puede estar inaccesible? Por ejemplo: una hora, un día hábil o varios días.
- ¿Cuánta información reciente se puede perder sin causar un daño inaceptable? Por ejemplo: los cambios de la última hora, del día o de la semana.
Estas decisiones convierten una conversación vaga sobre “hacer backup” en prioridades operativas. NIST recomienda evaluar sistemas y operaciones para determinar sus requisitos y prioridades de contingencia; ese criterio evita dedicar el mismo esfuerzo a información crítica y a archivos prescindibles.
2. Diseñá capas de respaldo, no un único punto de falla
Guardar una sola copia en el mismo equipo, servidor o cuenta que se quiere proteger no resuelve un incidente grave. Una estrategia razonable separa las copias para que un problema no las afecte a todas a la vez.
Una estructura práctica
- Copia de trabajo: los datos y sistemas que usa la operación todos los días.
- Copia de recuperación rápida: un respaldo reciente que permita restaurar con agilidad errores habituales o pérdidas puntuales.
- Copia separada: un respaldo almacenado en otra ubicación, cuenta o entorno con controles distintos.
- Versiones históricas: varias versiones para volver a un punto anterior si el problema pasó inadvertido durante días.
No hace falta aplicar la misma combinación a todo. Una base de datos que cambia constantemente puede requerir copias más frecuentes que un repositorio de imágenes institucionales. Lo importante es que la frecuencia responda a la pérdida de información que la organización está dispuesta a asumir.
3. Protegé el backup como un activo crítico
Un respaldo expuesto a las mismas credenciales y permisos que el entorno principal puede ser alterado por un atacante o por un error administrativo. CISA aconseja que los backups sean cifrados, estén fuera de línea o separados del entorno habitual y se prueben regularmente.
En la práctica, revisá estas medidas:
- Usar cuentas específicas para administración de backups, no cuentas personales compartidas.
- Aplicar autenticación multifactor donde esté disponible.
- Limitar quién puede eliminar copias, cambiar retenciones o modificar la configuración.
- Separar los permisos de lectura, restauración y eliminación cuando la herramienta lo permita.
- Activar protección contra borrado o sobrescritura y conservar versiones, si el proveedor la ofrece.
- Cifrar la información tanto durante la transferencia como en el almacenamiento.
- Guardar de forma segura las claves, credenciales y documentación necesarias para restaurar.
“Fuera de línea” no siempre significa desconectar un disco manualmente. Puede implicar una copia que no es accesible de forma permanente desde los sistemas de producción. La decisión técnica depende de la infraestructura, pero el principio es estable: comprometer el entorno principal no debería dar acceso automático a destruir todas las copias.
4. Documentá el procedimiento de restauración antes del incidente
Un archivo disponible no equivale a un servicio recuperado. Para volver a operar quizá sea necesario restaurar una base de datos en un orden determinado, recrear usuarios, volver a conectar una integración, validar permisos o cambiar configuraciones de DNS y correo.
Creá una ficha breve por sistema crítico con:
- responsable principal y reemplazo;
- ubicación exacta de las copias y método de acceso;
- credenciales o proceso seguro para obtenerlas;
- orden de restauración de componentes y dependencias;
- tiempo objetivo para una primera recuperación funcional;
- validaciones posteriores: acceso, datos, formularios, pagos, reportes o integraciones;
- canal para comunicar avances a las personas afectadas.
El NIST SP 800-34 Rev. 1 trata la contingencia como una combinación de procedimientos, estrategias de recuperación, pruebas, capacitación y mantenimiento. Es una buena advertencia: la tecnología sin responsables y sin pasos claros deja demasiadas decisiones para un momento de presión.
5. Probá una restauración real y registrá el resultado
La única manera de saber si un backup sirve es restaurar una copia en un entorno controlado. No alcanza con comprobar que una tarea terminó sin errores o que un panel muestra un indicador verde.
Qué debería incluir una prueba útil
- Elegir un sistema o conjunto de archivos con prioridad definida.
- Restaurar desde una copia concreta, sin usar datos del entorno original para completar lo que falte.
- Medir cuánto demora el proceso y comparar ese tiempo con el objetivo previsto.
- Verificar integridad y utilidad: abrir archivos, consultar registros, iniciar sesión, procesar una operación de prueba o revisar integraciones.
- Anotar fallas, pasos manuales inesperados, permisos faltantes y decisiones pendientes.
- Actualizar el procedimiento y repetir la prueba cuando cambie la infraestructura.
NIST señala que las pruebas son críticas para identificar deficiencias y validar tanto componentes del sistema como procedimientos de recuperación. Una prueba pequeña y recurrente suele aportar más aprendizaje que un plan extenso que nunca se ejecuta.
6. Convertí el backup en una rutina de gestión
Las copias de seguridad se degradan cuando cambian las herramientas, se incorporan nuevos sistemas, vence una suscripción o una persona deja de tener acceso. Reservá una revisión periódica para confirmar que el alcance sigue siendo correcto.
Como mínimo, verificá:
- qué sistemas nuevos o datos nuevos deben incluirse;
- si las copias terminan correctamente y dentro de la frecuencia acordada;
- si existen alertas de fallas que nadie está atendiendo;
- si las cuentas y permisos siguen asignados a personas autorizadas;
- si la retención cubre el tiempo necesario para detectar un incidente;
- si la documentación de restauración coincide con la operación actual;
- cuándo fue la última prueba y qué mejoras quedaron abiertas.
El Cybersecurity Framework de NIST sitúa la recuperación dentro de una gestión continua del riesgo: recuperar no es volver exactamente al estado anterior, sino restablecer capacidades y aprender del evento para mejorar la resiliencia.
Conclusión: definí una recuperación que puedas demostrar
Un buen sistema de backups tiene prioridades claras, copias separadas del entorno principal, controles de acceso, versiones suficientes y un proceso de restauración que ya fue probado. Empezá esta semana con un ejercicio concreto: elegí un activo crítico, intentá restaurarlo en un entorno seguro y anotá cada obstáculo. Ese resultado te mostrará con precisión qué mejorar antes de una emergencia.
