Copias de seguridad 3-2-1 para empresas: cómo diseñarlas y probarlas

1. Traduce la regla 3-2-1 a tu operación

La copia principal es la información con la que la empresa trabaja cada día. Las otras dos son respaldos independientes. Mantenerlas en dos medios o sistemas diferentes reduce la posibilidad de que el mismo defecto, error de configuración o incidente afecte a todas. Al menos una debe estar fuera de la sede o del entorno principal para sobrevivir a robo, incendio, daño eléctrico o indisponibilidad del proveedor.

La regla es un punto de partida, no un producto ni una garantía automática. Una sincronización en la nube puede replicar de inmediato un borrado accidental; un disco externo conectado permanentemente puede quedar cifrado junto con el equipo; dos servicios administrados desde la misma cuenta pueden perderse si esa identidad es comprometida. Diseña independencia técnica y administrativa, además de contar copias.

• Copia de trabajo en el sistema que usa el equipo.
• Primer respaldo en un repositorio administrado y supervisado.
• Segundo respaldo en otro medio, cuenta o tecnología.
• Una copia fuera de la ubicación principal y aislada cuando no se utiliza.
• Responsables distintos para operación, revisión y recuperación cuando sea viable.

Sincronizar ayuda a trabajar entre dispositivos; respaldar permite volver a un estado anterior. Son funciones distintas y deben evaluarse por separado.

2. Decide qué respaldar y cuánto puedes perder

Empieza por procesos: ventas, expedientes, inventario, facturación, diseños, correo, archivos compartidos o configuraciones. Para cada uno identifica la fuente oficial y todas sus dependencias. Respaldar documentos sin conservar la base de datos, las claves de cifrado, la configuración de la aplicación o las instrucciones de reconstrucción puede dejar un conjunto de archivos imposible de usar.

Define cuánto trabajo reciente puede perderse y cuánto tiempo puede permanecer detenido el proceso. Una carpeta que cambia una vez por semana no necesita la misma frecuencia que una base transaccional. También define retención: conservar únicamente la última versión puede ser insuficiente si el daño se descubre días después. Las decisiones deben reflejar impacto operativo y obligaciones aplicables, no una frecuencia genérica.

• Propietario del dato y sistema que contiene la versión oficial.
• Frecuencia de cambio y pérdida máxima tolerable.
• Orden de recuperación entre aplicaciones y departamentos.
• Versiones que deben conservarse y durante cuánto tiempo.
• Dependencias como licencias, certificados, claves y documentación.

3. Diseña copias con fallas independientes

Combina tecnologías según el riesgo. Un repositorio local puede permitir restauraciones rápidas; un servicio remoto protege frente a una pérdida física; una copia desconectada o inmutable dificulta que un atacante la altere. No necesitas la misma combinación para todo, pero sí debes poder explicar qué amenaza cubre cada capa y quién la mantiene.

Revisa el camino completo de acceso. Si todas las copias se administran con la misma contraseña o una sola cuenta privilegiada, la diversidad de medios no resuelve el riesgo de identidad. Usa cuentas individuales, autenticación multifactor, mínimo privilegio y alertas de cambios. Separa las credenciales de emergencia y documenta cómo recuperarlas sin dejarlas expuestas junto al equipo.

• Cifrado durante transferencia y almacenamiento cuando corresponda.
• Restricciones para borrar, reducir retención o desactivar tareas.
• Alertas enviadas a más de una persona responsable.
• Capacidad suficiente y crecimiento supervisado.
• Contrato y procedimiento de exportación para servicios externos.

Una copia “en la nube” no está aislada si el mismo usuario comprometido puede localizarla y borrarla desde el panel administrativo.

4. Automatiza sin dejar de supervisar

Las tareas manuales se olvidan precisamente cuando el equipo está ocupado. Automatiza horarios, verificación de integridad, rotación y alertas, pero asigna una persona que revise resultados. “Finalizado” no siempre significa “completo”: una tarea puede copiar una carpeta vacía, omitir un origen nuevo, quedarse sin espacio o autenticarse con una cuenta que perdió permisos.

Mantén un tablero pequeño con la última ejecución exitosa, volumen esperado, errores abiertos y fecha de la última restauración. Cuando se incorpora una aplicación, sede o persona clave, actualiza el alcance. Cuando se retira un sistema, conserva los datos según la política definida y elimina accesos de forma controlada. El inventario y el respaldo deben cambiar juntos.

• Revisa fallas y advertencias, no sólo el color general del panel.
• Compara el volumen respaldado con una referencia razonable.
• Prueba alertas para confirmar que llegan al responsable correcto.
• Registra cambios de configuración, retención y destinos.
• Incluye equipos portátiles y servicios SaaS expresamente.

5. Prueba restauraciones de menor a mayor

Empieza recuperando un archivo y verificando contenido, nombre, fecha y permisos. Continúa con una carpeta, una base de datos o una aplicación en un entorno seguro. Una prueba completa debe demostrar que el equipo conoce el orden de los pasos, que las credenciales están disponibles, que la versión recuperada abre correctamente y que el tiempo observado es compatible con la operación.

No restaures sobre producción como primer ensayo. Usa un destino aislado y controla que la prueba no envíe correos, procese pagos o sobrescriba información real. Documenta el resultado, los obstáculos y las decisiones. Si la recuperación depende de un proveedor, involúcralo en el ejercicio y confirma qué soporte incluye el contrato durante una emergencia.

• Archivo individual eliminado por error.
• Carpeta compartida con versiones anteriores.
• Aplicación con base de datos y configuración.
• Equipo nuevo que debe reconstruirse desde cero.
• Pérdida simulada del repositorio o cuenta principal.

Registra dos fechas: la última copia exitosa y la última restauración verificada. Una no sustituye a la otra.

6. Recupera con seguridad durante un incidente

Ante ransomware o una intrusión, no conectes inmediatamente todos los respaldos al entorno afectado. Aísla sistemas según el plan de respuesta, conserva evidencia y determina un punto de recuperación conocido como seguro. Restaurar datos sobre equipos que siguen comprometidos puede reiniciar el problema o contaminar la copia que todavía estaba protegida.

Define quién autoriza la restauración, quién valida el sistema y quién comunica el estado. Prioriza servicios según el mapa de procesos, cambia credenciales comprometidas y aplica correcciones antes de reabrir accesos. Al cerrar el incidente, incorpora lo aprendido: quizá necesites mayor aislamiento, más retención, otra frecuencia o un método de reconstrucción más rápido.

• Preserva la copia aislada hasta entender el alcance.
• Valida integridad y fecha antes de restaurar.
• Recupera primero identidades, red y dependencias esenciales.
• Supervisa actividad anómala después de volver a producción.
• Actualiza el plan con tiempos y problemas reales.