Puntos clave
- Microsoft no garantiza la recuperación ante borrados accidentales, ransomware o errores de configuración: necesitas pruebas independientes de copia de seguridad y restauración de Microsoft 365 para proteger tus datos.
- Comprueba que existen copias de seguridad de Exchange Online, OneDrive, SharePoint y Teams, con credenciales válidas, licencias activas y acceso continuo a la API, para evitar fallos de restauración ficticios.
- Realiza pruebas de restauración a nivel de carga de trabajo y de elemento individual para validar las necesidades reales de recuperación y asegurarte de que puedes cumplir los requisitos de RTO y RPO.
- Recurre a la automatización (PowerShell, APIs o herramientas de copia de seguridad) para probar las restauraciones con regularidad, vigilar los estados de éxito y registrar los resultados con fines de cumplimiento y auditoría.
Una copia de seguridad solo vale lo que vale su capacidad de restauración. Esta guía te explica paso a paso cómo probar la capacidad de restauración de las cargas de trabajo de Microsoft 365, es decir, Exchange Online, SharePoint, OneDrive y Teams, con las herramientas de Synology.
Al terminar este artículo sabrás proteger los datos críticos para el negocio y garantizar que tu organización puede recuperarlos de forma rápida y fiable cuando se produzca un incidente.
¿Prefieres un resumen en vídeo? Mira nuestro vídeo «Cómo probar la capacidad de restauración de los datos de Microsoft 365 con herramientas de Synology» para ampliar tus conocimientos.
Cómo probar la capacidad de restauración
Método 1: validar Synology Active Backup for Microsoft 365
📌 Casos de uso: ideal para probar restauraciones a nivel de usuario y de carga de trabajo (Exchange, SharePoint, OneDrive, Teams)
📌 Requisitos previos:
- NAS de Synology con Active Backup for Microsoft 365 (ABM365)
- Tareas de copia de seguridad configuradas y completadas
- DSM y ABM365 actualizados a la última versión
Pasos:
- Abre Synology Active Backup for Microsoft 365 desde la interfaz de tu NAS.
- Ve a Task List para comprobar el estado de las copias de seguridad:
- Revisa los resultados de las tareas y la hora de la última ejecución.
- Confirma el tamaño de la copia de seguridad y si ha terminado con éxito o con error.
- Abre el Restore Portal.
- Inicia sesión con una de estas opciones:
- Credenciales de administrador global
- Permisos de restauración delegados
- Selecciona una carga de trabajo:
- Buzón de Exchange
- Archivo de OneDrive
- Sitio de SharePoint
- Mensaje de Teams
- Elige un punto de restauración y previsualiza el elemento
- Ejecuta la restauración y comprueba lo siguiente:
- Se ha restaurado el elemento o contenido correcto
- Se conservan los permisos y la estructura
- No hay datos corruptos ni problemas de visibilidad
💡 Consejo: usa el panel de previsualización para validar la exactitud de cada elemento antes de restaurar.
Método 2: automatizar las comprobaciones con PowerShell o la API REST
📌 Casos de uso: este método resulta útil cuando necesitas programar comprobaciones de estado o generar informes proactivos sobre tareas de copia de seguridad fallidas o inactivas.
📌 Requisitos previos:
- PowerShell 5.1 o superior instalado (comprueba tu versión de PowerShell)
- Acceso al token de la API de Synology
- Acceso de red al DSM de Synology
Pasos:
- Abre PowerShell como administrador.
- Ejecuta este comando:
Connect-VB365
Get-VBOJobSession | Where-Object { $_.Status -ne «Success» } |
Format-Table Name, Status, EndTime
- Como alternativa, ejecuta este script de bash en Synology:
curl -X POST https://yourdiskstation:5001/webapi/entry.cgi \
-d «api=SYNO.Backup.M365.Status&version=1&method=list» \
-H "X-SYNO-TOKEN: your-session-token"
- Añade programación o alertas mediante:
- el Programador de tareas de Windows
- el Programador de tareas de Synology
- la automatización de flujos de trabajo de NinjaOne
💡 Consejo: entre los disparadores de alerta están las tareas que fallan, las que no se ejecutan en 24-48 horas y las que generan objetos incompletos.
Método 3: hacer seguimiento de las pruebas de restauración con claves del Registro
📌 Casos de uso: muy útil si quieres controlar la frecuencia de restauración por dispositivo o por tenant. También puedes usar este método como complemento para auditar el cumplimiento de los SLA internos o de las normativas aplicables.
📌 Requisitos previos:
- Acceso de administrador local al Registro de Windows
- Un sistema de copia de seguridad con registros de prueba accesibles
- Un ejecutor de scripts (como NinjaOne o una tarea de PowerShell)
- Te recomendamos encarecidamente que hagas una copia de seguridad del Registro de Windows. Una configuración incorrecta puede provocar inestabilidad en el sistema.
Pasos:
- Pulsa Win + R, escribe regedit y pulsa Intro.
- Ve a: HKEY_LOCAL_MACHINE\SOFTWARE\Org\BackupRestoreValidation
- Crea los siguientes valores:
- LastRestoreTestDate (cadena) = «2025-07-01T18:00:00Z»
- ToolUsed (cadena) = «Synology ABM365»
- Usa la automatización (por ejemplo, con NinjaOne o PowerShell) para:
- Leer las claves y detectar pruebas pendientes.
- Actualizar los valores cuando se realicen las pruebas.
- Lanzar alertas si una prueba se ha retrasado.
💡 Consejo: exporta las entradas del Registro a un servidor de logs centralizado o a un panel de cumplimiento.
Método 4: aplicar políticas de copia de seguridad de endpoints con directivas de grupo (para clientes de Synology)
📌 Casos de uso: este método sirve para evitar borrados accidentales de archivos, forzar el uso de instantáneas de volumen (VSS) o proteger los endpoints que intervienen en restauraciones híbridas.
📌 Requisitos previos:
- Entorno de dominio de Windows con acceso a las directivas de grupo
- Agente de Synology instalado (si también haces copia de seguridad de archivos locales)
Pasos:
- Pulsa Win + R, escribe gpedit.msc y pulsa Intro.
- Ve a: Configuración del equipo > Plantillas administrativas > Sistema > Protección de archivos de Windows
- Habilita los siguientes valores:
- No permitir que los usuarios eliminen archivos críticos del sistema
- Requerir instantáneas de volumen para todas las copias de seguridad locales
- Aplica el GPO a las unidades organizativas (OU) correspondientes.
- Usa gpresult o los registros de auditoría para verificar que el GPO se ha aplicado.
💡 Nota: aunque no estés copiando los archivos de los endpoints a Synology, estos ajustes evitan la pérdida de datos críticos ante una sobrescritura accidental o durante una recuperación de ransomware.
Método 5: verificar el acceso a los archivos de copia de seguridad con CMD o la CLI
📌 Casos de uso: este método garantiza que tus copias de seguridad no solo están «registradas», sino que son accesibles y utilizables de verdad. Te permite comprobar rápidamente que el archivo de copia de seguridad existe y qué tamaño tiene.
📌 Requisitos previos:
- Acceso al sistema de archivos de los directorios de copia de seguridad
- Acceso por red o montaje (SMB, iSCSI) a los recursos compartidos de Synology
Pasos:
A. Para recursos compartidos de copia de seguridad de Synology (por SMB)
- Ejecuta este comando:
net use Z: \\synology\m365backup
dir Z:\backups\user01
B. Automatiza scripts para:
- Comprobar las fechas y los tamaños de los archivos.
- Confirmar que hay instantáneas recientes disponibles.
- Registrar o avisar si faltan archivos o tienen un tamaño menor del esperado.
💡 Consejo: presta atención a los archivos .vbcat incompletos o a las carpetas de OneDrive y Teams que falten, porque pueden indicar copias de seguridad fallidas o credenciales caducadas.
Otros aspectos a tener en cuenta al probar la capacidad de restauración
Alcance de la restauración
- Prueba siempre restauraciones completas y granulares (por ejemplo, un buzón entero frente a un único correo).
- Simula incidentes reales: una carpeta de SharePoint corrupta, un chat de Teams eliminado, etc.
Caducidad de las credenciales
- Los tokens de OAuth y de Graph API suelen caducar cada 1 o 2 años.
- Programa la renovación de credenciales y la auditoría de permisos de la API cada 12 meses.
Licencias
- Synology Active Backup limita el acceso a determinadas funciones si no activas la licencia.
- Las tareas de copia de seguridad pueden seguir ejecutándose, pero los derechos de restauración pueden caducar sin avisar. Valídalos con frecuencia.
Gestión multitenant (para MSP)
- Haz seguimiento de las pruebas de restauración por cliente con:
- Etiquetado de metadatos (por ejemplo, en NinjaOne o en las notas de la tarea de restauración)
- Registro de marcas de tiempo (a través del Registro)
- Paneles por tenant para generar informes
💡 Consejo: probar una vez está bien, pero siempre es mejor automatizar la verificación de la capacidad de restauración para reducir riesgos. Es también un punto clave en cualquier plan de copia de seguridad y recuperación de datos.
⚠️ Aspectos a vigilar
| Riesgos | Posibles consecuencias | Soluciones |
| Las tareas de copia de seguridad fallan sin avisar porque las credenciales han caducado | No hay copias de seguridad restaurables durante semanas o meses | Vuelve a autenticar las credenciales de la aplicación en Synology y relanza las tareas de copia de seguridad completas. |
| La tarea aparece como «Success» pero tiene errores a nivel de objeto | Buzones que faltan, archivos corruptos o cobertura parcial de la copia de seguridad | Revisa los logs de la tarea y activa las notificaciones por correo o las alertas con PowerShell. |
| Cambian el token de OAuth o los permisos de Graph API | Restauraciones parciales o fallidas, sobre todo en Teams y SharePoint | Renueva el token y valida los permisos de la aplicación de forma periódica (una o dos veces al año). |
| Las copias de seguridad están guardadas pero no son accesibles por cambios en los permisos | Recuperación imposible durante un incidente | Audita las listas de control de acceso (ACL) del repositorio y los permisos del portal de restauración. |
| El punto de restauración es demasiado antiguo para cumplir el RTO o el RPO | Incumplimientos normativos o respuesta incompleta ante incidentes | Programa pruebas de restauración semanales y automatiza el registro de marcas de tiempo con el Registro o con NinjaOne. |
| Las copias de seguridad de los endpoints quedan fuera de los flujos del cloud | Pérdida de datos de los usuarios con flujos de trabajo híbridos o solo locales | Usa GPO y los agentes para endpoints de Synology para imponer el alcance y la retención de las copias de seguridad. |
Resolución de los problemas de restauración más habituales
Acceso denegado durante una restauración de Synology
Puede deberse a unos ámbitos de Graph API mal configurados o a tokens de OAuth caducados. Para solucionarlo, vuelve a autorizar el conector de Microsoft 365 desde DSM.
Asegúrate siempre de que el token de la aplicación tiene los permisos delegados necesarios (como Mail.ReadWrite, Sites.ReadWrite.All, etc.) y de que no ha caducado.
El portal de restauración de Synology no carga
Suele indicar problemas de compatibilidad de versiones de DSM o una configuración SSL/TLS incorrecta. Para solucionarlo, comprueba que Synology DiskStation Manager (DSM) está actualizado a una versión compatible con tu entorno actual de Microsoft 365.
Confirma además que el enlace HTTPS está bien configurado para garantizar un acceso seguro. En entornos donde el acceso HTTP está deshabilitado o mal redirigido, el portal puede no cargar en absoluto.
Faltan elementos en la selección de restauración
Esto puede indicar que los datos nunca se indexaron correctamente o que una tarea de copia de seguridad omitió objetos clave por un error de configuración. Suele pasar con usuarios que acaban de recibir licencia, que han cambiado de grupo o que quedan excluidos por algún filtro.
Para solucionarlo, vuelve a lanzar la copia de seguridad manualmente y revisa los logs en busca de usuarios omitidos o mensajes de error. Comprueba también que la indexación está activada para todas las cargas de trabajo.
La restauración se queda bloqueada o agota el tiempo de espera
Normalmente indica problemas de rendimiento en el repositorio de copias de seguridad o una latencia de red excesiva. Prueba a aislar la operación de restauración en un disco más rápido o a mover temporalmente la tarea a un volumen de alta disponibilidad. En Synology, comprueba que las NIC están correctamente agregadas o asignadas y que las conexiones iSCSI o SMB son estables.
Cómo NinjaOne te ayuda a unificar la capacidad de restauración en todos los tenants
- Despliegue de scripts de PowerShell: distribuye scripts con facilidad para validar el estado de las tareas de Synology. También puedes detectar copias de seguridad fallidas e informar del historial de restauraciones en todos los endpoints y tenants.
- Auditoría del Registro: NinjaOne puede analizar e informar sobre claves del Registro personalizadas (por ejemplo, LastRestoreTestDate) para confirmar si los administradores locales o los agentes han realizado las pruebas de restauración dentro de los intervalos definidos.
- Paneles personalizados: NinjaOne te da visibilidad centralizada del estado de las tareas de copia de seguridad, de la última restauración correcta por tenant o dispositivo y de las carencias en la frecuencia de pruebas o en la cobertura de objetos.
- Alertas entre tenants: la plataforma lanza alertas automáticamente cuando las validaciones de restauración se retrasan y las copias de seguridad fallan sin avisar. O cuando los tokens de OAuth o las licencias están a punto de caducar.
- Automatización de flujos de trabajo: vincula las comprobaciones de capacidad de restauración a tickets, logs o alertas. Integra los eventos de validación de restauraciones en los flujos de informes de cumplimiento o en la documentación de los SLA.
Prueba la capacidad de restauración con las herramientas adecuadas
Por obvio que parezca, una copia de seguridad no sirve de nada si no se puede restaurar. Por eso, probar la capacidad de restauración no es opcional: es imprescindible. Esta guía te ha dado las herramientas, las técnicas y las vías de automatización necesarias para que tu entorno de Microsoft 365 no solo tenga copias de seguridad, sino que sea recuperable de verdad.
Temas relacionados:
