ERPBackup

Respaldos

RPO y RTO: los dos números que definen tu respaldo

Cuánto trabajo estás dispuesto a reingresar y cuántas horas puedes estar detenido. De esas dos respuestas salen la frecuencia del respaldo y el destino.

· 6 min de lectura · Equipo ERPBackup

Cuando alguien pregunta "¿cada cuánto conviene respaldar?", la respuesta honesta es otra pregunta: ¿cuánto trabajo estás dispuesto a reingresar a mano y cuántas horas puedes estar detenido?

Esas dos respuestas tienen nombre técnico, RPO y RTO, y son las que definen todo lo demás: la frecuencia, el destino y hasta el plan que conviene contratar.

RPO: lo que se pierde

El RPO (punto de recuperación) es la distancia entre el último respaldo bueno y el momento del incidente. Todo lo que se digitó en ese intervalo no está en ninguna copia.

Con un respaldo diario a las 02:00 y una falla a las 16:00, el RPO real fue de 14 horas: un día completo de facturación, recepciones y pagos que alguien tiene que volver a ingresar mirando papeles.

RTO: lo que se demora

El RTO (tiempo de recuperación) es lo que pasa entre el incidente y el momento en que el ERP vuelve a estar operativo. No es solo restaurar el archivo: incluye conseguir un servidor, instalar SQL Server y Softland, bajar la copia desde el destino, restaurar, revisar y avisarle a la gente que ya puede entrar.

Último respaldo02:00Incidente16:00Sistema operativo22:00RPO14 horas de digitación por reingresarRTO6 horas hasta volver a facturar
Ejemplo: RPO es el trabajo que se pierde entre el último respaldo y el incidente; RTO es lo que demora volver a operar. Las horas son ilustrativas.

Por qué conviene ponerles número antes

Sin números, la conversación sobre respaldos se queda en "hay que respaldar más seguido". Con números, se vuelve concreta y se puede decidir:

  • Si el negocio tolera perder un día de digitación, el respaldo diario alcanza.
  • Si tolera perder una hora, hay que conversar de respaldos más frecuentes o de respaldos de log de transacciones.
  • Si el RTO objetivo es de horas y no de días, hay que tener resuelto de antemano dónde va a correr el ERP mientras el servidor original no está.

Cómo estimar el RTO sin adivinar

La única forma seria es cronometrar una restauración de verdad. Se toma la copia más reciente, se restaura en un equipo aparte y se anota cuánto demoró cada etapa. Ese ejercicio suele revelar dos cosas incómodas:

  • Bajar 40 GB desde la nube con la conexión de la oficina toma más de lo que cualquiera supone.
  • Nadie tenía a mano la clave del destino, ni el instalador de la versión correcta de Softland.

Ambas se arreglan en cinco minutos un día tranquilo, y cuestan horas el día del incidente. El procedimiento está en cómo probar una restauración.

Qué hace ERPBackup con esto

El RPO lo define la programación: eliges a qué hora y con qué frecuencia corre la copia. El aviso por correo en cada ejecución evita el peor caso, que es descubrir tarde que el RPO real era de tres meses porque el respaldo llevaba tres meses fallando.

El RTO depende de tu infraestructura y de tu equipo. Lo que aporta la herramienta es que la copia esté disponible fuera del servidor y que se restaure con las herramientas nativas de Softland, sin depender de un formato propio.

Si quieres ver el resto del cuadro, ciberseguridad de Softland ordena qué cubre el respaldo y qué controles siguen siendo de tu lado.

Revisemos cómo está respaldado tu Softland

Cuéntanos qué bases usas y dónde corren, y armamos contigo la programación de respaldos que corresponde.