El día en que el ransomware cifra tus servidores, nadie quiere descubrir, en vivo, cuánto de la operación se puede recuperar y en cuánto tiempo. Esas dos respuestas tienen nombre: RPO y RTO. Son números que defines antes — con calma, sobre la mesa — o números que el incidente define por ti, en el peor momento posible.
Este texto explica los dos conceptos sin rodeos, muestra la regla de backup que sigue vigente (la 3-2-1) y por qué una transportadora — que no puede pasar un día sin emitir CT-e ni rastrear la carga — necesita pensar en esto de una forma específica. Definiciones claras, tal como querrás haberlas leído antes.
RPO: cuántos datos aceptas perder
El RPO (Recovery Point Objective) es la cantidad máxima de datos que tu operación acepta perder, medida en tiempo. Si tu RPO es de 1 hora, significa que, tras la restauración, puedes haber perdido hasta la última hora de trabajo — y eso es aceptable. Si el RPO es de 24 horas, puedes volver a la foto de ayer por la mañana.
En la práctica, el RPO define cada cuánto tiempo haces backup. No se puede tener un RPO de 15 minutos con un backup una vez al día — la matemática no cierra. Cuanto menor es el RPO, más frecuente (y más caro) el backup.
La pregunta que destraba la definición es directa: si perdiera todo lo que entró en el sistema desde el último backup, ¿cuánto me costaría? Para un CT-e emitido y no guardado, el costo es rehacer la digitación y arriesgar una inconsistencia fiscal. Para un albarán de carga, es no saber qué entró en el camión.
RTO: en cuánto tiempo necesitas volver
El RTO (Recovery Time Objective) es el tiempo máximo que tu operación aguanta detenida antes de que la restauración esté concluida y el sistema vuelva a funcionar. Si el RTO es de 4 horas, tienes 4 horas, desde el incidente hasta la operación funcionando de nuevo — ni un minuto más.
El RTO no es solo el tiempo de copiar los archivos de vuelta. Es el reloj entero: detectar el problema, aislar lo que fue comprometido, encontrar un backup limpio, restaurar, validar que está íntegro y volver a encender. Quien solo cronometra la copia descubre demasiado tarde que validar y volver a encender llevan más tiempo del esperado.
La pregunta aquí es de dinero: ¿cuánto cuesta cada hora detenida? Para una transportadora, una hora detenida es entrega atrasada, multa de SLA, camión en la fila sin documento y cliente llamando. Ese costo por hora es lo que justifica — o no — invertir en una recuperación más rápida.
RPO y RTO no son lo mismo (y necesitas los dos)
Es común confundirlos. La forma simple de separarlos:
- El RPO mira hacia atrás — cuántos datos, en el pasado, aceptas perder.
- El RTO mira hacia adelante — cuánto tiempo, a partir de ahora, aceptas estar detenido.
Un sistema puede tener un RPO óptimo y un RTO pésimo: no pierdes casi nada, pero tardas tres días en volver a encender. O al revés: enciendes en 20 minutos, pero volviste a la foto de la semana pasada. Los dos tienen que tener sentido juntos, para cada sistema. El ERP fiscal exige un RPO y un RTO ajustados. Un data warehouse de BI, que se reconstruye a partir de las fuentes, aguanta números más holgados.
La regla 3-2-1: el backup que sobrevive al ataque
El RPO y el RTO solo existen si hay un backup de verdad para restaurar. La regla que aún organiza esto es la 3-2-1:
- 3 copias de tus datos (la original más dos).
- 2 medios o tecnologías diferentes (no las dos en el mismo disco, en el mismo servidor).
- 1 copia fuera del sitio — offline o inmutable, que el ransomware no logra alcanzar ni borrar.
El detalle que más falla es el "1". Un backup que queda en el mismo servidor, o en un NAS montado en la red, se cifra junto con el resto el día del ataque. El ransomware moderno busca y destruye los backups primero, justamente para forzar el rescate. Por eso la copia externa necesita ser inmutable (write-once, que nadie reescribe) o estar genuinamente desconectada. Sin ese "1", la regla entera no te salva.
Un backup que nunca fue restaurado no es un backup
Esta es la frase que más duele después de un incidente. Una rutina de backup que corre todos los días, genera un archivo, marca verde en el panel — y nunca fue restaurada — es una suposición, no una garantía. El día del ataque es cuando mucha gente descubre que el archivo estaba corrupto, que faltaba la base de datos correcta, o que la restauración lleva el triple del tiempo planeado.
Un backup solo se convierte en backup cuando pruebas la restauración de verdad, en un entorno separado, y la cronometras. Esa prueba responde, con hechos y no con fe, si tu RTO es real y si el RPO coincide con la frecuencia configurada. Recomendación concreta: una prueba de restauración documentada cada trimestre, y siempre que cambies algo grande en el sistema.
El caso de la transportadora: quien no puede parar ni un día
Una transportadora no tiene el lujo de un RTO de "algunos días". Sin ERP, no hay emisión de CT-e ni MDF-e — un camión no sale del patio sin documento fiscal. Sin rastreo, pierdes la posición de la flota y la visibilidad de la carga en tránsito. Cada hora detenida se vuelve multa de SLA, entrega atrasada y teléfono sonando.
Cómo pensarlo en la práctica:
- Separa los sistemas por criticidad. La emisión fiscal y el rastreo (SASCAR, Autotrac, Omnilink) exigen un RTO de horas y un RPO bajo. Los reportes de BI aguantan más.
- Frecuencia de backup que coincida con el RPO. Si aceptas perder como máximo 1 hora de documentos, el backup de la base fiscal no puede ser diario.
- Una copia inmutable y fuera del sitio — el ransomware que toma el ERP no puede alcanzar su backup.
- Prueba de restauración cronometrada, para saber si en 4 horas realmente vuelves a emitir documentos.
El objetivo es simple: que el secuestro de datos sea un contratiempo de horas, no una parada de días — y que pagar el rescate nunca sea la única salida sobre la mesa. Es privacidad y continuidad por diseño, no por parche.
Preguntas frecuentes
¿Cuál es la diferencia entre RPO y RTO?
El RPO (Recovery Point Objective) es cuántos datos aceptas perder, medido en tiempo — define la frecuencia del backup. El RTO (Recovery Time Objective) es en cuánto tiempo necesitas volver a operar tras el incidente. El RPO mira hacia atrás (datos perdidos); el RTO mira hacia adelante (tiempo detenido). Necesitas definir los dos, para cada sistema crítico.
¿Qué es la regla 3-2-1 de backup?
Son 3 copias de los datos, en 2 medios diferentes, con 1 copia fuera del sitio — offline o inmutable. El "1" es lo que protege contra el ransomware: la copia externa necesita estar fuera del alcance del ataque, porque el ransomware moderno busca y destruye los backups accesibles en la red antes de pedir el rescate.
¿Por qué se dice que un backup no probado no es un backup?
Porque un backup que nunca fue restaurado es solo una suposición. El día del incidente es cuando se descubre que el archivo estaba corrupto, que faltaba una base o que la restauración tarda el triple de lo previsto. Solo una prueba de restauración real, en un entorno separado y cronometrada, demuestra que tu RTO y RPO son verdaderos. Lo ideal es probar cada trimestre.
¿Cómo definir el RPO y el RTO para una transportadora?
Separa los sistemas por criticidad. La emisión fiscal (CT-e, MDF-e) y el rastreo de flota exigen un RTO de pocas horas y un RPO bajo, porque un camión no sale sin documento y una operación detenida se vuelve multa de SLA. El BI y los reportes aguantan números más holgados. Después, configura la frecuencia de backup para que coincida con el RPO y prueba la restauración de verdad.
¿Cuánto cuesta tener la operación detenida por ransomware?
Ese es exactamente el cálculo que define el RTO. Para una transportadora, cada hora detenida significa entregas atrasadas, multas de SLA, camiones en la fila sin documento fiscal y clientes sin respuesta. Ese costo por hora es lo que justifica invertir en una recuperación más rápida — cuanto más cara la hora detenida, más ajustado tiene que ser el RTO.
¿Pagar el rescate del ransomware lo resuelve?
Pagar no garantiza la clave, no garantiza que los datos vuelvan íntegros y financia el próximo ataque. La alternativa es tener backups inmutables y probados que permitan restaurar la operación dentro del RTO y RPO acordados, sin depender del criminal. Definir esos números antes del incidente es lo que quita el rescate de la mesa como única salida.