OneDrive « sauvegarde » n’est pas une sauvegarde : comment bien faire

février 13, 2026 • février 13, 2026 • Lecture : 30 min • Views: 0

Cet article vous a aidé ?

Quelqu’un supprime un dossier. Ou un ordinateur portable est chiffré. Ou un script d’exclusion d’employé « range » un compte un peu trop agressivement. Soudain l’équipe découvre une vérité gênante : ce qu’elle appelait « sauvegarde » est surtout une synchronisation avec un autocollant marketing.

OneDrive excelle à déplacer des fichiers et à les rendre disponibles partout. Par défaut, ce n’est pas un système de sauvegarde complet avec les garanties dont vous avez réellement besoin quand des données de production deviennent une scène d’incident.

Ce que fait réellement la « sauvegarde » OneDrive (et ce qu’elle ne fait pas)

Le client OneDrive de Microsoft propose une fonctionnalité qui « protège » des dossiers connus comme Bureau, Documents et Images en les redirigeant vers OneDrive et en les synchronisant dans le cloud. Dans de nombreuses organisations, cela est positionné, communiqué et perçu comme une « sauvegarde ».

Opérationnellement, il s’agit de redirection de dossiers plus synchronisation. Cela peut être utile. Cela peut aussi être catastrophique quand vous le traitez comme une machine à remonter le temps.

Ce qu’il fait bien

Atténuation de la perte d’appareil : l’ordinateur portable tombe en panne, les fichiers sont toujours dans le cloud (si ils avaient été complètement synchronisés).
Disponibilité multi-appareils : les fichiers apparaissent rapidement sur d’autres appareils.
Historique des versions (partiel) : OneDrive et SharePoint peuvent conserver des versions pendant une période, selon la configuration.
Corbeille : il existe un modèle de corbeille à deux niveaux dans SharePoint/OneDrive avec des fenêtres de rétention configurables (avec réserves).

Ce que cela ne garantit pas

Isolation : si un malware chiffre un dossier synchronisé, OneDrive synchronisera le chiffrement sans broncher.
Rétention indépendante : de nombreux comportements de rétention dépendent des politiques et des licences, et ils ne remplacent pas une sauvegarde.
Restauration à un point dans le temps : la granularité de restauration peut être limitée ; ce n’est pas conçu pour remettre l’ensemble d’un jeu de données à un instant connu sur plusieurs utilisateurs.
Sécurité contre l’administrateur : un administrateur privilégié avec un script inapproprié peut supprimer du contenu et purger les corbeilles plus vite que vous ne pouvez dire « demande de changement ».
Résilience au cycle de vie des comptes : la suppression d’un utilisateur, la suppression d’une licence ou des modifications de la configuration du locataire peuvent déclencher des comportements de rétention non adaptés aux sauvegardes.

Si vous retenez une chose : OneDrive est une couche de synchronisation orientée productivité. Les sauvegardes sont un contrôle d’ingénierie. Objectifs différents. Modes de défaillance différents. Outils différents.

Synchronisation vs sauvegarde : la différence qui ruine votre journée

La synchronisation est un miroir. La sauvegarde est un enregistrement.

La synchronisation cherche à faire correspondre deux états. La sauvegarde préserve les états antérieurs même quand l’état courant est erroné, malveillant ou supprimé accidentellement. Cette différence explique pourquoi votre « sauvegarde » peut reproduire fidèlement votre catastrophe à la vitesse du gigabit.

Une sauvegarde a des propriétés que la synchronisation n’a pas

Immutabilité (ou résistance à la falsification) : les attaquants ne devraient pas pouvoir la supprimer ou la chiffrer facilement.
Frontière d’authentification indépendante : si Azure AD est compromis, vos sauvegardes ne doivent pas tomber comme des dominos.
Rétention définie : périodes de rétention explicites alignées sur les objectifs de reprise et les besoins de conformité.
Restaurations vérifiables : vous exercez la restauration. Vous la mesurez. Vous savez qu’elle fonctionne.

Blague n°1 : Si votre « sauvegarde » se supprime quand vous supprimez le fichier, ce n’est pas une sauvegarde. C’est un complice très poli.

Modes de défaillance : comment la « sauvegarde » OneDrive échoue en pratique

1) Ransomware et chiffrement massif

Les ransomwares ciblant les postes ont appris le modèle économique : chiffrer les fichiers locaux gérés par les clients de sync, puis laisser le client synchroniser les dommages. Certaines variantes ciblent même spécifiquement les répertoires synchronisés avec le cloud.

L’historique des versions peut aider. Mais l’historique n’est pas infini, et il n’est pas conçu comme votre plan unique de reprise après ransomware. De plus, le ransomware peut toucher un grand nombre de fichiers très rapidement, vous poussant dans des throttles, des conflits de synchronisation et des restaurations partielles.

2) Suppression accidentelle devenue « autoritaire »

Supprimez localement, ça supprime dans le cloud. Supprimez dans le cloud, ça supprime localement. La fonctionnalité fait ce pour quoi elle a été conçue. Votre processus est ce qui est cassé.

