Vérifier une restauration M365 pour OneDrive, SharePoint et Teams

Une restauration M365 doit faire correspondre le bon objet, un point de sauvegarde adapté et une cible approuvée. Un fichier peut avoir été réécrit avec succès tout en se trouvant au mauvais endroit ou en étant visible par les mauvaises personnes. Cette procédure va donc de la demande délimitée à la validation fonctionnelle pour OneDrive, SharePoint et Teams.

Périmètre et état de vérification au 29 octobre 2026 : il s’agit de Sophos Backup and Recovery M365 dans le modèle de déploiement exploité par Rubrik. Ces scénarios permettent de planifier et de valider le périmètre de restauration. Ils ne confirment pas la disponibilité générale d’options particulières de cible, d’écrasement ou de restauration. L’aide propre à la charge et le dialogue affiché doivent correspondre au tenant utilisé.

Sophos Backup & Recovery M365 : configurer et vérifier une restauration décrit la configuration, l’abonnement, l’affectation SLA et le test Exchange distinct. La procédure suivante suppose une sauvegarde configurée et n’étend ni les autorisations Microsoft ni le périmètre du produit commandé.

Délimiter la demande de restauration

Avant d’accéder à un snapshot, consigner tenant source, abonnement et responsable. Ajouter l’utilisateur ou le site concerné, le chemin exact de l’objet, l’événement présumé de perte ou de modification avec son fuseau horaire et l’état souhaité. Lors d’un incident de sécurité, convenir avec le responsable de l’incident d’un point adapté, encore non compromis. La sauvegarde la plus récente n’est alors pas automatiquement la bonne.

Un pilote utilise exclusivement des comptes de test approuvés et des données inoffensives. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt et Restore-Abnahme sont des exemples d’utilisateur de test, de fichier et de cible de vérification souhaitée ; ils ne désignent pas des objets existants du tenant. Avant une demande réelle, les remplacer par des valeurs de test propres et confirmées.

Décider par écrit si les données sont nécessaires à leur emplacement d’origine ou séparément. Ne pas choisir un autre utilisateur cible, site ou abonnement simplement parce que l’assistant le propose. Autorisations, région des données et responsabilité de la cible font partie de la même approbation.

Clarifier les conflits de fichiers avant l’écriture

La cible peut déjà contenir des fichiers de même nom, des modifications plus récentes ou des documents verrouillés. Avant confirmation, il faut donc savoir si la procédure précise écrase, renomme, ignore ou crée une copie séparée. Ne pas déduire ces variantes du comportement d’une restauration Exchange. Rubrik distingue par exemple les résultats complets et partiels pour OneDrive et peut signaler des objets renommés en raison de conflits de noms. Cela ne définit pas une règle générale de conflit pour toutes les charges.

Si l’effet du mode proposé n’est pas clair, ne pas encore lancer de restauration. Clarifier d’abord l’aide propre à la charge et, si nécessaire, le dossier de support. Une restauration sur place prétendument rapide ne doit pas remplacer un travail actuel sans accord.

Ouvrir le bon snapshot et l’aide propre à la charge

1. Dans Sophos Fusion (anciennement Sophos Central), ouvrir My Products > Backup and Recovery M365. Après la redirection, contrôler l’organisation Rubrik.
2. Ouvrir Inventory > SaaS > Microsoft 365. Déterminer l’abonnement confirmé pour la demande ; ne pas le deviner à partir d’un nom d’affichage ressemblant.
3. Contrôler le périmètre protégé, l’affectation SLA et les sauvegardes disponibles de l’objet concerné. Un état d’intégration vert ne prouve pas encore l’existence d’un snapshot contenant la version de fichier requise.
4. Avant toute demande d’écriture, ouvrir l’icône Help, puis dans le Help Center l’aide correspondant à la charge. Pour SharePoint, le titre documenté est Backup and recovery of SharePoint sites and site collections ; pour Teams, Teams data recovery. Pour OneDrive, rechercher OneDrive et le parcours de restauration prévu dans le Help Center.
5. Comparer l’heure à l’événement et au fuseau horaire. Vérifier l’objet sélectionné dans le snapshot par rapport à la source, au chemin et au contenu attendu. Avant la dernière étape d’écriture, rapprocher encore source, périmètre, cible et gestion des conflits de la demande.

Les vérifications suivantes ne remplacent pas la séquence de clics précise pour chaque charge. Une sélection documentée pour Exchange, comme Recover to a new folder, ne garantit pas l’existence du même dialogue pour OneDrive, SharePoint ou Teams. Si l’aide ne correspond pas au parcours proposé, arrêter avant la restauration et clarifier l’écart.

OneDrive : prouver une version de fichier précise

Dans un scénario de test limité, la personne de test autorisée crée un fichier texte inoffensif au nom unique. Son contenu reçoit d’abord la valeur de contrôle Alpha. Après confirmation d’un snapshot, le fichier est modifié en Bravo et sauvegardé à nouveau. Noter les deux heures et la version attendue à chacune. Ce scénario est un plan de vérification, pas un résultat produit déjà observé.

