Points clés
- Microsoft ne garantit pas la récupération des données en cas de suppression accidentelle, de ransomware ou d’erreur de configuration. Des tests de sauvegarde et de restauration indépendants sont indispensables pour protéger vos données Microsoft 365.
- Vérifiez que des sauvegardes existent pour Exchange Online, OneDrive, SharePoint et Teams, avec des identifiants valides, des licences actives et un accès aux API sans interruption, afin d’éviter les faux échecs de restauration.
- Réalisez des tests de restauration au niveau de la charge de travail et au niveau de l’élément pour valider les besoins réels de récupération et confirmer que vos exigences de RTO (recovery time objective) et de RPO (recovery point objective) peuvent être respectées.
- Servez-vous de l’automatisation (PowerShell, API ou outils de sauvegarde) pour tester régulièrement les restaurations, surveiller leur réussite et consigner les résultats à des fins de conformité et d’audit.
Une sauvegarde ne vaut que par sa capacité à être restaurée. Ce guide vous explique pas à pas comment tester la capacité de restauration des charges de travail Microsoft 365, à savoir Exchange Online, SharePoint, OneDrive et Teams, à l’aide des outils Synology.
À la fin de cet article, vous saurez sécuriser vos données critiques et garantir que votre entreprise pourra les récupérer rapidement et de façon fiable en cas d’incident.
Vous préférez un résumé en vidéo ? Regardez notre vidéo « Comment tester la capacité de restauration des données Microsoft 365 avec les outils Synology » pour approfondir le sujet.
Comment tester la capacité de restauration
Méthode 1 : valider Synology Active Backup for Microsoft 365
📌 Cas d’usage : idéal pour tester les restaurations au niveau utilisateur et au niveau des charges de travail (Exchange, SharePoint, OneDrive, Teams)
📌 Prérequis :
- Un stockage en réseau NAS Synology avec Active Backup for Microsoft 365 (ABM365)
- Des tâches de sauvegarde configurées et terminées
- DSM et ABM365 mis à jour vers la dernière version
Étapes :
- Lancez Synology Active Backup for Microsoft 365 depuis l’interface de votre NAS.
- Ouvrez la liste des tâches pour confirmer l’état des sauvegardes :
- vérifiez les résultats des tâches et l’heure de la dernière exécution ;
- confirmez la taille de la sauvegarde et son statut (réussie ou échouée).
- Ouvrez le portail de restauration.
- Connectez-vous avec :
- des identifiants d’administrateur général ;
- ou des autorisations de restauration déléguées.
- Sélectionnez une charge de travail :
- une boîte aux lettres Exchange ;
- un fichier OneDrive ;
- un site SharePoint ;
- un message Teams.
- Choisissez un point de restauration et prévisualisez l’élément.
- Lancez la restauration, puis vérifiez que :
- le bon élément ou contenu a été restauré ;
- les autorisations et la structure ont été conservées ;
- aucune donnée n’est corrompue et aucun problème de visibilité n’apparaît.
💡 Conseil : servez-vous du volet de prévisualisation pour valider l’exactitude de chaque élément avant de lancer la restauration.
Méthode 2 : automatiser les contrôles avec PowerShell ou l’API REST
📌 Cas d’usage : cette méthode est utile lorsque vous souhaitez planifier des contrôles d’état ou mettre en place un reporting proactif sur les tâches de sauvegarde en échec ou inactives.
📌 Prérequis :
- PowerShell 5.1 ou version ultérieure installé (vérifiez votre version de PowerShell)
- Un accès par jeton à l’API Synology
- Un accès réseau au DSM Synology
Étapes :
- Ouvrez PowerShell en tant qu’administrateur.
- Exécutez cette commande :
Connect-VB365
Get-VBOJobSession | Where-Object { $_.Status -ne "Success" } |
Format-Table Name, Status, EndTime
- Vous pouvez aussi exécuter ce script bash sur le 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"
- Ajoutez une planification ou des alertes via :
- le Planificateur de tâches Windows ;
- le planificateur de tâches Synology ;
- l’automatisation des workflows NinjaOne.
💡 Conseil : déclenchez des alertes pour les tâches qui échouent, qui ne s’exécutent pas dans les 24 à 48 heures ou qui produisent des objets incomplets.
Méthode 3 : suivre les tests de restauration avec des clés de registre
📌 Cas d’usage : parfait si vous voulez suivre la fréquence des restaurations par appareil ou par tenant. Cette méthode sert aussi de complément pour prouver la conformité avec vos SLA (contrats de niveau de service) internes ou avec des obligations réglementaires.
📌 Prérequis :
- Un accès administrateur local au registre Windows
- Un système de sauvegarde dont les enregistrements de test sont accessibles
- Un exécuteur de scripts (NinjaOne, tâche PowerShell, etc.)
- Il est fortement recommandé de sauvegarder votre registre Windows. Des configurations incorrectes peuvent rendre le système instable.
Étapes :
- Appuyez sur Win + R, saisissez regedit, puis appuyez sur Entrée.
- Rendez-vous dans : HKEY_LOCAL_MACHINE\SOFTWARE\Org\BackupRestoreValidation
- Créez les valeurs suivantes :
- LastRestoreTestDate (chaîne) = « 2025-07-01T18:00:00Z »
- ToolUsed (chaîne) = « Synology ABM365 »
- Utilisez l’automatisation (avec NinjaOne ou PowerShell, par exemple) pour :
- lire les clés et repérer les tests en retard ;
- mettre à jour les valeurs à chaque test réalisé ;
- déclencher des alertes en cas de test en retard.
💡 Conseil : exportez les entrées de registre vers un serveur de journalisation centralisé ou un tableau de bord de conformité.
Méthode 4 : imposer des politiques de sauvegarde des terminaux par stratégie de groupe (clients Synology)
📌 Cas d’usage : cette méthode est utile pour éviter les suppressions accidentelles de fichiers, imposer l’utilisation des clichés instantanés de volume (VSS) ou protéger les terminaux utilisés dans des scénarios de restauration hybride.
📌 Prérequis :
- Un environnement de domaine Windows avec accès aux stratégies de groupe
- L’agent Synology installé (si vous sauvegardez aussi des fichiers locaux)
Étapes :
- Appuyez sur Win + R, saisissez gpedit.msc, puis appuyez sur Entrée.
- Rendez-vous dans : Configuration ordinateur > Modèles d’administration > Système > Protection de fichiers Windows
- Activez les paramètres suivants :
- Ne pas autoriser les utilisateurs à supprimer des fichiers système critiques
- Exiger le cliché instantané de volume pour toutes les sauvegardes locales
- Appliquez la GPO aux unités d’organisation (OU) concernées.
- Utilisez gpresult ou les journaux d’audit pour vérifier l’application de la GPO.
💡 Remarque : même si vous ne sauvegardez pas les fichiers des terminaux vers le Synology, ces paramètres évitent la perte de données critiques lors d’un écrasement accidentel ou d’une récupération en cas de ransomware.
Méthode 5 : vérifier l’accessibilité des fichiers de sauvegarde via CMD (invite de commande) ou CLI (interface en ligne de commande)
📌 Cas d’usage : cette méthode garantit que vos sauvegardes ne sont pas seulement « consignées », mais bien accessibles physiquement et exploitables. Elle permet de vérifier rapidement la présence et la taille du fichier de sauvegarde.
📌 Prérequis :
- Un accès au système de fichiers des répertoires de sauvegarde
- Un accès réseau ou par montage (SMB, iSCSI) aux partages Synology
Étapes :
A. Pour les partages de sauvegarde Synology (via SMB)
- Exécutez cette commande :
net use Z: \\synology\m365backup
dir Z:\backups\user01
B. Automatisez des scripts pour :
- vérifier les horodatages et la taille des fichiers ;
- confirmer la disponibilité des snapshots récents ;
- consigner ou alerter en cas de fichier manquant ou de taille insuffisante.
💡 Conseil : méfiez-vous des fichiers .vbcat incomplets ou des dossiers OneDrive/Teams manquants, qui peuvent signaler des sauvegardes en échec ou des identifiants expirés.
Autres points à prendre en compte pour tester la capacité de restauration
Périmètre de restauration
- Testez toujours les restaurations complètes et granulaires (par exemple, une boîte aux lettres entière contre un seul e-mail).
- Simulez des incidents réels : dossier SharePoint corrompu, conversation Teams supprimée, etc.
Expiration des identifiants
- Les jetons OAuth et Graph API expirent généralement au bout de 1 à 2 ans.
- Planifiez le renouvellement des identifiants et l’audit des autorisations d’API tous les 12 mois.
Licences
- Synology Active Backup restreint l’accès à certaines fonctionnalités si la licence n’est pas activée.
- Les tâches de sauvegarde peuvent continuer de s’exécuter alors que les droits de restauration ont expiré sans avertissement. Pensez à les valider souvent.
Gestion multi-tenant (pour les MSP)
- Suivez les tests de restauration client par client grâce à :
- l’étiquetage par métadonnées (dans NinjaOne ou dans les notes des tâches de restauration, par exemple) ;
- l’horodatage dans les journaux (via le registre) ;
- des tableaux de bord par tenant pour le reporting.
💡 Conseil : un test ponctuel est déjà utile, mais il vaut toujours mieux automatiser la vérification de la capacité de restauration pour réduire les risques. C’est aussi un point déterminant dans tout plan de sauvegarde et de récupération des données.
⚠️ Points de vigilance
| Risques | Conséquences possibles | Solutions |
| Des tâches de sauvegarde échouent sans avertissement à cause d’identifiants expirés | Aucune sauvegarde restaurable pendant des semaines, voire des mois | Réauthentifiez les identifiants de l’application dans Synology et relancez les tâches de sauvegarde complète. |
| Une tâche affichée comme « réussie » comporte des erreurs au niveau des objets | Boîtes aux lettres manquantes, fichiers corrompus ou couverture de sauvegarde partielle | Examinez les journaux des tâches et activez les notifications par e-mail ou les alertes PowerShell. |
| Le jeton OAuth ou les autorisations Graph API changent | Restaurations partielles ou en échec, en particulier pour Teams et SharePoint | Renouvelez le jeton et validez les autorisations de l’application régulièrement (une à deux fois par an). |
| Des sauvegardes sont stockées mais inaccessibles à cause d’une dérive des autorisations | Récupération impossible en cas d’incident | Auditez les listes de contrôle d’accès (ACL) du référentiel et les autorisations du portail de restauration. |
| Point de restauration trop ancien pour respecter le RTO (recovery time objective) ou le RPO (recovery point objective) | Manquements à la conformité ou réponse à incident incomplète | Planifiez des tests de restauration chaque semaine et automatisez l’horodatage avec le registre ou NinjaOne. |
| Les sauvegardes des terminaux sont exclues des workflows cloud | Perte de données pour les utilisateurs dont le workflow est hybride ou purement local | Utilisez les GPO et les agents Synology sur les terminaux pour imposer le périmètre de sauvegarde et la rétention. |
Résoudre les problèmes de restauration les plus courants
Accès refusé pendant une restauration Synology
Ce problème peut venir d’étendues Graph API mal configurées ou de jetons OAuth expirés. Pour y remédier, réautorisez le connecteur Microsoft 365 depuis DSM.
Assurez-vous toujours que le jeton d’application dispose des autorisations déléguées nécessaires (comme Mail.ReadWrite, Sites.ReadWrite.All, etc.) et qu’il n’a pas expiré.
Le portail de restauration Synology ne se charge pas
C’est souvent le signe d’un problème de compatibilité de version DSM ou de paramètres SSL/TLS incorrects. Pour y remédier, vérifiez que Synology DiskStation Manager (DSM) est mis à jour vers une version compatible avec votre environnement Microsoft 365 actuel.
De plus, confirmez que la liaison HTTPS est correctement configurée pour un accès sécurisé. Dans les environnements où l’accès HTTP est désactivé ou mal redirigé, le portail peut ne pas se charger du tout.
Des éléments manquent dans la sélection de restauration
Cela peut indiquer que les données n’ont jamais été correctement indexées ou qu’une tâche de sauvegarde a ignoré des objets clés en raison d’une mauvaise configuration. Ce cas se présente lorsque des utilisateurs viennent d’obtenir une licence, ont changé de groupe ou ont été exclus par un filtre.
Pour y remédier, relancez la sauvegarde manuellement et consultez les journaux pour repérer les utilisateurs ignorés ou les messages d’erreur. Vérifiez également que l’indexation est activée pour toutes les charges de travail.
La restauration expire ou se bloque
Cela traduit généralement des problèmes de performance du référentiel de sauvegarde ou une latence réseau excessive. Essayez d’isoler l’opération de restauration sur un disque plus rapide ou de déplacer temporairement la tâche vers un volume à haute disponibilité. Sur Synology, vérifiez que vos cartes réseau sont correctement agrégées ou attribuées et que vos connexions iSCSI ou SMB sont stables.
Comment NinjaOne vous aide à harmoniser la capacité de restauration entre tous vos tenants
- Déploiement de scripts PowerShell : diffusez facilement des scripts pour valider l’état des tâches Synology. Vous pouvez aussi détecter les sauvegardes en échec et produire un reporting sur l’historique des restaurations pour l’ensemble de vos terminaux et tenants.
- Audit du registre : NinjaOne peut analyser des clés de registre personnalisées (par exemple LastRestoreTestDate) et en rendre compte, afin de confirmer si les administrateurs locaux ou les agents ont bien effectué les tests de restauration dans les délais définis.
- Tableaux de bord personnalisés : NinjaOne vous offre une visibilité centralisée sur l’état de santé des tâches de sauvegarde, la dernière restauration réussie par tenant ou par appareil, ainsi que sur les lacunes en matière de fréquence de test ou de couverture des objets.
- Alertes inter-tenants : la plateforme déclenche automatiquement des alertes lorsque les validations de restauration sont en retard et que des sauvegardes échouent sans avertissement, ou encore lorsque des jetons OAuth ou des licences approchent de leur date d’expiration.
- Automatisation des workflows : reliez les contrôles de capacité de restauration à des tickets, des journaux ou des alertes. Intégrez les événements de validation de restauration à vos flux de reporting de conformité ou à votre documentation SLA (contrat de niveau de service).
Testez votre capacité de restauration avec les bons outils
Disons-le clairement : une sauvegarde ne sert à rien si elle ne peut pas être restaurée. C’est pourquoi tester la capacité de restauration n’est pas une option, mais une nécessité. Ce guide vous a donné les outils, les techniques et les pistes d’automatisation nécessaires pour garantir que vos données Microsoft 365 ne sont pas seulement sauvegardées, mais bien récupérables.
Sujets connexes :