La corbeille peut vous sauver. À moins qu’elle n’ait été purgée. À moins que la rétention n’ait expiré. À moins que le fichier soit trop volumineux pour certains flux de travail. À moins que le compte n’ait été supprimé et que l’horloge de rétention n’ait démarré d’une manière inattendue.

3) Compromission de compte et suppression « légitime »

Si un attaquant accède au compte d’un utilisateur (ou d’un administrateur), il peut supprimer des fichiers d’une manière qui ressemble à une activité utilisateur normale. Beaucoup d’organisations découvrent trop tard que leur chemin de récupération suppose que l’attaquant n’a pas aussi vidé les corbeilles ou manipulé les paramètres de rétention.

4) Risque interne et scripts de « nettoyage »

L’automatisation de l’exclusion d’employés est nécessaire. C’est aussi une source récurrente de blessures auto-infligées. Un script qui supprime des licences et des comptes peut aussi supprimer l’accès au contenu OneDrive ou déclencher des politiques de suppression.

5) Synchronisation cassée = perte silencieuse de données

Les échecs de synchronisation OneDrive n’ont souvent pas l’air d’échecs. Ils ont l’air de « tout va bien » jusqu’à ce que vous tentiez une restauration et que vous découvriez que le dossier crucial n’a jamais été téléversé.

Files On-Demand, longueur de chemin, caractères non autorisés, fichiers verrouillés et bugs clients peuvent laisser des trous. Si vous ne surveillez pas la santé de la synchronisation, vous n’avez pas une sauvegarde ; vous avez de l’espoir.

6) Rétention juridique/conformité ≠ sauvegarde

Les politiques de rétention et les holds juridiques visent la préservation et la découvrabilité, pas la récupération opérationnelle. Elles peuvent préserver des données difficiles à restaurer à grande échelle. Elles peuvent aussi augmenter les coûts de stockage et compliquer la suppression, ce qui est utile pour les enquêtes et ennuyeux pendant les incidents.

7) Événements au niveau du locataire et dérive de configuration

La plupart des fonctionnalités « filet de sécurité » OneDrive sont configurables au niveau du locataire. Les politiques changent. Les licences changent. Les paramètres par défaut changent. Quand la direction dit « On a déjà une sauvegarde, c’est OneDrive », ce qu’elle veut souvent dire est « On a activé une fonction une fois et on ne l’a jamais validée de nouveau. »

Faits et contexte intéressants : pourquoi cette confusion perdure

Fait 1 : « Known Folder Move » (redirection des dossiers Desktop/Documents/Images) est devenu une poussée d’entreprise grand public à l’ère de Windows 10, souvent présenté comme une « protection » parce qu’il réduisait les incidents de perte de portable.
Fait 2 : Le modèle de corbeille de SharePoint/OneDrive est à deux étapes ; le contenu peut passer de la corbeille utilisateur à une corbeille administrateur de second niveau, mais les deux sont limités par des fenêtres de rétention et ne remplacent pas une sauvegarde à long terme.
Fait 3 : L’historique des versions existe en partie parce que la collaboration sur des documents Office nécessitait la gestion des conflits et le retour en arrière — pas parce que Microsoft voulait construire un produit de sauvegarde.
Fait 4 : Le « modèle de responsabilité partagée » dans les services cloud existe depuis des décennies ; les fournisseurs SaaS protègent le service, mais les clients restent responsables de la protection des données et de la planification de la reprise.
Fait 5 : Les anciens outils de synchronisation grand public (avant l’ère du cloud) ont appris aux utilisateurs que « vos fichiers sont partout », ce qui a conditionné la perception que « partout » équivaut à « sûr ». Ce n’est pas vrai.
Fait 6 : Les opérateurs de ransomware conçoivent de plus en plus des campagnes autour d’environnements synchronisés cloud car la propagation amplifie l’impact et accélère le levier de pression.
Fait 7 : Les entreprises se reposaient historiquement sur des serveurs de fichiers avec rotation de bandes ; la migration vers le SaaS a supprimé les indices physiques (« la bande existe ») et les a remplacés par des indices d’interface (« l’icône du fichier est verte »).
Fait 8 : La leçon douloureuse initiale pour beaucoup d’organisations est que « rétention » et « sauvegarde » sont des mots différents pour des problèmes différents — les auditeurs s’intéressent à l’un, les intervenants aux incidents à l’autre.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une société de services professionnels de taille moyenne a migré d’un serveur de fichiers legacy vers un « modern workplace ». Le discours était clair : OneDrive pour les fichiers personnels, SharePoint pour les équipes, et « la sauvegarde est intégrée ». L’IT l’a accepté car les budgets étaient serrés et le calendrier de migration plus serré encore.

Des mois plus tard, un employé senior a essayé de réorganiser une archive client et a glissé un dossier de haut niveau au mauvais endroit. Des milliers de fichiers ont été déplacés. Le client de synchronisation a fait exactement ce pourquoi il est conçu : il a synchronisé le déplacement sur les appareils. Les permissions SharePoint ont changé avec le nouvel emplacement, et soudain une partie du personnel n’avait plus accès à ce dont il avait besoin.

