Respaldo gestionado y continuidad del negocio en Uruguay

Casi todas las empresas tienen respaldos. Muy pocas saben si funcionan. La diferencia entre las dos cosas se descubre siempre en el peor momento: cuando hay que restaurar de verdad y recién ahí se ve si el respaldo estaba completo, si el archivo era legible y cuánto tarda realmente el proceso.

Por eso el servicio de respaldo de ITS incluye pruebas de restauración semestrales, documentadas. No es una promesa de que el respaldo va a funcionar: es la evidencia, dos veces por año, de que funcionó.

Un respaldo sin restauración probada es una suposición

Un trabajo de backup puede terminar con estado exitoso durante meses y aun así no servir. Puede estar respaldando una carpeta que dejó de ser la que importa. Puede tener un archivo corrupto que nadie abrió. Puede depender de una credencial que caducó. Puede estar completo pero tardar catorce horas en restaurarse, cuando el negocio aguanta cuatro.

Nada de eso aparece en el reporte de que el backup corrió bien. Aparece únicamente cuando se restaura. Probar la restauración es lo que convierte al respaldo de una intención en un servicio.

Que las pruebas queden documentadas agrega la otra mitad: hay registro de qué se restauró, cuándo, cuánto tardó y qué resultado dio. Eso es lo que permite ajustar los tiempos comprometidos con datos, y es también lo que un auditor puede revisar. La gestión de continuidad es uno de los procesos que audita la norma ISO/IEC 20000, en la que ITS está certificada desde 2009.

El servicio empieza con una restauración

Cuando ITS toma control del respaldo de una empresa, el primer paso del servicio es una prueba de restauración. No en la primera revisión semestral: al inicio, antes de dar por buena la operación que se está recibiendo.

Es la única forma de saber en qué estado real está lo que se hereda. Y con frecuencia es también la primera vez que esa empresa averigua si lo que venía respaldando durante años se podía recuperar de verdad. Preferimos descubrirlo el primer día, con tiempo y sin presión, y no el día en que hace falta.

Dónde queda la información: en el cliente y en la nube

ITS mantiene el respaldo en dos lugares, porque resuelven problemas distintos.

La copia local, en la infraestructura del cliente, es la que permite restaurar rápido. Recuperar un servidor completo desde internet depende del ancho de banda disponible y puede tardar horas o días; hacerlo desde una copia que está en la misma red es cuestión de minutos u horas. Para el incidente cotidiano —un archivo borrado, una base corrupta, un servidor que falla— es la que se usa.

La copia en la nube es la que sobrevive cuando el problema alcanza al sitio: un incendio, un robo, una inundación. Y sobre todo un ransomware, que es hoy la razón principal para tenerla. El ransomware moderno no se limita a cifrar los datos: busca activamente los respaldos accesibles desde la red y los cifra o los borra primero, justamente para dejar a la víctima sin salida. Una copia local, sola, puede caer en el mismo ataque que provocó la necesidad de restaurar.

Tener las dos no es redundancia por las dudas: es cubrir dos escenarios que no se resuelven igual.

Air gap o inmutabilidad: que el respaldo no caiga con el resto

Que exista una copia remota no alcanza si el atacante puede llegar a ella. El problema a resolver es concreto: la copia tiene que sobrevivir a un compromiso de la red que la genera. Hay dos maneras de lograrlo, y ITS usa la que corresponde a cada esquema:

• Air gap. La copia queda fuera del alcance de la red: si el atacante no puede llegar a ella, no puede cifrarla ni borrarla.
• Inmutabilidad. Cuando la copia tiene que permanecer accesible en línea, se configura con retención bloqueada. Una vez escrita, no se puede modificar ni eliminar hasta que vence el plazo definido —tampoco con credenciales de administrador, que es justamente lo que un atacante busca obtener.

Son dos respuestas al mismo riesgo y se eligen según cómo esté armado el esquema de cada cliente. La inmutabilidad es la que aplica sobre todo cuando la copia no está aislada, porque sustituye la protección que en otro escenario daría la desconexión.

Del respaldo a la continuidad

Restaurar un archivo borrado y volver a operar después de perder un servidor son problemas de escala distinta. El respaldo resuelve el primero. El segundo requiere haber decidido de antemano qué se levanta primero, en qué plataforma, quién lo hace y con qué autorizaciones.

ITS trabaja los dos niveles: respaldo gestionado con restauración verificada, y planes de continuidad operacional que definen cómo sigue funcionando la empresa cuando algo importante deja de estar disponible.

Las dos preguntas que definen el diseño

Antes de elegir herramientas o frecuencias, hay dos números que conviene definir con el negocio y no con el área técnica:

• Cuánta información se puede perder. Si se respalda una vez por día, un incidente a las cinco de la tarde puede costar una jornada entera de trabajo. ¿Es aceptable? Para una contabilidad puede serlo; para una operación transaccional, no.
• Cuánto tiempo se puede estar sin el servicio. No es lo mismo volver a operar en dos horas que en dos días, y la diferencia de costo entre ambas cosas es grande. Definirlo evita las dos formas de equivocarse: pagar por una disponibilidad que no se necesita, o descubrir tarde que la que se contrató no alcanza.

Con esas dos respuestas, el resto del diseño —frecuencia, retención, dónde se guarda, cómo se restaura— se vuelve una consecuencia y no una discusión de preferencias.

Preguntas frecuentes

¿Cada cuánto se prueban las restauraciones?

En ITS las pruebas de restauración se realizan de forma semestral y quedan documentadas, con registro de qué se restauró, cuándo y con qué resultado. Es una diferencia importante al comparar proveedores: casi todos hacen respaldos, pero muchos nunca verifican que se puedan restaurar, y esa verificación es lo único que distingue un respaldo real de un trabajo que termina en estado exitoso.

¿Cómo sé si mis respaldos actuales realmente funcionan?

Restaurándolos. No hay otra manera: los reportes de ejecución indican que el trabajo corrió, no que el resultado sirva. Una prueba de restauración muestra si la información está completa, si es legible y cuánto tarda en volver a estar disponible, que es el dato que en un incidente define todo. En ITS, cuando tomamos control del respaldo de una empresa, el primer paso del servicio es justamente una prueba de restauración, y después se repite de forma semestral con registro documentado.

¿Por qué no alcanza con que el backup diga que corrió bien?

Porque un trabajo de respaldo puede completarse correctamente y aun así no servir: puede estar copiando una carpeta que ya no es la relevante, contener un archivo corrupto, depender de una credencial vencida o tardar en restaurarse mucho más de lo que el negocio puede esperar. Ninguna de esas situaciones aparece en el reporte de ejecución. Solo se detectan restaurando.

¿Dónde se guardan los respaldos?

En dos lugares: una copia en la infraestructura del cliente y otra en la nube. La copia local permite restaurar rápido, porque no depende del ancho de banda, y es la que se usa para los incidentes cotidianos. La copia en la nube cubre los casos en que el problema alcanza al sitio —incendio, robo— y sobre todo el ransomware, que además de cifrar los datos busca los respaldos accesibles desde la red para cifrarlos o borrarlos primero. Una sola copia local puede quedar comprometida por el mismo ataque que obliga a restaurar.

¿Qué protege a los respaldos de un ransomware?

Que el atacante no pueda alcanzarlos o no pueda alterarlos. Son dos caminos distintos hacia lo mismo. El air gap deja la copia fuera del alcance de la red, de modo que un compromiso de la infraestructura no llega hasta ella. La inmutabilidad se usa cuando la copia tiene que permanecer accesible en línea: se configura con retención bloqueada, y una vez escrita no puede modificarse ni borrarse hasta que vence el plazo definido, ni siquiera con credenciales de administrador. Un respaldo conectado a la red, sin ninguna de las dos protecciones, puede quedar cifrado por el mismo ataque que obliga a restaurarlo.

¿Qué diferencia hay entre respaldo y continuidad del negocio?

El respaldo permite recuperar información perdida. La continuidad del negocio define cómo sigue operando la empresa cuando un servicio deja de estar disponible: qué se levanta primero, en qué plataforma, quién lo ejecuta y con qué autorizaciones. Son complementarios: un respaldo impecable no evita que la empresa esté detenida si nadie definió el orden de recuperación.

¿Cómo defino cada cuánto respaldar?

A partir de dos preguntas de negocio, no técnicas: cuánta información puede perderse sin consecuencias graves, y cuánto tiempo puede estar la empresa sin ese servicio. La frecuencia, la retención y el esquema de restauración se desprenden de esas dos respuestas. Definirlas al revés —elegir primero la herramienta— es como se llega a pagar por una disponibilidad que no se necesita, o a descubrir tarde que la contratada no alcanzaba.

Hablemos

Si no sabés con certeza si tus respaldos actuales se pueden restaurar, esa es la conversación que vale la pena tener. Escribinos a info@its.com.uy o llamanos al +598 2623 4347. Al tomar control de un servicio de respaldo empezamos siempre por lo mismo: probar una restauración y ver qué había realmente.