Resumen consolidado de las notas de clase
1. Importancia estratégica de los datos en las organizaciones
Se abordó la gestión de los datos como un tema central para la administración de organizaciones. Si bien las políticas de backup, recuperación y continuidad suelen ser consideradas cuestiones técnicas, se destacó que sus consecuencias son directamente administrativas, operativas, económicas y estratégicas.
El punto de partida conceptual fue que la tecnología puede reemplazarse, pero los datos no. Una computadora, un servidor, un sistema operativo o incluso una infraestructura tecnológica pueden ser sustituidos. En cambio, los datos generados por la propia organización no pueden comprarse en el mercado ni reconstruirse fácilmente mediante terceros. Incluso cuando cierta información se encuentra disponible en plataformas externas, como organismos fiscales o sistemas integrados, esa información suele ser parcial y no contiene todo el detalle interno necesario para reconstruir la operatoria completa.
Por ello, se remarcó que la información propia de la organización constituye un activo crítico. Su pérdida puede afectar la facturación, la atención a clientes, los movimientos de inventario, la gestión financiera, el cumplimiento normativo, la trazabilidad de operaciones y la continuidad general del negocio.
2. Riesgo residual y certeza de fallas en los sistemas
Se planteó que no existe el riesgo cero. Toda organización, aun cuando cuente con buenas prácticas de seguridad, conserva siempre un riesgo residual. En consecuencia, la pregunta no debe ser si los sistemas fallarán, sino cuándo fallarán y qué capacidad tendrá la organización para responder.
La falla de los sistemas fue presentada como una certeza eventual dentro de la vida organizacional. Los controles, políticas y mecanismos de seguridad tienen por finalidad reducir la probabilidad de ocurrencia, disminuir el impacto y permitir una recuperación ordenada. Sin embargo, ninguna medida elimina totalmente la posibilidad de incidentes.
Desde esta perspectiva, la gestión del backup no debe considerarse una actividad secundaria ni meramente técnica. Debe formar parte de la planificación organizacional, de la gestión de riesgos y de la estrategia de continuidad operativa.
3. Backup y restore
El backup fue definido como la copia de datos, sistemas o configuraciones que se conserva como respaldo ante una eventual pérdida, daño o indisponibilidad de la información original. Su objetivo es permitir que, frente a un incidente, la organización pueda recuperar los datos necesarios para volver a operar.
El restore o restauración fue explicado como el proceso inverso: consiste en recuperar los datos desde una copia de seguridad para restablecer la operatoria. Sin embargo, se enfatizó que no alcanza con tener una copia. La copia debe existir, debe estar disponible, debe ser accesible y debe poder restaurarse correctamente.
Una idea central fue que un backup que no se prueba no puede considerarse realmente existente desde el punto de vista de la gestión. La organización puede creer que tiene copias de seguridad, pero si nunca se verificó su integridad ni su capacidad de restauración, puede descubrir recién ante un incidente que esas copias son incompletas, corruptas, inaccesibles o inútiles.
4. DRP, BCP y BAU
Se trabajaron tres conceptos fundamentales de la continuidad tecnológica y organizacional:
DRP: Disaster Recovery Plan
El DRP o Plan de Recuperación de Desastres comprende los procedimientos técnicos y administrativos que se ponen en marcha para restablecer los sistemas críticos luego de una interrupción grave, incidente o desastre.
Su objetivo principal es recuperar la infraestructura, los sistemas y los datos necesarios para volver a operar. Se destacó que este plan debe estar documentado, probado, auditado y revisado periódicamente, especialmente después de cambios tecnológicos relevantes.
BCP: Business Continuity Plan
El BCP o Plan de Continuidad del Negocio responde a una pregunta distinta: qué debe hacer la organización mientras los sistemas se están recuperando.
No se trata solo de volver a la normalidad, sino de sostener las funciones esenciales durante el período de contingencia. Por ejemplo, una organización puede definir procesos alternativos, operaciones manuales, canales provisorios, mecanismos de comunicación con clientes o formas limitadas de prestación del servicio.
El DRP y el BCP deben planificarse en conjunto, aunque tienen objetivos diferentes. El DRP se concentra en recuperar los sistemas; el BCP se concentra en mantener viva la operación mientras la recuperación ocurre.
BAU: Business as Usual
El concepto de BAU o Business as Usual refiere a la operatoria normal o habitual del negocio. La recuperación no concluye simplemente cuando los sistemas vuelven a encenderse, sino cuando la organización logra retornar a su funcionamiento normal, con datos consistentes, procesos activos y capacidad operativa validada.
5. Métricas de recuperación: RPO, RTO y MTD
Se explicaron tres métricas fundamentales para definir políticas de continuidad y recuperación.
RPO: Recovery Point Objective
El RPO indica la cantidad máxima de datos que una organización está dispuesta a perder, expresada en tiempo. Por ejemplo, si el RPO es de una hora, la organización debería contar con copias de seguridad suficientemente frecuentes como para no perder más de sesenta minutos de datos.
Este parámetro depende del volumen de transacciones, del tipo de negocio, de la criticidad de los procesos y de la capacidad de reprocesar información perdida. Una hora puede ser tolerable para una organización pequeña con bajo volumen de operaciones, pero inaceptable para un banco, una cadena de supermercados, una plataforma de pagos o un sistema de inscripción en períodos críticos.
RTO: Recovery Time Objective
El RTO indica el tiempo máximo aceptable para restaurar los sistemas y volver a operar. No se refiere a la cantidad de datos perdidos, sino al tiempo de indisponibilidad tecnológica que la organización puede tolerar.
Una interrupción de dos horas puede parecer breve en términos generales, pero su impacto varía según el contexto. No es lo mismo una caída de sistemas bancarios fuera del horario de mayor actividad que una caída durante la atención al público. Tampoco es equivalente una caída en un supermercado durante una hora de baja demanda que durante un pico de ventas.
MTD: Maximum Tolerable Downtime
El MTD representa el tiempo máximo tolerable de caída antes de que la organización sufra un perjuicio grave o comprometa la viabilidad de sus procesos. Es el límite superior de indisponibilidad aceptable.
El MTD permite definir hasta cuándo puede extenderse una contingencia sin que el daño sea crítico. Superado ese umbral, la interrupción deja de ser solo un problema técnico y se transforma en un problema de continuidad organizacional.
6. Relación entre riesgo, tiempo y costo
Se destacó que existe una relación directa entre el nivel de protección deseado, el tiempo de recuperación esperado y el costo de la solución tecnológica.
Cuanto menor sea el RPO, menor debe ser la ventana entre copias de seguridad. Cuanto menor sea el RTO, más rápida debe ser la capacidad de restauración. Ambas exigencias suelen requerir mayor inversión en infraestructura, almacenamiento, automatización, replicación, nube, monitoreo y personal especializado.
Por ello, la decisión no es exclusivamente técnica. Es una decisión de administración. La organización debe determinar cuánto riesgo está dispuesta a asumir, cuánto tiempo puede permanecer inactiva, cuántos datos puede tolerar perder y cuánto está dispuesta a invertir para reducir esos riesgos.
7. Clasificación de los datos
Se explicó que la clasificación de los datos no debe quedar exclusivamente en manos del área de sistemas. La criticidad de la información depende del proceso de negocio al que sirve. Por eso, son las áreas de gestión quienes deben indicar qué datos son críticos, necesarios o innecesarios.
Datos críticos
Son aquellos cuya pérdida impide operar. Requieren mayor frecuencia de backup, protección reforzada y prioridad de restauración.
Ejemplos: maestros de clientes, maestros de productos, listas de precios, inventario disponible, movimientos financieros esenciales, condiciones de venta, datos necesarios para facturar o cobrar.
Datos necesarios
Son útiles para la gestión, pero su ausencia no paraliza de inmediato la operatoria. Deben conservarse y respaldarse, aunque pueden tener una frecuencia de backup distinta y una prioridad de restauración menor.
Ejemplos: cuentas corrientes de clientes o proveedores, históricos recientes, información de consulta, programas de puntos, reportes complementarios.
Datos innecesarios, redundantes o superfluos
Son datos que no aportan valor operativo actual o que pueden conservarse solo por obligación normativa, legal o documental. Su tratamiento depende de la política de retención de datos de la organización.
Ejemplos: ciertos textos legales incluidos en comprobantes, datos impresos por obligación formal o información histórica que ya no se utiliza en la gestión cotidiana.
8. Ejemplo del ticket o comprobante comercial
Se utilizó el ejemplo de un ticket o factura para mostrar que dentro de un mismo documento conviven distintos tipos de datos.
Algunos datos son críticos para la operación: producto vendido, precio, cantidad, impuestos, medio de pago, identificación del comprobante y movimientos de inventario. Otros datos son necesarios, como información vinculada al cliente, programas de beneficios o acumulación de puntos. También pueden existir datos de escasa utilidad operativa para la organización, aunque deban incluirse por razones legales o regulatorias.
Este ejemplo permitió mostrar que no todos los datos tienen la misma prioridad ante una restauración. En una situación de desastre, la organización debe decidir qué información debe recuperarse primero para volver a operar.
9. Tipos de backup
Se explicaron distintos tipos de backup según el alcance, la frecuencia, el espacio requerido y la complejidad de restauración.
Backup full o completo
Consiste en copiar la totalidad del conjunto de datos seleccionado. Puede incluir datos críticos, necesarios, innecesarios, configuraciones, tablas y archivos asociados.
Su ventaja es que ofrece una copia integral. Su desventaja es que demanda más tiempo, más espacio de almacenamiento y mayor capacidad de procesamiento. La periodicidad del backup full depende del volumen de datos, la velocidad de generación de transacciones, la criticidad del negocio y la capacidad tecnológica disponible.
Backup incremental
Copia únicamente los cambios producidos desde el último backup completo o desde el último backup incremental. Permite reducir espacio y tiempo de copia, pero su restauración requiere seguir una secuencia ordenada.
Por ejemplo, si se realiza un backup full a las 2 de la mañana y luego backups incrementales cada dos horas, ante un incidente se deberá restaurar primero el backup completo y luego cada incremental posterior hasta el último disponible.
Backup diferencial
Copia todos los cambios realizados desde el último backup full. A diferencia del incremental, no depende del incremental inmediatamente anterior, sino del último backup completo.
Puede simplificar ciertos procesos de recuperación, aunque también puede aumentar el volumen copiado a medida que pasan las horas desde el último backup completo.
Snapshot
El snapshot fue explicado como una “fotografía” del estado de los datos en un momento determinado. Es habitual en entornos de alta transaccionalidad, donde se necesita capturar el estado de sistemas con ventanas breves y controladas.
Se mencionó como ejemplo la lógica de redes financieras o bancarias, donde el volumen de transacciones exige mecanismos de copia muy frecuentes y coordinados con otras plataformas.
Backup en espejo o replicación en tiempo real
El backup en espejo replica las operaciones casi en tiempo real hacia otra base, servidor o entorno. Permite reducir de manera significativa la pérdida de datos y el tiempo de recuperación.
Sin embargo, se aclaró que estas soluciones tienen costos y exigencias técnicas importantes. Pueden ser accesibles para bancos, grandes cadenas, plataformas críticas o ciertas organizaciones con alta inversión tecnológica, aunque cada vez más empresas pequeñas y medianas pueden acceder a soluciones modernas de nube y replicación.
10. Regla 3-2-1
Se explicó la regla 3-2-1 como una práctica fundamental de resguardo.
La regla indica que deben existir tres copias de los datos, almacenadas en al menos dos medios diferentes, y una de ellas debe conservarse fuera del sitio principal de trabajo.
Esto busca evitar que un único incidente destruya simultáneamente el dato original y sus copias. Si todas las copias se encuentran en el mismo lugar físico, un incendio, robo, inundación, sabotaje o daño eléctrico podría afectar todo el esquema de recuperación.
La copia externa puede estar en otra sede, en una nube, en un centro de datos remoto o en un medio físico resguardado fuera de la organización. Lo importante es que no dependa del mismo espacio físico ni del mismo riesgo que afecta al entorno productivo.
11. Nube, almacenamiento remoto y offsite
Se diferenció el uso cotidiano de la nube del uso profesional de la nube como parte de una estrategia de backup. Guardar archivos en Google Drive, OneDrive o Dropbox no equivale necesariamente a tener una política formal de backup organizacional.
En una organización, el almacenamiento en nube debe formar parte de una política planificada: debe contemplar disponibilidad, seguridad, auditoría, restauración, tiempos de acceso, control de versiones, integridad de los datos y cumplimiento normativo.
También se explicó el concepto de offsite, es decir, una copia ubicada fuera del lugar físico donde se encuentran los sistemas principales. Este principio es esencial para evitar que el mismo desastre afecte tanto a los datos originales como a sus respaldos.
12. Restauración y prueba de backups
Se remarcó que restaurar no consiste simplemente en “copiar de vuelta” los datos. La restauración debe seguir una secuencia técnica correcta, especialmente cuando se combinan backups full, incrementales y diferenciales.
Además, luego de restaurar los sistemas, se deben verificar los datos, revisar la consistencia, validar transacciones y asegurar que la operatoria se haya recuperado correctamente.
La máxima central fue: backup que no se prueba, no existe. La organización debe realizar pruebas periódicas de restauración, idealmente en ambientes separados, para comprobar que las copias sirven efectivamente para volver a operar.
13. Estacionalidad, criticidad y momento del incidente
Se explicó que el impacto de una interrupción depende del momento en que ocurre. Una caída tecnológica durante una hora de baja actividad puede tener un impacto moderado, mientras que la misma caída durante un pico operativo puede generar consecuencias graves.
Se mencionaron ejemplos como bancos durante el horario de atención, supermercados en períodos de alta demanda, organizaciones educativas durante procesos de inscripción y empresas de retail durante vacaciones, fiestas o temporadas de alto consumo.
Por eso, las políticas de backup, recuperación y continuidad deben considerar la estacionalidad del negocio. No alcanza con definir tiempos generales: también se deben identificar ventanas críticas, momentos de congelamiento de sistemas, períodos de alta demanda y escenarios donde solo podrían aplicarse correcciones urgentes o hot fixes.
14. Responsabilidad de gestión
La clase enfatizó que, aunque la ejecución técnica del backup corresponda al área de sistemas, las decisiones principales son de gestión.
La administración debe definir qué datos son críticos, cuál es el RPO tolerable, cuál es el RTO aceptable, cuál es el MTD, qué procesos deben continuar durante una contingencia, qué costos se justifican y qué riesgos se aceptan.
El área de sistemas puede proponer soluciones, automatizar procesos, configurar copias, monitorear plataformas y ejecutar restauraciones. Sin embargo, no puede decidir por sí sola qué impacto tiene la pérdida de datos sobre el negocio. Esa valoración corresponde a quienes administran y gestionan los procesos organizacionales.
15. Conclusión
La clase consolidó la idea de que la protección de datos no es solo una cuestión técnica, sino una responsabilidad central de la gestión organizacional. La pérdida de información puede afectar la continuidad operativa, la reputación, la relación con clientes, el cumplimiento legal y la viabilidad de los procesos internos.
Por ello, toda organización debe contar con políticas de backup, mecanismos de restauración, planes de recuperación de desastres, planes de continuidad del negocio, criterios de clasificación de datos y pruebas periódicas de restauración.
La finalidad no es impedir absolutamente todos los incidentes, porque el riesgo cero no existe. La finalidad es reducir la probabilidad de ocurrencia, limitar el impacto, recuperar la operatoria en tiempos aceptables y asegurar que los datos esenciales de la organización puedan seguir sosteniendo sus procesos críticos.