Ils ont tenté de « restaurer depuis la sauvegarde » et ont découvert que l’organisation n’avait pas de sauvegarde indépendante. Il y avait un historique de versions pour des documents Office individuels, mais pas de moyen simple et fiable de « remettre tout l’arbre de dossiers exactement comme hier à 17h ». La corbeille a aidé pour les suppressions, mais c’était un déplacement. Un autre domaine.

La récupération s’est transformée en exercice d’investigation lent : exporter les journaux d’audit, cartographier les opérations de déplacement et les inverser manuellement par lots tout en limitant le locataire pour que les clients de sync ne ré-brisent pas la situation. Ça a fonctionné, mais ça a pris un week-end. La cause racine n’était pas l’erreur utilisateur ; les utilisateurs font des choses d’utilisateurs. La cause racine était de traiter la synchronisation comme une stratégie de récupération.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe IT d’entreprise voulait réduire la croissance du stockage. Ils ont durci la rétention des corbeilles OneDrive et réduit la profondeur de l’historique des versions, estimant que « les vraies données vivent dans SharePoint de toute façon ». Ils ont aussi déployé Files On-Demand agressivement pour économiser l’espace disque sur les endpoints, ce qui était une victoire pour la gestion des appareils.

Puis un incident de ransomware a frappé quelques endpoints. Ce n’était pas sophistiqué — juste efficace. Les attaquants ont chiffré le contenu local « disponible hors ligne ». La synchronisation OneDrive a commencé à téléverser les changements. Certains utilisateurs ont débranché, mais d’autres non. Désormais ils avaient une propagation de contenu corrompu à travers le locataire.

L’équipe IT s’attendait à ce que l’historique des versions les sauve. Mais ils avaient réduit le nombre de versions. Ils s’attendaient à ce que les corbeilles les sauvent. Mais ils avaient raccourci la rétention. Ils s’attendaient à ce que le « cloud signifie récupérable ». Mais leur propre optimisation avait supprimé la marge de sécurité.

Ils ont récupéré la plupart des données, mais cela a exigé une combinaison désordonnée de restaurations partielles, d’actions « Restaurer votre OneDrive » utilisateur par utilisateur et beaucoup de validation manuelle. La leçon n’était pas « ne jamais optimiser ». C’était « n’optimisez pas au point de supprimer votre seul mécanisme de retour en arrière, surtout si vous n’avez pas encore construit une vraie sauvegarde ».

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation — ennuyeuse, dans le bon sens — utilisait un produit tiers de sauvegarde Microsoft 365 qui extrayait le contenu OneDrive et SharePoint vers un stockage objet avec immutabilité. Ils appliquaient des identifiants séparés et MFA, et testaient les restaurations chaque trimestre. Personne ne célébrait cela. C’est ainsi que vous savez que c’est sain.

Le compte d’un sous-traitant a été compromis par réutilisation d’identifiants. L’attaquant a supprimé un morceau de contenu OneDrive puis vidé la corbeille. Il a aussi tenté de créer des règles de transfert dans les mails, car les criminels sont imprévisibles mais prévisibles.

L’équipe sécurité a contenu le compte rapidement, mais les suppressions avaient déjà eu lieu. La différence tenait au chemin de restauration : le SRE a extrait les journaux des jobs de sauvegarde, identifié la dernière sauvegarde réussie avant la fenêtre de compromission et restauré les dossiers impactés dans un emplacement de quarantaine. Les responsables métier ont alors validé l’intégrité et remis le contenu en place.

Le rapport d’incident était presque ennuyeux : détection, confinement, restauration, validation, prévention. Pas de « nous ne savions pas ». Pas de « nous pensions que OneDrive était une sauvegarde ». Juste un mardi désagréable, géré comme des adultes.

Guide de diagnostic rapide : trouvez rapidement le goulot d’étranglement

Quand les gens disent « la sauvegarde OneDrive a échoué », ils veulent généralement dire une des trois choses : la synchronisation n’a jamais été complète, la restauration n’est pas possible à la granularité requise, ou la rétention a avalé ce dont ils avaient besoin. Ne devinez pas. Triez.

Première étape : identifiez la cible de récupération et la fenêtre temporelle

Question : Qu’est-ce qui doit être récupéré exactement — un fichier unique, un arbre de dossiers, tout le disque d’un utilisateur, ou plusieurs utilisateurs ?
Question : Quel est le dernier instant « sain » connu ? Avant le chiffrement ? Avant la suppression ? Avant la migration ?
Décision : Si vous ne pouvez pas définir le point de restauration, vous faites de l’archéologie, pas de l’intervention d’incident.

Deuxième étape : décidez du mécanisme sur lequel vous vous appuyez

Option A : corbeille OneDrive/SharePoint
Option B : « Restaurer votre OneDrive » (rollback massif)
Option C : historique des versions
Option D : exports de découverte par rétention/hold juridique
Option E : système de sauvegarde indépendant (recommandé)

Décision : Si votre seule option est « demander aux utilisateurs de restaurer depuis leur propre corbeille », vous n’avez pas de processus de récupération d’entreprise.

Troisième étape : vérifiez les trois goulots d’étranglement courants