Pour la restauration, choisir volontairement le snapshot contenant Alpha. Avant le lancement, vérifier l’utilisateur cible confirmé, le chemin complet et le traitement du fichier Bravo désormais présent. Si la procédure choisie prend en charge et autorise une copie séparée, celle-ci facilite la comparaison. Ce mode n’est pas supposé disponible ; ne pas poursuivre si l’écrasement reste incertain.

Après la demande, vérifier d’abord le message du job et le nombre d’objets, y compris avertissements, échecs partiels et renommages. La personne de test ouvre ensuite le fichier réellement créé à la cible documentée. Il doit contenir la valeur de contrôle attendue. Si un dossier cible supplémentaire ou un autre nom de fichier a été utilisé, consigner précisément ce chemin. Un fichier inchangé à son ancien emplacement ne constitue pas une preuve de substitution.

Contrôler aussi accès et partages : la personne de test prévue doit pouvoir ouvrir le fichier ; un compte de test non autorisé ne doit pas obtenir un nouvel accès à cette occasion. Un fichier texte vérifié dans un pilote ne confirme ni une restauration utilisateur complète ni la conservation de tous les liens de partage ou propriétés du fichier.

SharePoint : valider séparément contenu, cible et propriétés

Une demande SharePoint commence par l’URL exacte du site. Déterminer ensuite si le besoin porte sur un fichier, un dossier, une bibliothèque, une liste ou une structure plus étendue. Une bibliothèque de même nom dans un autre site est une autre cible.

Pour le pilote, utiliser une bibliothèque de test approuvée avec un petit fichier et une valeur de contrôle notée au préalable. Si cela compte pour l’usage ultérieur, documenter aussi un champ de métadonnées et le groupe d’autorisation attendu. Le snapshot doit contenir exactement ces données initiales. Un historique des versions, une structure de liste ou une autorisation individuelle n’est confirmée comme restaurée que si elle appartient au périmètre sélectionné et a été vérifiée séparément.

Avant la dernière écriture, contrôler site cible, périmètre des objets et collisions possibles avec des contenus actuels. Si un seul fichier est requis, ne pas restaurer préventivement un site entier. Après le job, le responsable vérifie le contenu à la bonne cible, les propriétés prévues et l’accès. Un job terminé dans le portail Rubrik ne prouve pas encore qu’une application métier peut fonctionner avec la structure restaurée.

Si la structure du site diffère entre le snapshot et le présent, contrôler explicitement chemin source et correspondance cible. Si la cible manque ou si les droits restent incertains, ne pas créer de comptes, sites ou rôles supplémentaires à l’aveugle. La demande doit d’abord établir le parcours cible pris en charge et les responsabilités nécessaires.

Teams : distinguer fichiers et collaboration

Une demande « restaurer Teams » est trop vague. Elle doit préciser s’il faut des messages, un canal, des fichiers ou d’autres contenus. Microsoft indique que les fichiers des canaux standard se trouvent dans le site SharePoint de l’équipe ; les canaux privés et partagés possèdent leurs propres sites. Le nom du canal ne suffit donc pas à déterminer le bon snapshot de fichiers.

Pour un pilote limité, convenir d’une équipe de test approuvée, du type de canal et d’un contenu de test inoffensif. S’il s’agit d’un fichier de canal, relever le véritable site SharePoint, la bibliothèque et le fichier, puis les vérifier selon le plan de validation SharePoint. Un fichier récupéré ne confirme pas la restauration des messages du canal, des appartenances, des onglets ou de toute la configuration Teams.

Si des messages ou structures de canaux sont nécessaires, clarifier avant restauration dans Teams data recovery les types d’objets et cibles pris en charge par l’état de déploiement précis. Documenter séparément équipe source, canal, snapshot et cible. Après la demande, un membre de test autorisé vérifie le contenu requis dans Teams ; pour les fichiers, une vérification supplémentaire de l’emplacement réel reste nécessaire. Sans périmètre confirmé et snapshot adapté, ne pas promettre une restauration Teams complète et universelle.

Consigner le résultat et terminer le test

Le rapport de validation consigne objet source, heure du snapshot avec fuseau, cible, mode choisi et référence traçable du job. Ajouter nombres d’objets, avertissements, renommages, échantillon de contenu vérifié, accès et durée mesurée. Résultat attendu et résultat réellement observé restent distincts.

Si une demande affiche une erreur ou une fin incertaine, ne pas lancer immédiatement la même restauration. Clarifier d’abord dans le portail et à la cible si des données ont déjà été écrites. Même une réussite partielle peut avoir créé ou modifié des objets. Lors d’une escalade, fournir source précise, heure, cible et message expurgé ; ne pas copier contenu de fichiers, identifiants ou exports complets dans des tickets publics.

Une restauration n’a pas de bouton d’annulation universel. Les copies de test supplémentaires ne sont nettoyées qu’après validation et uniquement dans le périmètre de test convenu. Fichiers de production, contenus métier restaurés ou sauvegardes ne sont pas un « retour arrière » général. Tant qu’un contenu ou une autorisation nécessaire n’est pas confirmé, la demande reste ouverte, même si l’affichage technique du job paraît réussi.