Copia De Seguridad En La Nube: Guía Para Empresas

Hay una conversación que se repite en cada incidente de ransomware: la empresa está convencida de tener copias de seguridad, y cuando llega el momento de restaurar descubre que estaban cifradas, que llevaban meses fallando en silencio o que nadie había probado nunca a recuperarlas.

Tener copia de seguridad en la nube no es lo mismo que tener una estrategia de respaldo. Esta guía repasa qué hace falta para que las copias sirvan el día que se necesiten.

Sincronizar no es hacer copia de seguridad

Es el malentendido más extendido y el que más disgustos causa. Herramientas como OneDrive, Google Drive o Dropbox son servicios de sincronización, no de copia de seguridad. Su función es que el mismo archivo esté disponible en varios dispositivos.

La diferencia es crítica: si un ransomware cifra los archivos de un equipo sincronizado, la carpeta en la nube replica el cifrado en cuestión de segundos. Si alguien borra una carpeta por error, se borra en todas partes. La sincronización propaga los cambios, sean deseados o no.

Una copia de seguridad real es independiente del sistema original, guarda versiones anteriores en el tiempo y no puede ser modificada por lo que ocurra en producción. Los servicios de sincronización ofrecen papelera y versiones, pero con retenciones limitadas y sin control real por parte de la empresa.

La regla 3-2-1, y por qué ya se queda corta

La regla clásica establece tres condiciones:

3 copias de los datos: la original y dos respaldos.
2 tipos de soporte distintos, para que un fallo de tecnología no afecte a ambos.
1 copia fuera de las instalaciones, que sobreviva a un incendio, una inundación o un robo.

Sigue siendo un buen punto de partida, pero se diseñó pensando en fallos de hardware y desastres físicos, no en un atacante que busca activamente destruir las copias. De ahí que se haya extendido a 3-2-1-1-0, con dos condiciones nuevas:

1 copia inmutable, que no pueda alterarse ni borrarse durante un periodo definido.
0 errores en las verificaciones de restauración.

Esos dos añadidos son precisamente los que marcan la diferencia entre recuperarse de un ataque y no poder hacerlo.

Qué es un backup inmutable

Una copia inmutable es aquella que, una vez escrita, no puede modificarse ni eliminarse hasta que expire su periodo de retención. Ni por un atacante, ni por un administrador, ni por el propio administrador de la cuenta.

Es la respuesta directa a cómo opera el ransomware moderno. Los grupos de doble extorsión no cifran y ya está: primero localizan las copias de seguridad, las borran o las cifran, y solo entonces lanzan el ataque sobre los sistemas de producción. Saben que una empresa con copias intactas no paga.

Las tecnologías cloud implementan la inmutabilidad mediante bloqueo de objetos. En almacenamiento tipo S3 existe el Object Lock, con un modo de cumplimiento en el que ni siquiera la cuenta raíz puede eliminar los datos antes de tiempo. Azure ofrece almacenamiento inmutable con políticas de retención basadas en tiempo bajo el principio de escribir una vez y leer muchas.

RPO y RTO: las dos cifras que definen la estrategia

Antes de elegir tecnología hay que responder a dos preguntas de negocio, no técnicas:

RPO, punto objetivo de recuperación. Cuántos datos puede permitirse perder la empresa, medido en tiempo. Si el RPO es de 24 horas, basta con una copia diaria. Si es de una hora, hacen falta copias mucho más frecuentes o replicación continua.

RTO, tiempo objetivo de recuperación. Cuánto puede estar la empresa parada. No es lo mismo un sistema que puede esperar dos días que un ERP cuya caída detiene la facturación.

Estas dos cifras las fija la dirección, no el departamento de IT, porque son decisiones sobre riesgo asumible. Y no tienen por qué ser iguales para todos los sistemas: lo normal es clasificar los servicios por criticidad y asignar objetivos distintos, porque proteger todo al máximo nivel es innecesario.

Tipos de copia

Completa. Copia todo cada vez. Es la más simple de restaurar y la que más espacio y tiempo consume.
Incremental. Copia solo lo cambiado desde la última copia, sea del tipo que sea. Es rápida y ligera, pero restaurar exige la copia completa más toda la cadena de incrementales posterior.
Diferencial. Copia lo cambiado desde la última copia completa. Ocupa más que la incremental, pero restaurar solo requiere dos elementos: la completa y la última diferencial.

Lo habitual es combinarlas: una copia completa periódica con incrementales entre medias, ajustando la frecuencia al RPO definido.

Lo que casi nadie hace: probar la restauración

Este es el punto donde falla la mayoría de las estrategias, y merece decirlo sin rodeos: una copia que no se ha restaurado nunca no es una copia, es una suposición.

Los trabajos de backup pueden estar marcándose como correctos durante meses mientras respaldan una carpeta equivocada, omiten una base de datos que quedó fuera del alcance o generan archivos corruptos que solo se detectan al intentar abrirlos.

Una prueba de restauración seria implica recuperar de verdad en un entorno aislado, verificar que los datos están íntegros y que la aplicación arranca, y cronometrar cuánto se ha tardado para contrastarlo con el RTO comprometido. Conviene hacerlo de forma periódica y documentada, y probar también la restauración completa de un servidor, no solo de ficheros sueltos.

Checklist de una estrategia razonable

Al menos tres copias, en dos soportes, con una fuera de las instalaciones.
Una copia inmutable con retención acorde al tiempo que puede tardarse en detectar un ataque.
RPO y RTO definidos por servicio y aprobados por dirección.
Credenciales de la plataforma de backup separadas del directorio corporativo, para que comprometer el dominio no dé acceso a las copias.
Cifrado de los datos en tránsito y en reposo.
Alertas activas ante trabajos fallidos, revisadas por alguien concreto.
Pruebas de restauración periódicas y documentadas.
Cobertura explícita de los servicios SaaS. Microsoft 365 y Google Workspace replican tus datos, pero no los respaldan frente a un borrado o un cifrado: esa responsabilidad es del cliente.

Ese último punto sorprende a muchas empresas. El modelo de responsabilidad compartida de los grandes proveedores cloud cubre la disponibilidad de la infraestructura, no la recuperación de tus datos ante un error humano o un ataque.

Cada infraestructura tiene su propio punto de partida y sus propias restricciones. Si quieres valorar cómo aplicar esto en tu organización, escríbenos y lo revisamos sobre tu caso concreto.