Copias de seguridad que sí se pueden restaurar

Microsoft protege su servicio y replica su infraestructura, pero eso no es lo mismo que proteger tus datos. Es lo que se llama modelo de responsabilidad compartida: ellos responden de que la plataforma esté disponible, tú respondes del contenido.

En la práctica, los elementos recuperables tienen plazos limitados y un borrado hecho por un usuario, una salida de la empresa mal gestionada o un ataque con credenciales robadas pueden dejarte sin datos pasado ese plazo. Por eso recomendamos una copia externa de Exchange Online, OneDrive, SharePoint y Teams, con retención decidida por ti y almacenada fuera del propio tenant.

El RTO es cuánto tiempo puedes estar sin ese sistema antes de que el daño sea serio; el RPO es cuántas horas de trabajo estás dispuesto a rehacer. Si tu ERP tiene copia cada 24 horas, tu RPO es de un día entero de facturación y albaranes. Y si restaurar ese servidor lleva ocho horas, ese es tu RTO real, no el que figura en el contrato. Fijar los dos números por sistema es lo que convierte el backup en una decisión de negocio en lugar de en una configuración técnica.

Añaden coste de almacenamiento, porque el dato no se puede borrar antes de tiempo aunque quieras liberar espacio, y obligan a dimensionar mejor la retención. A cambio, son la única defensa que sigue en pie cuando el atacante ya tiene credenciales de administrador. Nuestra recomendación habitual es aplicar inmutabilidad al conjunto crítico con una ventana corta y mantener retenciones largas en almacenamiento más barato para lo demás.

Depende de la criticidad, pero como norma trimestral para los sistemas centrales y anual para el resto, además de cada vez que se cambia algo importante en la infraestructura. La prueba tiene que incluir el tiempo que ha tardado: descubrir el día del incidente que restaurar el servidor de ficheros lleva dos jornadas es exactamente el escenario que se quiere evitar.

Como copia local rápida es una pieza útil, pero no es suficiente por sí sola. Está en el mismo edificio, así que no cubre incendio, robo ni inundación, y si está integrado en el dominio con credenciales compartidas es alcanzable por el mismo ransomware que cifre los servidores. Un NAS bien configurado, con cuenta dedicada, snapshots y replicación a un destino externo, sí es una buena base.

El inventario y la definición de RTO y RPO suelen llevar una o dos semanas, porque exigen hablar con cada área. La implantación depende del volumen: la primera copia completa a la nube de varios terabytes puede tardar días y se planifica para no saturar la línea. A partir de ahí las copias son incrementales y el impacto en la red es mucho menor.

La frecuencia la marca el RPO: cuántas horas de trabajo podéis permitiros rehacer. En la mayoría de pymes, los ficheros y las bases de datos de trabajo necesitan como mínimo una copia diaria, y los sistemas donde se factura o se registra la producción suelen pedir copias cada pocas horas o instantáneas a lo largo del día. Los servidores completos pueden copiarse con menos frecuencia si los datos que contienen ya se copian por separado. Lo importante es fijarlo sistema por sistema, no con un único horario para todo, y que al menos una copia esté fuera de la oficina y no se pueda borrar desde la red de la empresa.

Depende casi por completo de cómo estaban las copias antes del incidente. Con copias recientes, probadas y fuera del alcance de un atacante, recuperar un servidor o unos buzones es cuestión de horas. Sin ellas, la recuperación se mide en días o semanas, cuando es posible: rehacer documentos, pedir copias a clientes y proveedores y reconstruir sistemas desde cero. Por eso insistimos en las pruebas de restauración: son la única forma de saber de antemano cuánto tardaríais, en lugar de descubrirlo en mitad del incidente.