[et_pb_section fb_built=\u00bb1″ theme_builder_area=\u00bbpost_content\u00bb _builder_version=\u00bb4.27.8″ _module_preset=\u00bbdefault\u00bb][et_pb_row _builder_version=\u00bb4.27.8″ _module_preset=\u00bbdefault\u00bb theme_builder_area=\u00bbpost_content\u00bb][et_pb_column _builder_version=\u00bb4.27.8″ _module_preset=\u00bbdefault\u00bb type=\u00bb4_4″ theme_builder_area=\u00bbpost_content\u00bb][et_pb_text _builder_version=\u00bb4.27.8″ _module_preset=\u00bbdefault\u00bb theme_builder_area=\u00bbpost_content\u00bb hover_enabled=\u00bb0″ sticky_enabled=\u00bb0″]<\/p>\n
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\u00e9n ah\u00ed se ve si el respaldo estaba completo, si el archivo era legible y cu\u00e1nto tarda realmente el proceso.<\/p>\n
Por eso el servicio de respaldo de ITS incluye pruebas de restauraci\u00f3n semestrales, documentadas<\/strong>. No es una promesa de que el respaldo va a funcionar: es la evidencia, dos veces por a\u00f1o, de que funcion\u00f3.<\/p>\n Un trabajo de backup puede terminar con estado exitoso durante meses y aun as\u00ed no servir. Puede estar respaldando una carpeta que dej\u00f3 de ser la que importa. Puede tener un archivo corrupto que nadie abri\u00f3. Puede depender de una credencial que caduc\u00f3. Puede estar completo pero tardar catorce horas en restaurarse, cuando el negocio aguanta cuatro.<\/p>\n Nada de eso aparece en el reporte de que el backup corri\u00f3 bien. Aparece \u00fanicamente cuando se restaura. Probar la restauraci\u00f3n es lo que convierte al respaldo de una intenci\u00f3n en un servicio.<\/p>\n Que las pruebas queden documentadas<\/strong> agrega la otra mitad: hay registro de qu\u00e9 se restaur\u00f3, cu\u00e1ndo, cu\u00e1nto tard\u00f3 y qu\u00e9 resultado dio. Eso es lo que permite ajustar los tiempos comprometidos con datos, y es tambi\u00e9n lo que un auditor puede revisar. La gesti\u00f3n de continuidad es uno de los procesos que audita la norma ISO\/IEC 20000, en la que ITS est\u00e1 certificada desde 2009<\/a>.<\/p>\n Cuando ITS toma control del respaldo de una empresa, el primer paso del servicio es una prueba de restauraci\u00f3n<\/strong>. No en la primera revisi\u00f3n semestral: al inicio, antes de dar por buena la operaci\u00f3n que se est\u00e1 recibiendo.<\/p>\n Es la \u00fanica forma de saber en qu\u00e9 estado real est\u00e1 lo que se hereda. Y con frecuencia es tambi\u00e9n la primera vez que esa empresa averigua si lo que ven\u00eda respaldando durante a\u00f1os se pod\u00eda recuperar de verdad. Preferimos descubrirlo el primer d\u00eda, con tiempo y sin presi\u00f3n, y no el d\u00eda en que hace falta.<\/p>\n ITS mantiene el respaldo en dos lugares, porque resuelven problemas distintos.<\/p>\n La copia local, en la infraestructura del cliente<\/strong>, es la que permite restaurar r\u00e1pido. Recuperar un servidor completo desde internet depende del ancho de banda disponible y puede tardar horas o d\u00edas; hacerlo desde una copia que est\u00e1 en la misma red es cuesti\u00f3n de minutos u horas. Para el incidente cotidiano \u2014un archivo borrado, una base corrupta, un servidor que falla\u2014 es la que se usa.<\/p>\n La copia en la nube<\/strong> es la que sobrevive cuando el problema alcanza al sitio: un incendio, un robo, una inundaci\u00f3n. Y sobre todo un ransomware<\/a>, que es hoy la raz\u00f3n 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\u00edctima sin salida. Una copia local, sola, puede caer en el mismo ataque que provoc\u00f3 la necesidad de restaurar.<\/p>\n Tener las dos no es redundancia por las dudas: es cubrir dos escenarios que no se resuelven igual.<\/p>\n 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:<\/p>\n Son dos respuestas al mismo riesgo y se eligen seg\u00fan c\u00f3mo est\u00e9 armado el esquema de cada cliente. La inmutabilidad es la que aplica sobre todo cuando la copia no est\u00e1 aislada, porque sustituye la protecci\u00f3n que en otro escenario dar\u00eda la desconexi\u00f3n.<\/p>\n Restaurar un archivo borrado y volver a operar despu\u00e9s de perder un servidor son problemas de escala distinta. El respaldo resuelve el primero. El segundo requiere haber decidido de antemano qu\u00e9 se levanta primero, en qu\u00e9 plataforma, qui\u00e9n lo hace y con qu\u00e9 autorizaciones.<\/p>\n ITS trabaja los dos niveles: respaldo gestionado con restauraci\u00f3n verificada, y planes de continuidad operacional que definen c\u00f3mo sigue funcionando la empresa cuando algo importante deja de estar disponible.<\/p>\n Antes de elegir herramientas o frecuencias, hay dos n\u00fameros que conviene definir con el negocio y no con el \u00e1rea t\u00e9cnica:<\/p>\n Con esas dos respuestas, el resto del dise\u00f1o \u2014frecuencia, retenci\u00f3n, d\u00f3nde se guarda, c\u00f3mo se restaura\u2014 se vuelve una consecuencia y no una discusi\u00f3n de preferencias.<\/p>\n En ITS las pruebas de restauraci\u00f3n se realizan de forma semestral y quedan documentadas, con registro de qu\u00e9 se restaur\u00f3, cu\u00e1ndo y con qu\u00e9 resultado. Es una diferencia importante al comparar proveedores: casi todos hacen respaldos, pero muchos nunca verifican que se puedan restaurar, y esa verificaci\u00f3n es lo \u00fanico que distingue un respaldo real de un trabajo que termina en estado exitoso.<\/p>\n Restaur\u00e1ndolos. No hay otra manera: los reportes de ejecuci\u00f3n indican que el trabajo corri\u00f3, no que el resultado sirva. Una prueba de restauraci\u00f3n muestra si la informaci\u00f3n est\u00e1 completa, si es legible y cu\u00e1nto 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\u00f3n, y despu\u00e9s se repite de forma semestral con registro documentado.<\/p>\n Porque un trabajo de respaldo puede completarse correctamente y aun as\u00ed 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\u00e1s de lo que el negocio puede esperar. Ninguna de esas situaciones aparece en el reporte de ejecuci\u00f3n. Solo se detectan restaurando.<\/p>\n En dos lugares: una copia en la infraestructura del cliente y otra en la nube. La copia local permite restaurar r\u00e1pido, 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 \u2014incendio, robo\u2014 y sobre todo el ransomware, que adem\u00e1s 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.<\/p>\n 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\u00ednea: se configura con retenci\u00f3n 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.<\/p>\n El respaldo permite recuperar informaci\u00f3n perdida. La continuidad del negocio define c\u00f3mo sigue operando la empresa cuando un servicio deja de estar disponible: qu\u00e9 se levanta primero, en qu\u00e9 plataforma, qui\u00e9n lo ejecuta y con qu\u00e9 autorizaciones. Son complementarios: un respaldo impecable no evita que la empresa est\u00e9 detenida si nadie defini\u00f3 el orden de recuperaci\u00f3n.<\/p>\n A partir de dos preguntas de negocio, no t\u00e9cnicas: cu\u00e1nta informaci\u00f3n puede perderse sin consecuencias graves, y cu\u00e1nto tiempo puede estar la empresa sin ese servicio. La frecuencia, la retenci\u00f3n y el esquema de restauraci\u00f3n se desprenden de esas dos respuestas. Definirlas al rev\u00e9s \u2014elegir primero la herramienta\u2014 es como se llega a pagar por una disponibilidad que no se necesita, o a descubrir tarde que la contratada no alcanzaba.<\/p>\n Si no sab\u00e9s con certeza si tus respaldos actuales se pueden restaurar, esa es la conversaci\u00f3n que vale la pena tener. Escribinos a info@its.com.uy<\/a> o llamanos al +598 2623 4347. Al tomar control de un servicio de respaldo empezamos siempre por lo mismo: probar una restauraci\u00f3n y ver qu\u00e9 hab\u00eda realmente.<\/p>\n [\/et_pb_text][et_pb_code _builder_version=\u00bb4.27.8″ _module_preset=\u00bbdefault\u00bb theme_builder_area=\u00bbpost_content\u00bb hover_enabled=\u00bb0″ sticky_enabled=\u00bb0″]Un respaldo sin restauraci\u00f3n probada es una suposici\u00f3n<\/h2>\n
El servicio empieza con una restauraci\u00f3n<\/h2>\n
D\u00f3nde queda la informaci\u00f3n: en el cliente y en la nube<\/h2>\n
Air gap o inmutabilidad: que el respaldo no caiga con el resto<\/h2>\n
\n
Del respaldo a la continuidad<\/h2>\n
Las dos preguntas que definen el dise\u00f1o<\/h2>\n
\n
Preguntas frecuentes<\/h2>\n
\u00bfCada cu\u00e1nto se prueban las restauraciones?<\/h3>\n
\u00bfC\u00f3mo s\u00e9 si mis respaldos actuales realmente funcionan?<\/h3>\n
\u00bfPor qu\u00e9 no alcanza con que el backup diga que corri\u00f3 bien?<\/h3>\n
\u00bfD\u00f3nde se guardan los respaldos?<\/h3>\n
\u00bfQu\u00e9 protege a los respaldos de un ransomware?<\/h3>\n
\u00bfQu\u00e9 diferencia hay entre respaldo y continuidad del negocio?<\/h3>\n
\u00bfC\u00f3mo defino cada cu\u00e1nto respaldar?<\/h3>\n
Hablemos<\/h2>\n