Validar un restore M365 de OneDrive, SharePoint y Teams

En una recuperación M365 deben coincidir el objeto correcto, un punto de copia adecuado y un destino autorizado. Un archivo puede haberse escrito correctamente y aun así estar en el lugar equivocado o ser visible para personas incorrectas. Este procedimiento va, por tanto, desde un encargo acotado hasta la validación funcional para OneDrive, SharePoint y Teams.

Alcance y revisión, 29 de octubre de 2026: Se trata de Sophos Backup and Recovery M365 en el modelo de prestación operado por Rubrik. Los escenarios siguientes permiten planificar y comprobar un restore de alcance limitado. No confirman una disponibilidad general de determinadas opciones de destino, sobrescritura o recuperación. La ayuda específica de la carga y el diálogo mostrado deben corresponder al tenant propio.

Sophos Backup & Recovery M365: configuración y validación de un restore describe configuración, subscription, asignación de SLA y la prueba Exchange separada. El procedimiento siguiente presupone una copia ya configurada y no amplía los permisos Microsoft ni el alcance de producto contratado.

Delimitar el encargo de recuperación

Antes de acceder a un snapshot, se registran tenant origen, subscription y responsable. También el usuario o sitio afectado, la ruta exacta del objeto, el posible incidente de pérdida o cambio con zona horaria y el estado deseado. En un incidente de seguridad, el momento adecuado, aún no comprometido, debe acordarse con el responsable del incidente. La copia más reciente no es automáticamente la correcta.

En un piloto se utilizan exclusivamente cuentas de prueba autorizadas y datos de prueba inocuos. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt y Restore-Abnahme son ejemplos de usuario, archivo y destino de comprobación; no son objetos existentes del tenant. Antes de un encargo real se sustituyen por valores propios de prueba confirmados.

Se decide por escrito si los datos se necesitan en su ubicación original o separados de ella. No se elige otro usuario, sitio o subscription destino únicamente porque lo ofrezca el asistente. Los permisos, la región de datos y la responsabilidad del destino forman parte de la misma autorización.

Aclarar conflictos de archivos antes de escribir

En el destino pueden existir archivos con el mismo nombre, ediciones más recientes o documentos bloqueados. Antes de confirmar debe quedar claro si el procedimiento concreto sobrescribe, renombra, omite o crea una copia separada. No deducir estas variantes del comportamiento de un restore Exchange. En OneDrive, por ejemplo, Rubrik distingue resultados correctos y parciales y puede indicar objetos renombrados por conflictos de nombre. Eso no establece una regla general de conflictos para todas las cargas.

Si el efecto del modo ofrecido no es inequívoco, todavía no se inicia el restore. Primero se aclaran la ayuda específica de la carga y, si procede, el caso de soporte. Una recuperación in-place aparentemente rápida no debe sustituir una edición actual sin consentimiento.

Abrir el snapshot correcto y la ayuda de la carga

1. En Sophos Fusion (anteriormente Sophos Central), abrir My Products > Backup and Recovery M365. Tras la redirección, comprobar la organización Rubrik.
2. Abrir Inventory > SaaS > Microsoft 365. Identificar la subscription confirmada para el encargo; no adivinar por un nombre parecido.
3. Comprobar alcance de protección, asignación de SLA y copias existentes del objeto afectado. Un estado de integración verde no demuestra que exista un snapshot con la versión necesaria del archivo.
4. Antes de escribir, abrir el símbolo Help y, en Help Center, la ayuda correspondiente a la carga. Para SharePoint, el título documentado es Backup and recovery of SharePoint sites and site collections; para Teams, Teams data recovery. Para OneDrive, buscar OneDrive y la ruta de recuperación prevista en Help Center.
5. Contrastar el momento con el incidente y la zona horaria. Comparar el objeto seleccionado en el snapshot con el origen, la ruta y el contenido esperado. Antes del último paso de escritura, volver a contrastar origen, alcance, destino y comportamiento ante conflictos con el encargo.

Las comprobaciones siguientes no sustituyen la secuencia de clics exacta de la carga. Una opción documentada para Exchange, como Recover to a new folder, no garantiza que exista el mismo diálogo para OneDrive, SharePoint o Teams. Si la ayuda no corresponde al procedimiento ofrecido, se detiene la recuperación y se aclara la diferencia.

OneDrive: demostrar una versión concreta de archivo

Para un escenario de prueba acotado, la persona autorizada crea un archivo de texto inocuo con nombre inequívoco. Su contenido recibe primero el valor de comprobación Alpha. Después de un snapshot confirmado, el archivo se modifica a Bravo y se vuelve a copiar. Se anotan ambos momentos y la versión esperada en cada uno. Este escenario es un plan de comprobación, no un resultado de producto ya observado.