Frontière d’authentification : Êtes-vous verrouillé ? Le compte est-il supprimé ? Le MFA est-il cassé ? L’accès au locataire est-il compromis ?
Disponibilité des données : Le contenu a-t-il déjà synchronisé ? Est-il dans OneDrive ? Est-il uniquement local ? Est-il en état de conflit ?
Fenêtre de rétention : Êtes-vous hors de la fenêtre de corbeille/historique de versions à cause de changements de politique ou du temps écoulé ?

Quatrième étape : vérifiez l’étendue avant de « tout restaurer »

Les restaurations massives sont séduisantes. Elles écrasent aussi le travail légitime récent. Préférez la restauration vers un emplacement alternatif quand c’est possible, puis basculez après validation.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des tâches pratiques que vous pouvez exécuter depuis un serveur admin ou de sauvegarde pour réduire les suppositions. Elles supposent que vous avez accès à Microsoft Graph via une application enregistrée (par exemple en utilisant Azure CLI pour les tokens) et que vous stockez des exports/sauvegardes sur Linux. L’objectif n’est pas de faire de vous un expert Graph ; c’est de rendre les défaillances observables.

Task 1: Confirm you can get a Graph token (auth boundary check)

cr0x@server:~$ az account show
{
  "environmentName": "AzureCloud",
  "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "name": "Prod-IT-Subscription",
  "state": "Enabled",
  "tenantId": "11111111-2222-3333-4444-555555555555",
  "user": {
    "name": "backup-operator@corp.example",
    "type": "user"
  }
}

Ce que cela signifie : Vous êtes authentifié dans le bon contexte de locataire et d’abonnement.

Décision : Si state n’est pas enabled ou si vous êtes dans le mauvais locataire, arrêtez. Réparez l’identité avant de toucher aux données.

Task 2: Get an access token and sanity-check its audience

cr0x@server:~$ az account get-access-token --resource-type ms-graph --query accessToken -o tsv | cut -c1-30
eyJ0eXAiOiJKV1QiLCJ...

Ce que cela signifie : Vous pouvez obtenir un token Graph ; vous n’êtes pas bloqué par un accès conditionnel ou des identifiants expirés.

Décision : Si la récupération du token échoue, votre « système de sauvegarde » est opérationnellement mort tant que vous n’aurez pas réglé les politiques CA, l’automatisation MFA ou les permissions du principal de service.

Task 3: Identify a user and confirm OneDrive exists (data location check)

cr0x@server:~$ TOKEN=$(az account get-access-token --resource-type ms-graph --query accessToken -o tsv)
cr0x@server:~$ curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/users?$filter=mail eq 'alice@corp.example'&$select=id,displayName,userPrincipalName"
{
  "value": [
    {
      "id": "9c0f2b2a-1111-2222-3333-444444444444",
      "displayName": "Alice Example",
      "userPrincipalName": "alice@corp.example"
    }
  ]
}

Ce que cela signifie : L’identité existe ; vous avez la permission d’interroger Graph.

Décision : Si l’utilisateur n’existe pas, vous pourriez faire face à une suppression liée à l’offboarding. Passez à la rétention/hold juridique ou aux sauvegardes ; la synchronisation ne vous aidera pas.

Task 4: Query the user’s drive (is OneDrive provisioned?)

cr0x@server:~$ USER_ID="9c0f2b2a-1111-2222-3333-444444444444"
cr0x@server:~$ curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/users/$USER_ID/drive?$select=id,driveType,owner"
{
  "id": "b!XxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx",
  "driveType": "business",
  "owner": {
    "user": {
      "id": "9c0f2b2a-1111-2222-3333-444444444444",
      "displayName": "Alice Example"
    }
  }
}

Ce que cela signifie : OneDrive existe et est accessible.

Décision : Si ceci renvoie 404, OneDrive peut ne pas être provisionné (nouvel utilisateur) ou est bloqué (licence/rétention/offboarding). N’assumez pas que les fichiers sont « dans le cloud ». Vérifiez.

Task 5: List top-level items to confirm content and scope

cr0x@server:~$ DRIVE_ID="b!XxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx"
cr0x@server:~$ curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/drives/$DRIVE_ID/root/children?$select=name,size,folder,file,lastModifiedDateTime" | head
{
  "value": [
    {
      "name": "Documents",
      "size": 0,
      "folder": { "childCount": 37 },
      "lastModifiedDateTime": "2026-01-15T19:02:11Z"
    },
    {
      "name": "Desktop",
      "size": 0,
      "folder": { "childCount": 118 },
      "lastModifiedDateTime": "2026-01-12T08:44:50Z"
    }
  ]
}

Ce que cela signifie : Le drive contient du contenu reconnaissable ; les dossiers connus sont présents.

Décision : Si « Desktop/Documents/Pictures » sont absents, KFM peut ne pas être activé, ou l’utilisateur a déplacé ses données ailleurs. Votre plan de récupération doit correspondre à la réalité.

Task 6: Detect a ransomware pattern (many recent modifications)

cr0x@server:~$ curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/drives/$DRIVE_ID/root/search(q='')?$select=name,lastModifiedDateTime,size&$top=5"
{
  "value": [
    { "name": "Q4_finance.xlsx", "lastModifiedDateTime": "2026-02-03T10:12:01Z", "size": 99212 },
    { "name": "client_archive.zip", "lastModifiedDateTime": "2026-02-03T10:11:58Z", "size": 402114553 },
    { "name": "README_RECOVER_FILES.txt", "lastModifiedDateTime": "2026-02-03T10:11:40Z", "size": 1842 }
  ]
}

