Respaldos listos para el ransomware: la regla 3-2-1-1-0 para sistemas de negocio

Esta es una escena inventada, no un cliente real. Es viernes, 4:40 p. m. La dueña de una tienda en línea de 15 personas le pide a su contratista de TI que restaure el respaldo de anoche en un servidor de repuesto, algo que nadie ha hecho en dos años. Se supone que es un trámite: el panel de respaldos muestra una palomita verde cada mañana desde enero.

La restauración termina en once minutos y la tabla de pedidos está vacía. Desde que el disco se llenó en marzo, la tarea nocturna escribía un volcado truncado y aun así reportaba éxito, porque nadie revisaba su código de salida. Cada palomita era cierta: la tarea se ejecutó. Lo que nadie preguntó fue si el archivo se podía abrir.

Un respaldo que nunca has restaurado es una suposición, y el ransomware convierte esa suposición en pérdida. El atacante con credenciales de administrador busca tus respaldos antes de cifrar nada, así que la regla de siempre, tres copias en dos tipos de medios y una fuera del sitio, ya no alcanza. La versión actual suma dos números, y son más importantes que los tres primeros.

En el resto del artículo verás por qué las empresas pequeñas están en la mira, qué significa 3-2-1-1-0 en la práctica, cómo definir metas de recuperación para cada sistema, qué respaldar en una aplicación de negocio y cómo ensayar el día en que todo falle.

Por qué las empresas pequeñas son el blanco

Los atacantes no eligen a sus víctimas por la marca. Escanean en busca de accesos expuestos, equipos de red sin parchar y contraseñas repetidas, y después revisan qué cayó en la red. Las empresas pequeñas tienen las mismas debilidades que las grandes, pero muchas menos personas para notar el problema.

Las cifras lo confirman. El Informe de Investigaciones de Violación de Datos 2025 de Verizon encontró ransomware en el 44 % de las brechas analizadas, frente al 32 % del año anterior. En las pymes la proporción fue mucho mayor: el 88 % de las brechas involucró ransomware, contra el 39 % en las grandes organizaciones. El mismo informe halló que el 64 % de las víctimas no pagó y que la mediana de los pagos bajó a unos 115,000 dólares.

Esta última cifra es a la vez una buena noticia y una advertencia. Menos víctimas pagan porque más pueden restaurar. El informe State of Ransomware 2026 de Sophos, una encuesta a 2,158 responsables de TI y seguridad de organizaciones afectadas, encontró que el 66 % de quienes sufrieron cifrado de datos los recuperó desde respaldos, 12 puntos más que el año anterior. Aun así, la factura típica de recuperación llegó a 1.7 millones de dólares.

Los atacantes saben que los respaldos deciden el resultado, así que van primero por ellos. Una investigación anterior de Sophos halló que intentaron comprometer los respaldos del 94 % de las organizaciones que atacaron, y lo lograron en el 57 % de esos intentos. Donde lo lograron, las víctimas tenían casi el doble de probabilidad de pagar el rescate y enfrentaron una factura de recuperación unas ocho veces mayor. Un respaldo al que el atacante puede llegar no es un respaldo: es otro objetivo.

De 3-2-1 a 3-2-1-1-0

La regla clásica es sencilla: guarda 3 copias de tus datos, en 2 tipos de almacenamiento distintos, con 1 copia fuera del sitio. Sigue funcionando contra fallas de hardware, robo e incendio. Frente a un intruso decidido tiene un hueco, porque las tres copias suelen ser accesibles con las mismas credenciales.

La regla moderna agrega dos requisitos:

• 1 copia inmutable o fuera de línea. Una copia que nadie puede modificar ni borrar hasta que termine su periodo de retención: ni tus propios administradores ni el atacante que tenga sus contraseñas.
• 0 errores. Un respaldo solo cuenta si su prueba de restauración terminó sin errores. Mientras no pase una prueba de restauración, es solo una esperanza.

Puedes cumplir la regla con recursos modestos. La base de datos en producción es la copia uno. Un volcado nocturno en otro disco o servidor es la copia dos. La tercera va a un almacenamiento de objetos de otro proveedor, escrita con credenciales que pueden agregar archivos pero no borrarlos, y con un bloqueo de retención activado. Esa tercera copia cubre a la vez el requisito de estar fuera del sitio y el de ser inmutable.

Inmutabilidad, en palabras simples

Una copia inmutable se escribe una sola vez: cuando el archivo queda guardado, el propio servicio de almacenamiento se niega a modificarlo o borrarlo hasta la fecha que elegiste. Amazon S3 llama a esto Object Lock, y varios almacenamientos compatibles con S3 ofrecen la misma función con el mismo nombre. Tiene dos modos, y la diferencia importa.

• Modo Compliance. Nadie puede borrar ni sobrescribir una versión bloqueada antes de la fecha de retención, ni siquiera el usuario root de la cuenta, y el plazo no se puede acortar.
• Modo Governance. La mayoría de los usuarios no puede borrar el objeto, pero quien tenga un permiso especial puede saltarse el bloqueo. Es mejor que nada y más débil que el modo compliance, porque un atacante con el permiso adecuado también puede usarlo.