Para recuperar se elige deliberadamente el snapshot con Alpha. Antes de empezar se comprueban el usuario destino confirmado, la ruta completa y el tratamiento del archivo Bravo que ya existe. Si el procedimiento admite y se ha autorizado una copia separada, esta facilita la comparación. No se presupone ese modo; si la sobrescritura no está aclarada, no se continúa.

Después del encargo se comprueban primero el mensaje del trabajo y los recuentos de objetos, incluidas advertencias, errores parciales y cambios de nombre. A continuación, la persona de prueba abre el archivo realmente creado en el destino documentado. Debe contener el valor esperado. Si se utilizó otra carpeta destino u otro nombre, se registra esa ruta exacta. Un archivo intacto en la ubicación antigua no sirve como evidencia sustitutiva.

También se comprueban acceso y uso compartido: la persona de prueba prevista debe poder abrir el archivo; una cuenta de prueba sin autorización no debe obtener por ello un nuevo acceso. Probar un archivo de texto en un piloto no confirma todavía un restore completo de usuario ni la conservación de todos los enlaces compartidos o propiedades de archivos.

SharePoint: validar contenido, destino y propiedades por separado

En SharePoint, el encargo empieza con la URL exacta del sitio. Después se determina si hace falta un archivo, carpeta, biblioteca, lista o estructura más amplia. Una biblioteca con el mismo nombre en otro sitio es un destino distinto.

Para el piloto resulta adecuada una biblioteca de prueba autorizada con un archivo pequeño y un valor de comprobación anotado previamente. Si es relevante para el uso posterior, se documentan también un campo de metadatos y el grupo de permisos esperado. El snapshot debe contener exactamente esos datos de partida. Solo se confirma la recuperación del historial de versiones, estructura de listas o permisos individuales si forman parte del alcance seleccionado y se han comprobado por separado.

Antes del último paso de escritura se comprueban sitio destino, alcance de objetos y posibles colisiones con contenido actual. Si solo se necesita un archivo, no se recupera preventivamente un sitio entero. Tras el trabajo, la persona responsable comprueba contenido en el destino correcto, propiedades previstas y acceso. Que el portal Rubrik muestre un trabajo terminado no demuestra que una aplicación de negocio pueda utilizar la estructura recuperada.

Si la estructura del sitio ha cambiado entre el snapshot y el presente, se comprueban expresamente ruta origen y asignación destino. Si falta el destino o los permisos no están claros, no se crean cuentas, sitios ni roles adicionales por suposición. El encargo debe definir primero una ruta destino compatible y las responsabilidades necesarias.

Teams: no equiparar archivos y colaboración

El encargo «recuperar Teams» es demasiado impreciso. Debe indicar si se necesitan mensajes, un canal, archivos u otros contenidos. Microsoft documenta que los archivos de canales estándar residen en el sitio SharePoint del equipo; los canales privados y compartidos tienen sus propios sitios. Por tanto, el nombre del canal no basta para determinar el snapshot de archivos adecuado.

Para un piloto acotado se acuerdan un equipo de prueba autorizado, el tipo de canal y un contenido inocuo. Si se trata de un archivo de canal, se registran sitio SharePoint, biblioteca y archivo reales y se comprueban mediante el plan de validación SharePoint. Recuperar un archivo no confirma la recuperación de mensajes del canal, miembros, pestañas ni de toda la configuración Teams.

Si se necesitan mensajes o estructuras de canal, antes del restore se aclara en Teams data recovery qué tipos de objetos y destinos admite el estado concreto del servicio. Equipo origen, canal, snapshot y destino se documentan por separado. Después del encargo, un miembro de prueba autorizado comprueba el contenido necesario en Teams; para archivos sigue siendo necesaria la comprobación adicional de la ubicación real. Sin alcance confirmado y snapshot adecuado no se promete una recuperación completa general de Teams.

Registrar el resultado y terminar la prueba

El informe de validación registra objeto origen, hora del snapshot con zona horaria, destino, modo seleccionado y referencia trazable del trabajo. Incluye recuentos de objetos, advertencias, cambios de nombre, comprobaciones de contenido por muestreo, acceso y duración medida. Resultado esperado y resultado realmente observado permanecen separados.

Si el encargo muestra un error o un cierre incierto, no se inicia inmediatamente otra vez el mismo restore. Primero se aclara en el portal y en el destino si ya se han escrito datos. Incluso un éxito parcial puede haber creado o modificado objetos. Al escalar, indicar origen, momento, destino y mensaje depurado exactos; no copiar contenidos de archivos, credenciales ni exportaciones completas en tickets públicos.

Un restore no tiene un botón general para deshacer. Las copias de prueba adicionales solo se limpian después de validar y exclusivamente dentro del alcance de prueba acordado. Los archivos productivos, contenido de negocio recuperado o backups no constituyen un «rollback» general. Mientras no se confirme un contenido o permiso necesario, el encargo sigue pendiente, aunque el estado técnico del trabajo parezca correcto.