Ce que cela signifie : Une note de rançon apparente plus une rafale de timestamps de dernière modification est un indicateur classique.

Décision : Arrêtez les clients de synchronisation si vous le pouvez (confinement). Passez immédiatement à la restauration depuis la sauvegarde ou au rollback OneDrive vers un moment connu — après confirmation de la capacité de rétention/version.

Task 7: Check local OneDrive client status on Windows endpoints (sync health)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-ItemProperty -Path 'HKCU:\Software\Microsoft\OneDrive\Accounts\Business1' | Select-Object UserEmail,ServiceEndpointUri"
UserEmail              ServiceEndpointUri
---------              -------------------
alice@corp.example     https://tenant-my.sharepoint.com/personal/alice_corp_example

Ce que cela signifie : L’endpoint est connecté au tenant et au compte attendus.

Décision : Si le compte pointe vers un autre tenant ou est manquant, les fichiers locaux peuvent ne pas être synchronisés là où vous le pensez. Traitez le contenu local comme séparé tant que ce n’est pas prouvé.

Task 8: Find OneDrive sync errors on the endpoint (silent gaps)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-OneDrive/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated      : 2/3/2026 10:20:14 AM
Id               : 3018
LevelDisplayName : Error
Message          : Couldn't upload 'Design\spec_final.docx' because the file name contains invalid characters.

Ce que cela signifie : Le client vous indique qu’il n’a pas pu téléverser quelque chose. Ce fichier n’a jamais été « sauvegardé » dans OneDrive.

Décision : Corrigez le nom/le chemin et resynchronisez, ou capturez le fichier via une sauvegarde d’endpoint. Ne dites pas à la direction « c’est dans OneDrive » quand les logs disent que ça ne l’est pas.

Task 9: Verify your export/backup repository has enough space (boring, essential)

cr0x@server:~$ df -h /backups
Filesystem      Size  Used Avail Use% Mounted on
tank/backups     20T   14T  6.0T  71% /backups

Ce que cela signifie : Vous avez 6 To libres dans l’ensemble de sauvegarde.

Décision : Si vous êtes au-dessus d’environ 85% d’utilisation, attendez-vous à une dégradation des performances et à un risque plus élevé d’échecs de jobs. Augmentez la capacité ou resserrez la rétention avant que le prochain incident ne vous force la main.

Task 10: Check immutability/WORM status for your object-store target (tamper resistance)

cr0x@server:~$ aws s3api get-object-lock-configuration --bucket m365-backups-prod
{
  "ObjectLockConfiguration": {
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }
}

Ce que cela signifie : Object Lock est activé avec une rétention en mode compliance, rendant la suppression/écrasement plus difficile (même pour les admins) dans la fenêtre.

Décision : Si cela est absent, vos sauvegardes sont des cibles molles. Traitez cela comme un bug de sécurité, pas comme un « nice to have ».

Task 11: Validate backup job freshness (are you backing up or just configured to?)

cr0x@server:~$ ls -lt /backups/m365/onedrive/alice@corp.example/ | head -5
total 32
drwxr-xr-x 2 root root 4096 Feb  3 01:10 2026-02-03T01-00Z
drwxr-xr-x 2 root root 4096 Feb  2 01:09 2026-02-02T01-00Z
drwxr-xr-x 2 root root 4096 Feb  1 01:08 2026-02-01T01-00Z
drwxr-xr-x 2 root root 4096 Jan 31 01:07 2026-01-31T01-00Z

Ce que cela signifie : Les sauvegardes s’exécutent quotidiennement et produisent des snapshots/exports datés.

Décision : Si le répertoire le plus récent est ancien, vous êtes déjà hors de votre RPO. Enquêter avant d’avoir à l’expliquer lors d’un appel d’incident.

Task 12: Check backup integrity with hashes (detect silent corruption)

cr0x@server:~$ sha256sum /backups/m365/onedrive/alice@corp.example/2026-02-03T01-00Z/Documents/Q4_finance.xlsx | head -1
5f6c2d0b8c2b56f2c9d8bb4f8f5a8b5d2eaa3f3dfe4c7a9a5c1b2d3e4f5a6b7c  /backups/m365/onedrive/alice@corp.example/2026-02-03T01-00Z/Documents/Q4_finance.xlsx

Ce que cela signifie : Vous pouvez enregistrer des hachages de contenu pour des vérifications ultérieures (très utile lors de restaurations après événements malveillants).

Décision : Si les hachages changent de façon inattendue entre deux sauvegardes sans modification connue, enquêtez : vous sauvegardez peut‑être des fichiers chiffrés, ou vous avez de la corruption en transit/stockage.

Task 13: Measure restore performance (your RTO is a number, not a vibe)