Los detalles están en la documentación de S3 Object Lock. Uses el proveedor que uses, revisa tres cosas antes de confiar en él: que el versionado esté activo, que el modo de bloqueo sea compliance (o que el permiso para saltarlo lo tenga alguien que no sea administrador de todos los días) y que la retención sea más larga que el tiempo que tardarías en notar un ataque. Una intrusión puede pasar semanas sin que nadie la note.

Si no tienes Object Lock, una copia fuera de línea cumple la misma función: un disco externo o una cinta que queda desconectada físicamente entre una ejecución y otra, o un servidor de respaldos que jala los datos por su cuenta, de modo que el sistema de producción no guarda ninguna credencial para llegar a ellos.

Define metas de recuperación por sistema

Cada decisión de respaldo depende de dos números. El RPO (objetivo de punto de recuperación) es cuántos datos recientes puedes permitirte perder, medido en tiempo. El RTO (objetivo de tiempo de recuperación) es cuánto tiempo puedes permitirte estar caído. Son decisiones de negocio antes que ajustes técnicos, y cambian según el sistema.

Los pedidos son el caso más claro. Una tienda en línea que recibe cien pedidos por hora no puede perder un día de ellos, porque a los clientes ya se les cobró y no queda nada contra qué conciliar. Una carpeta compartida con folletos viejos puede esperar una semana. Fija las metas preguntándote cuánto cuesta cada hora de pérdida o de caída.

Nivel	Ejemplos	RPO meta	RTO meta	Método
Nivel 1: dinero en movimiento	Pedidos, pagos, libro de inventario, contabilidad	5–15 minutos	1–4 horas	Envío continuo de registros o volcados incrementales frecuentes, más una copia completa inmutable cada día
Nivel 2: operación diaria	Clientes, RR. HH. y nómina, registros de proveedores, archivos subidos	24 horas	8–24 horas	Instantánea nocturna a almacenamiento fuera del sitio con bloqueo de retención
Nivel 3: archivos de trabajo	Documentos, exportaciones, reportes, biblioteca de medios	24 horas	2–3 días	Almacenamiento de objetos con versiones y protección contra borrado
Nivel 4: archivo histórico	Facturas antiguas, ejercicios cerrados, registros legales	1 semana	1 semana	Copia inmutable mensual, retención larga, cifrada

Estas cifras son puntos de partida ilustrativos, no estándares. Las tuyas deben salir del costo de tu propia caída. Lo importante es que cada sistema tenga un nivel y que ese nivel esté por escrito.

Qué respaldar en una aplicación de negocio

El volcado de la base de datos es lo primero en lo que todos piensan y casi nunca basta por sí solo. Si alguna vez restauraste un sistema y no arrancó, lo más probable es que faltara alguno de estos elementos.

• La base de datos. Haz un volcado o una instantánea consistente, no una copia de los archivos de datos en uso, y guarda con ella la versión de las migraciones del esquema.
• Los archivos subidos. Fotos de productos, facturas, adjuntos y documentos suelen vivir fuera de la base de datos. Una base restaurada sin sus archivos deja enlaces rotos por todas partes.
• La configuración. Archivos de entorno, definiciones de tareas programadas, configuración del servidor y del proxy, ajustes de pagos y de paquetería.
• Secretos y llaves. Llaves de la aplicación, de cifrado y de firma. Sin la llave de la aplicación, las columnas cifradas de un respaldo perfecto de la base de datos no se pueden leer. Guárdalas aparte de los datos que protegen.
• Licencias e integraciones. Archivos de licencia, secretos de webhook, credenciales de API y registros de dominio y DNS. Reconstruirlos bajo presión toma horas.
• La receta misma. Un documento corto que diga qué versión del software, qué imagen de servidor y qué pasos reconstruyen el sistema desde cero.

Cifra cada copia antes de que salga de tu red y guarda las llaves de cifrado donde el almacenamiento de respaldos no pueda alcanzarlas. Un respaldo robado es una filtración de datos, y en muchas jurisdicciones una que hay que notificar.

Mantén las llaves separadas

El punto débil suele ser la separación, no la tecnología. Cuatro reglas cubren casi todo:

1. Usa una cuenta separada con el proveedor de almacenamiento para la copia inmutable, de preferencia con otro usuario propietario y su propia autenticación multifactor.
2. Dale al servidor de producción credenciales de solo escritura: puede agregar respaldos y nada más. No puede listar, leer, modificar ni borrar.
3. Mantén las credenciales de administrador del almacenamiento de respaldos fuera del gestor de contraseñas y del inicio de sesión único, a los que los atacantes llegan a través de una laptop comprometida.
4. Configura alertas sobre eventos de respaldo: una tarea que falla, un intento de borrado, un cambio de retención o un día completo sin ningún respaldo nuevo.

Retención: qué tan atrás conviene guardar

Conservar solo el respaldo de anoche es peligroso, porque una intrusión silenciosa puede tener semanas y la copia de anoche quizá ya contenga el daño. Un esquema práctico para la mayoría de las pymes es guardar copias diarias por 30 días, semanales por tres meses y mensuales por un año, o lo que exijan tu contador y la ley local. El almacenamiento es barato frente a una factura de recuperación.