cr0x@server:~$ time rsync -a --info=progress2 /backups/m365/onedrive/alice@corp.example/2026-02-03T01-00Z/ /restore-staging/alice/
sending incremental file list
total size is 18.42G  speedup is 1.00
   18.42G 100%  112.34MB/s    0:02:47 (xfr#14322, to-chk=0/14323)

real    2m48.201s
user    0m9.122s
sys     0m31.553s

Ce que cela signifie : Restaurer 18,4 Go a pris moins de 3 minutes vers une zone de staging sur votre réseau/stockage.

Décision : Si les restaurations sont lentes, corrigez le pipeline de restauration maintenant (réseau, IOPS stockage, parallélisme). Pendant un incident, « la restauration est lente » devient « l’activité est arrêtée ».

Task 14: Snapshot your backup filesystem (fast rollback of the backup itself)

cr0x@server:~$ zfs snapshot tank/backups@m365-2026-02-03
cr0x@server:~$ zfs list -t snapshot | tail -3
tank/backups@m365-2026-02-01   0B      -  14T  -
tank/backups@m365-2026-02-02   0B      -  14T  -
tank/backups@m365-2026-02-03   0B      -  14T  -

Ce que cela signifie : Le dépôt de sauvegarde est lui-même protégé par des snapshots copy-on-write.

Décision : Si vous ne pouvez pas snapshot/verrouiller votre stockage de sauvegarde, vous êtes à une erreur d’admin de la suppression du dernier canot de sauvetage.

Task 15: Confirm you can restore to an alternate location (safe restore practice)

cr0x@server:~$ mkdir -p /restore-staging/alice-quarantine
cr0x@server:~$ cp -a /backups/m365/onedrive/alice@corp.example/2026-02-03T01-00Z/Documents /restore-staging/alice-quarantine/
cr0x@server:~$ ls -la /restore-staging/alice-quarantine/Documents | head
total 128
drwxr-xr-x  5 root root  4096 Feb  3 01:12 .
drwxr-xr-x  3 root root  4096 Feb  4 09:01 ..
-rw-r--r--  1 root root 98212 Feb  3 01:10 Q4_finance.xlsx
-rw-r--r--  1 root root 22011 Feb  3 01:10 pricing_notes.docx

Ce que cela signifie : Vous pouvez mettre en scène des restaurations sans écraser l’état actuel de l’utilisateur.

Décision : Toujours mettre en scène en premier lors d’incidents de sécurité. Si vous restaurez directement dans les chemins de production, vous risquez de réintroduire du contenu compromis ou de détruire du travail récent.

À quoi ressemble une vraie solution : conception de sauvegarde pour OneDrive/M365

Voici la réponse pratique et argumentée : considérez OneDrive comme l’espace de travail primaire et construisez un système de sauvegarde indépendant qui soit hors du rayon d’explosion de OneDrive, d’une compromission Azure AD et des malwares endpoints.

Définissez vos objectifs (RPO/RTO) sérieusement

RPO (Recovery Point Objective) : combien de données vous pouvez vous permettre de perdre. Pour de nombreuses équipes, une exécution quotidienne suffit. Pour des départements à forte activité, vous aurez peut-être besoin de plusieurs runs par jour.
RTO (Recovery Time Objective) : à quelle vitesse vous devez restaurer. Si la direction dit « heures », ne construisez pas quelque chose qui restaure des térabytes sur un tuyau mono-threadé.

Utilisez la règle 3-2-1, adaptée au SaaS

3 copies : production (OneDrive) + copie de sauvegarde + une autre copie (ou lignée de snapshots).
2 supports/types : par ex. stockage objet plus snapshots locaux immuables.
1 hors site/isolé : identifiants/compte séparés et idéalement un fournisseur différent ou au moins une frontière de sécurité différente.

Sauvegardez les bonnes choses (périmètre)

Au minimum pour Microsoft 365, votre périmètre de protection des données devrait inclure :

OneDrive (disques utilisateurs)
Sites SharePoint et bibliothèques de documents
Fichiers Microsoft Teams (qui sont majoritairement SharePoint sous le capot)
Boîtes aux lettres Exchange si le mail est important (ce qui est généralement le cas)
Exports des métadonnées Azure AD (utilisateurs/groupes/enregistrements d’applications) pour référence en récupération

Concevez pour les cas méchants

Ransomware : sauvegardes immuables, temps de détection court et workflow répété de restauration vers quarantaine.
Erreur d’admin : identifiants séparés et protection contre la suppression sur la cible de sauvegarde.
Offboarding : assurez-vous que le contenu OneDrive est sauvegardé et récupérable après suppression d’utilisateur.
Dérive de politique : surveillez les paramètres de rétention/version ; ne comptez pas uniquement sur eux comme filet de sécurité.

Cit.: idée paraphrasée

Richard Cook (chercheur en résilience opérationnelle), idée paraphrasée : « Le succès en opérations vient souvent des personnes qui s’adaptent aux problèmes, pas d’un système parfait. »

C’est la raison principale pour laquelle vous avez besoin de vraies sauvegardes : les humains s’adaptent sous pression. Ils cliqueront sur la mauvaise chose. Ils feront du « nettoyage ». Ils feront des actions héroïques. Votre système doit tolérer cela.

Blague n°2 : Appeler la synchronisation une sauvegarde, c’est comme appeler un détecteur de fumée un service d’incendie. L’un est utile ; l’autre apporte réellement de l’eau.

Listes de contrôle / plan étape par étape

Checklist A : Établir un état des lieux (une après-midi)

Inventoriez les utilisateurs, les sites SharePoint et les emplacements de fichiers Teams que vous considérez dans le périmètre.
Documentez les paramètres actuels de rétention/historique et les fenêtres de corbeille.
Choisissez un utilisateur « canari » et un site d’équipe « canari » pour les tests de restauration.
Décidez vos cibles RPO/RTO en langage clair et obtenez la signature métier.

Checklist B : Mettre en place une sauvegarde indépendante (un à deux sprints)

Choisissez une approche de sauvegarde :
- Produit commercial de sauvegarde M365 (commun en entreprise)
- Exportateur personnalisé basé sur Graph (fonctionne, mais vous l’héritez à vie)
Sauvegardez dans un stockage objet ou un NAS durci avec immutabilité (Object Lock / WORM / snapshots).
Identités séparées :
- Principal de service ou compte de sauvegarde dédié
- Groupe admin séparé ; rôles minimaux requis
- MFA/accès conditionnel conçu pour l’automatisation
Chiffrez les sauvegardes au repos et en transit.
Mettez en œuvre des niveaux de rétention :
- Court terme : restaurations rapides (jours/semaines)
- Moyen terme : opérationnel (mois)
- Long terme : conformité (années) si nécessaire

Checklist C : Prouver que la restauration fonctionne (trimestrielle, toujours)

Restaurer un petit ensemble de fichiers vers un emplacement alternatif.
Restaurer un disque utilisateur complet (ou un sous-ensemble représentatif) en staging.
Restaurer une bibliothèque SharePoint.
Mesurer le temps de restauration et le rapporter.
Valider l’intégrité des fichiers (vérifications de hachage pour un échantillon).
Consigner les leçons apprises et mettre à jour le runbook.

Checklist D : Boutons prêts pour les incidents (avant d’en avoir besoin)

Sachez comment suspendre/contenir la synchronisation OneDrive sur les endpoints pendant un ransomware.
Ayez un workflow approuvé pour restaurer des données sans écraser des modifications légitimes récentes.
Activez et surveillez les journaux d’audit pour les événements de suppression/déplacement massif.
Définissez qui peut autoriser une restauration massive (c’est perturbateur).

Erreurs courantes : symptôme → cause racine → correction

1) « On ne trouve le fichier nulle part, mais l’utilisateur jure qu’il était sur son Bureau. »

Symptôme : Fichier manquant après perte ou rebuild du portable.

Cause racine : Known Folder Move n’était pas activé, ou la synchronisation échouait (caractères invalides, chemin trop long, fichier verrouillé). Le fichier n’a jamais été téléversé.

Correction : Vérifiez l’enrôlement KFM ; surveillez les erreurs du client OneDrive ; ajoutez une sauvegarde d’endpoint pour les appareils critiques. Traitez les erreurs de sync comme des incidents de perte de données, pas comme du bruit helpdesk.

2) « Nous avons restauré depuis la corbeille, mais ce n’est pas là. »

Symptôme : Corbeille vide ou élément manquant.

Cause racine : Fenêtre de rétention expirée, corbeille purgeée, ou le compte/site a été supprimé et le contenu a vieilli.

Correction : Mettez en place des sauvegardes indépendantes avec rétention définie. Pour les utilisateurs à haut risque, prolongez la rétention et protégez les permissions de purge — mais ne confondez pas cela avec une sauvegarde.

3) « Le ransomware a frappé, et maintenant OneDrive a aussi des versions chiffrées. »

Symptôme : Fichiers dans OneDrive chiffrés ou remplacés par des données inutilisables.

Cause racine : La synchronisation a propagé les changements malveillants ; l’historique des versions était insuffisant ou aussi affecté par l’ampleur des changements.

Correction : Contenez la synchronisation, puis restaurez depuis des sauvegardes immuables ou effectuez un rollback OneDrive vers un moment connu après confirmation qu’il n’écrasera pas de travail nécessaire. Augmentez la fréquence des sauvegardes pour les groupes à haute activité.

4) « Nous avons essayé d’optimiser le stockage, et les restaurations sont devenues impossibles. »

Symptôme : Pas assez de versions conservées ; la corbeille ne remonte pas assez loin ; restaurations incomplètes.

Cause racine : Versioning/rétention réglés à la baisse avant qu’une vraie sauvegarde n’existe.

Correction : Priorisez d’abord les sauvegardes. Puis optimisez. Si vous devez réduire, faites-le avec une évaluation des risques et des tests de restauration.

5) « Les jobs de sauvegarde sont verts, mais les restaurations manquent des fichiers récents. »

Symptôme : Le système de sauvegarde annonce un succès ; les données sont obsolètes ou incomplètes.

Cause racine : Throttling API, bugs de pagination, types de fichiers ignorés, ou lacunes dans les permissions de l’identité de sauvegarde.

Correction : Ajoutez des contrôles de complétude : compte des éléments par drive/bibliothèque, validation des tokens delta, budget d’erreurs pour le throttling, et scans complets périodiques. Alertez sur les anomalies, pas seulement sur les codes de sortie.