La retención también te protege de ti mismo. Alguien borra el catálogo de productos por error, alguien importa la hoja de cálculo equivocada, un bug corrompe los precios de todo un mes. Con un historial de puntos de restauración, esos incidentes dejan de ser desastres y se vuelven una tarde de trabajo.

Los simulacros de restauración van en el calendario

El último "0" de 3-2-1-1-0 es el que casi todos los equipos se saltan. De un respaldo que nunca se ha restaurado no se sabe si funciona. Los archivos pueden estar vacíos, la llave puede haberse perdido, la restauración puede tardar 30 horas en lugar de tres. Mejor enterarte un martes tranquilo.

Empieza con poco y hazlo rutina. Cada semana, restaura automáticamente el respaldo más reciente de la base de datos en un entorno desechable y ejecuta algunas consultas de verificación. Cada mes, restaura un conjunto de archivos y abre varios. Cada trimestre, reconstruye un sistema completo en un servidor limpio y mide el tiempo. Una vez al año, haz un ejercicio de escritorio como si el servidor principal se hubiera perdido y nadie pudiera entrar al anterior.

Anota cada resultado: fecha, qué restauraste, cuánto tardó y qué salió mal. Si un simulacro tarda más que el RTO que prometiste, cambia el plan o cambia la promesa. Un planificador de tareas que toma instantáneas, aplica la retención y restaura en un entorno limpio con un solo paso abarata mucho los simulacros. El recorrido corto de abajo muestra un ejemplo autoalojado, el módulo Backups de StoreConsole, ejecutando justo este ciclo.

Un manual de incidentes de una página

El orden de las primeras decisiones importa más que cualquier paso suelto. Antes de cada restauración hay que responder dos preguntas: ¿los respaldos están intactos y fuera del alcance del atacante?, ¿y el punto de restauración es anterior a la intrusión? El diagrama de flujo muestra el camino completo, y la lista que sigue es la versión corta para imprimir.

Cuando llega el ransomware, la gente toma sus peores decisiones en la primera hora. Escribe el manual con calma, imprímelo y guarda una copia fuera de la red. Una versión corta se ve así:

1. Aísla. Desconecta los equipos afectados de la red y del almacenamiento de respaldos. No los apagues si podrías necesitar evidencia de la memoria.
2. Llama a las personas correctas. Defínelas de antemano: quien está a cargo, tu contacto de TI, la aseguradora, el asesor legal y quien hablará con los clientes.
3. Protege los respaldos. Rota todas las credenciales de respaldo desde un equipo limpio y confirma que la copia inmutable está intacta.
4. Encuentra la puerta de entrada. Antes de restaurar, identifica cómo entró el atacante y ciérrala; si no, volverás a quedar cifrado en pocos días.
5. Restaura por niveles. Reconstruye desde imágenes limpias, restaura el nivel 1, verifícalo y sigue bajando por la lista.
6. Cambia todos los secretos. Contraseñas, llaves de API, tokens y la llave de la aplicación cuando sea seguro hacerlo.
7. Notifica y revisa. Avisa a los reguladores y a los clientes afectados donde la ley lo exija, y luego anota qué vas a cambiar.

Conviene leer las guías de los gobiernos antes de necesitarlas. Los recursos StopRansomware de la CISA de Estados Unidos incluyen una lista de verificación práctica de respuesta que sirve también fuera de ese país.

Repite el mismo viernes con los consejos aplicados. Cada lunes a las 6:00 el sistema restaura el volcado más reciente en una base de datos desechable y compara el número de pedidos con producción. En marzo la comprobación falla y llega un correo: pedidos: 0, esperados: unos 4,200. La dueña lo lee con su café, el contratista corrige el script en menos de una hora y, detrás, queda intacta una copia en un bucket bloqueado, escrita con una llave que solo puede agregar archivos. Lo que habría sido un descubrimiento de viernes por la tarde es un correo de lunes por la mañana.

Ideas clave

• Los atacantes van primero por los respaldos. Una copia a la que se llega con tus credenciales de administrador habituales será cifrada o borrada junto con todo lo demás.
• Usa 3-2-1-1-0: tres copias, dos medios, una fuera del sitio, una inmutable o fuera de línea y cero errores en las pruebas de restauración.
• Asigna a cada sistema un RPO y un RTO según lo que cuesta la caída, no según lo que sea cómodo de configurar.
• Respalda más que la base de datos: archivos, configuración, secretos, licencias y la receta de reconstrucción por escrito, todo cifrado.
• Cuentas separadas, credenciales de solo escritura y una retención mayor que el tiempo que un intruso pasa escondido protegen la copia inmutable.
• Pon los simulacros de restauración en el calendario y registra los resultados. Un respaldo se comprueba restaurándolo, no con una palomita verde.

Anichur Rahaman es arquitecto de software y creador de StoreConsole. Diseña sistemas de comercio y ERP para negocios en crecimiento, con enfoque en arquitectura orientada a eventos, integridad de datos y operación en servidores propios.