6) « Nous avons restauré, mais les utilisateurs disent que le travail le plus récent a disparu. »

Symptôme : Après restauration, des modifications légitimes sont manquantes.

Cause racine : La restauration a écrasé l’état courant au lieu de restaurer dans un emplacement séparé et de réconcilier.

Correction : Par défaut, restaurez en quarantaine/staging, validez, puis fusionnez/basculez. Utilisez une autorisation claire pour les restaurations destructrices.

7) « L’offboarding supprime les données OneDrive avant qu’on puisse les préserver. »

Symptôme : Les données d’un utilisateur partant disparaissent ou deviennent inaccessibles.

Cause racine : La suppression de compte/nettoyage déclenche des comportements de rétention/désapprovisionnement ; pas d’étape pré-offboarding pour préserver/exporter.

Correction : Intégrez la préservation dans l’offboarding : transférez la propriété, placez un hold juridique si nécessaire et assurez-vous qu’une sauvegarde indépendante capture le disque utilisateur avant suppression.

FAQ

1) OneDrive « sauvegarde » est-ce la même chose que sauvegarder mon PC ?

Non. Il redirige et synchronise certains dossiers. Il ne garantit pas la restauration à un point dans le temps, l’immutabilité ou l’indépendance vis-à-vis des malwares et des compromissions de comptes.

2) L’historique des versions n’est-il pas suffisant ?

L’historique des versions aide pour des modifications accidentelles et certains cas de ransomware, mais il dépend des politiques et n’est pas conçu comme votre unique mécanisme de récupération. De plus, restaurer beaucoup de fichiers via l’historique peut être lent et manuel.

3) Si Microsoft a de la redondance, pourquoi ai-je besoin de sauvegardes ?

La redondance du fournisseur protège contre la perte d’un disque ou d’un datacenter chez Microsoft. Les sauvegardes protègent contre vous : suppression, écrasement, compromission et dérive de politique. Problème différent.

4) Ne peut-on pas simplement compter sur les politiques de rétention et les holds juridiques ?

La rétention et les holds servent à la préservation et à la conformité. Ils peuvent conserver des données pour l’eDiscovery mais ne garantissent pas une restauration opérationnelle rapide et propre à l’échelle nécessaire.

5) Quel est le minimum acceptable pour une petite entreprise ?

Au minimum : une sauvegarde Microsoft 365 indépendante couvrant OneDrive et SharePoint, stockée avec immutabilité (ou au moins des identifiants séparés et des snapshots), plus des tests de restauration trimestriels.

6) Comment protéger les sauvegardes d’un attaquant qui compromet notre locataire ?

Séparez la frontière d’authentification : identités de sauvegarde dédiées avec privilèges minimaux, accès conditionnel durci, et stockage de sauvegarde appliquant immutabilité/WORM et contrôle administratif séparé.

7) Que devons-nous restaurer en premier pendant un incident ?

Restaurez d’abord vers un emplacement alternatif, en commençant par les jeux de données métier les plus critiques. Validez l’intégrité, puis restaurez en production. Évitez de « tout restaurer partout » sauf si vous avez scindé l’impact.

8) À quelle fréquence devons-nous tester les restaurations ?

Trimestriellement est une base raisonnable pour la plupart des organisations ; mensuellement pour les environnements à haut risque. Si vous n’avez jamais testé, votre première tentative se fera pendant une panne. Mauvaise habitude.

9) Files On-Demand — cela affecte-t-il les sauvegardes ?

Oui. Files On-Demand peut signifier que le contenu complet n’est pas présent sur l’endpoint. Si vous comptez sur des sauvegardes d’endpoint, vous devez vous assurer que les fichiers sont hydratés (téléchargés) ou sauvegardés depuis le cloud côté serveur indépendamment.

10) Quel est le plus grand signe que nous confondons synchronisation et sauvegarde ?

Si votre plan de récupération commence par « il suffit de se connecter et de retélécharger », vous dépendez du même système qui a échoué. Les sauvegardes devraient rester disponibles quand le système primaire est compromis ou mal configuré.

Conclusion : étapes pratiques suivantes

Arrêtez d’appeler OneDrive « sauvegarde ». Appelez-le ce qu’il est : synchronisation plus quelques filets de sécurité. Utile, mais insuffisant.

Si vous dirigez une entreprise, vous avez besoin d’une sauvegarde indépendante avec une rétention définie, une frontière de sécurité isolée et des tests de restauration qui donnent de vrais chiffres. Le plan correct est aussi le plan ennuyeux : automatisez les sauvegardes, stockez-les de façon immuable, mettez en scène les restaurations et entraînez-vous.

Faites ceci, dans l’ordre

Écrivez RPO et RTO pour les données OneDrive/SharePoint, avec validation métier.
Inventoriez le périmètre (utilisateurs, sites, emplacements Teams) et choisissez des canaris pour les tests.
Mettez en place une cible de sauvegarde indépendante avec immutabilité et identifiants séparés.
Exécutez un exercice de restauration vers une zone de staging et mesurez le temps de restauration. Corrigez ce qui est lent.
Surveillez la santé de la synchronisation pour savoir quand la « sauvegarde via la synchronisation » n’arrive plus silencieusement sur les endpoints.