OneNote & Teams ouverts pendant un snapshot AWS EBS : risques, VSS et bonnes pratiques

En bref : pendant un snapshot EBS, laissez le moins possible d’applications « connectées » ouvertes. Fermez ou mettez OneNote et Teams hors ligne, ou utilisez des snapshots application‑consistent via VSS. Automatisez des scripts pré/post, testez la restauration et surveillez les journaux.

Sommaire

Contexte et problème

Vous exécutez un Windows Server 2019 sur EC2, sauvegardé chaque nuit par snapshots EBS. La question est simple : faut‑il impérativement fermer Microsoft OneNote et Teams avant la prise de snapshot ? Toutes deux gardent une connexion persistante à Microsoft 365 et maintiennent des caches locaux actifs. Le risque n’est pas de « casser » les données sur le cloud Microsoft, mais de capturer un état disque incohérent côté serveur (fichiers, caches et journaux partiellement écrits), ce qui peut provoquer des messages d’erreur ou des resynchronisations complexes après restauration.

Risques liés à OneNote & Teams ouverts lors d’un snapshot AWS

Pourquoi c’est risqué ?

  • Incohérence applicative : un snapshot est un gel à l’instant T du volume EBS. Si OneNote/Teams écrivent encore des transactions en local (sections OneNote, pièces jointes, messages, fichiers cache, tokens, base de données locale), le cliché pourra contenir un journal incomplet. Après restauration, l’application repart d’un état divergent et doit rejouer ou purger le cache.
  • Caches et journaux locaux :
    • OneNote garde une base de cache locale dans le profil utilisateur. En cas de coupure au mauvais moment, vous pouvez voir des « sections égarées » ou un sync status = failed au redémarrage.
    • Teams maintient un cache dense (historique de conversations, structure des canaux, settings) et des connexions temps réel. Un cliché pris durant l’écriture peut nécessiter une reconstruction lente du cache après restauration.
  • Crash‑consistent vs application‑consistent : par défaut, un snapshot EBS est crash‑consistent (équivalent d’une coupure brutale d’alimentation). Pour les applications bavardes, on vise des clichés application‑consistent via VSS (Volume Shadow Copy Service) qui fige proprement les écritures et vide les buffers.

Réponses possibles

  1. Bonne pratique immédiate : fermer OneNote et Teams avant la fenêtre de sauvegarde. À défaut, forcer la synchronisation (flush) puis placer les deux en mode hors connexion.
  2. Activer des snapshots application‑consistent : utilisez AWS Backup avec l’option VSS activée pour EC2/Windows. AWS orchestre un freeze VSS avant la photo et un thaw après.
  3. Scripts de pré/post‑snapshot : via AWS Systems Manager (SSM), fermez proprement les processus critiques, vérifiez l’état VSS, lancez le snapshot, puis rouvrez les applis.

Playbook minimal « sans regret »

  1. Avant la fenêtre : prévenir les utilisateurs, bloquer de nouvelles ouvertures de session si nécessaire (mode maintenance).
  2. Pré‑snapshot :
    • Arrêt OneNote/Teams (fermeture douce puis forcée si besoin).
    • Vérification des writers VSS et des services indispensables.
  3. Snapshot : lancer un snapshot application‑consistent (ou un multi‑volume snapshot groupé pour tous les volumes de l’instance).
  4. Post‑snapshot : redémarrer les applis, tester une resync rapide, écrire un healthcheck dans les journaux.

Implémentation détaillée avec VSS

Pour obtenir la cohérence applicative, assurez‑vous que :

  • Le SSM Agent est installé et l’instance est gérée.
  • Le Windows Server Backup et le service Microsoft Software Shadow Copy Provider sont présents et démarrés.
  • Dans votre plan AWS Backup, l’option avancée WindowsVSS est activée pour la ressource EC2.
{
  "BackupPlanName": "EC2-AppConsistent",
  "Rules": [{
    "RuleName": "Nightly",
    "TargetBackupVaultName": "Default",
    "ScheduleExpression": "cron(0 1 * * ? *)",
    "StartWindowMinutes": 60,
    "CompletionWindowMinutes": 180,
    "Lifecycle": { "DeleteAfterDays": 30 }
  }],
  "AdvancedBackupSettings": [{
    "ResourceType": "EC2",
    "BackupOptions": { "WindowsVSS": "enabled" }
  }]
}

En complément, utilisez les multi‑volume snapshots lorsque votre instance possède plusieurs volumes (C:, D:, E:). Cela garantit un cliché coordonné entre volumes :

aws ec2 create-snapshots \
  --instance-specification InstanceId=i-0abc123def4567890 \
  --copy-tags-from-source volume \
  --description "Nightly MVSS"

Scripts PowerShell de pré/post‑snapshot (SSM)

Exemple de script « pré‑snapshot » exécuté via AWS-RunPowerShellScript (Run Command) :

# Pré-snapshot : fermer proprement puis forcer si nécessaire
$ErrorActionPreference = "Stop"

$procs = @("OneNote","onenote","Teams","teams")
foreach ($p in $procs) {
Get-Process -Name $p -ErrorAction SilentlyContinue | ForEach-Object {
try { $_.CloseMainWindow() | Out-Null } catch {}
}
}
Start-Sleep -Seconds 5
foreach ($p in $procs) {
taskkill /IM "$p.exe" /F 2>NUL | Out-Null
}

# Vérifier l'état des writers VSS

$vss = vssadmin list writers
if ($vss -match "State: \s*Failed") {
Write-Host "[WARN] Un writer VSS est en erreur. Tentative de redémarrage..."
Get-Service -Name "VSS","SwPrv" | Restart-Service -Force
Start-Sleep -Seconds 5
}

# Journaliser

$newLog = "C:\Backup\logs\pre-snapshot_{0:yyyyMMdd_HHmmss}.log" -f (Get-Date)
New-Item -ItemType Directory -Force -Path (Split-Path $newLog) | Out-Null
$vss | Out-File -FilePath $newLog -Encoding UTF8 

Exemple de script « post‑snapshot » :

# Post-snapshot : relancer Teams et OneNote, vérifier la resynchronisation
Start-Process "$env:LOCALAPPDATA\Microsoft\Teams\Update.exe" -ArgumentList "--processStart Teams.exe" -ErrorAction SilentlyContinue
Start-Sleep -Seconds 3

# OneNote (Win32). Adapter si UWP

$oneNotePaths = @(
"$env:ProgramFiles\Microsoft Office\root\Office16\ONENOTE.EXE",
"$env:ProgramFiles(x86)\Microsoft Office\root\Office16\ONENOTE.EXE"
) | Where-Object { Test-Path $_ }

foreach ($p in $oneNotePaths) { Start-Process $p -ErrorAction SilentlyContinue }

# Journaliser un marqueur de santé

"[INFO] Post-snapshot OK: $(Get-Date)" | Out-File "C:\Backup\logs\post-snapshot.log" -Append 

Si vous utilisez une tâche personnalisée (Lambda ou SSM Automation) pour déclencher le snapshot, la séquence type est :

  1. Run Command « pré‑snapshot » (fermeture applis + contrôle VSS)
  2. Appel create-snapshots ou start-backup-job
  3. Run Command « post‑snapshot » (réouverture + checks)

Vérifications après restauration

  • OneNote : inspecter les journaux sous <userprofile>\AppData\Local\Microsoft\OneNote\logs. Rechercher sync status = failed, misplaced sections, ou des IDs de sections répliquées. Forcer une synchronisation et résoudre les conflits si des copies locales sont marquées « en attente ».
  • Teams : consulter %AppData%\Microsoft\Teams\logs. En cas de cache corrompu, vider %AppData%\Microsoft\Teams\Cache (en fermant Teams) puis relancer. L’app se resynchronise depuis M365.
  • Événements Windows : Event Viewer → Windows Logs → Application pour VSS/VolSnap, et System pour d’éventuels resets de disque.

Applications « non connectées » (Excel fermé, Acrobat, front‑end SQL, etc.)

Risque réduit mais non nul

  • Fichiers fermés : si l’application n’écrit plus, NTFS et le journal de système de fichiers garantissent un état cohérent du disque au moment du snapshot.
  • Caches en RAM : certains logiciels gardent des tampons en mémoire. Restaurer l’instance ailleurs les perdra — le fichier sur disque reste sain, mais vous pourrez voir une demande de réouverture ou un avertissement d’« enregistrement récupéré ».
  • Documents ouverts mais inactifs : si un classeur Excel est ouvert mais non modifié et que l’auto‑enregistrement n’est pas en cours, le cliché capturera le fichier tel qu’écrit sur disque. Les modifications non enregistrées (RAM) seront perdues — c’est attendu.

Cas du front‑end SQL

Si le front‑end (par ex. un client SSMS ou une appli maison) se connecte à un SQL Server local sur la même instance EC2, deux approches :

  • Idéal : réaliser des BACKUP FULL + LOG avant la fenêtre de snapshot, ou activer le writer VSS de SQL Server pour des sauvegardes application‑consistent.
  • À défaut : snapshot crash‑consistent mais exécuter un CHECKPOINT ou un BACKUP LOG pour réduire la fenêtre de récupération.
-- Exemple avant snapshot
BACKUP DATABASE [MaBase] TO DISK = 'C:\Backups\MaBase_full.bak' WITH COPY_ONLY, INIT, COMPRESSION;
BACKUP LOG [MaBase] TO DISK = 'C:\Backups\MaBase_log.bak' WITH INIT, COMPRESSION;

Matrice de décision (résumé opérationnel)

Type d’applicationExemplesAction pré‑snapshot recommandéeNiveau de risque si laissé ouvert
Connectée temps réelOneNote, TeamsFermer ou hors‑ligne / VSS activé / scripts pré/postÉlevé → inconsistances de cache
Client lourd non connectéExcel (fichiers fermés), AcrobatOptionnel : fermer, sinon OKFaible → perte RAM non écrite
Front‑end sur SQL localApp métier, SSMSBACKUP FULL+LOG ou VSS SQLMoyen → récupération via journaux
Service Windows critiqueIIS, AD DS, DFSVérifier writers VSS, fenêtres dédiéesMoyen/Élevé selon rôle

Procédure complète de bout en bout

Avant la première exécution

  • Documenter clairement la fenêtre de sauvegarde et prévenir les utilisateurs.
  • Installer/valider SSM Agent, Windows Server Backup, services VSS actifs.
  • Configurer un plan AWS Backup avec WindowsVSS=enabled, rétention et coffre (vault) dédiés.
  • Étiqueter les volumes EBS et l’instance (tags de backup selection).

Chaque nuit

  1. Pré‑snapshot (SSM) :
    • Fermeture OneNote/Teams (gracieuse puis forcée).
    • Contrôle VSS (vssadmin list writers doit être « Stable »).
    • Option : wbadmin start systemstatebackup vers un disque dédié si vous voulez un point de restauration AD ou registre séparé.
  2. Snapshot :
    • AWS Backup déclenche l’application‑consistent (freeze/thaw VSS).
    • Ou EC2 Multi‑Volume : aws ec2 create-snapshots pour tous les volumes de l’instance.
  3. Post‑snapshot :
    • Relancer Teams/OneNote, vérifier une synchro complète.
    • Pousser un healthcheck (fichier témoin, entrée d’événement) pour tracer l’état.

Contrôles et surveillance

  • CloudWatch : latence de snapshot, durée du freeze, volumes non sauvegardés. Déclenchez des alarmes si un gel dépasse un seuil (ex. >60 s).
  • EventBridge : règles sur les états de job AWS Backup (succès/échec) → notifications.
  • Vérification applicative :
    • OneNote : pas d’erreurs « synchronisation impossible », sections non dupliquées.
    • Teams : démarrage < 15 s, pas de boucle de connexion, panneau « Statut de connexion » OK.

Plan de restauration granulaire

Un snapshot restaure un volume entier. Conservez toujours une porte de sortie granulaire :

  • OneNote : exports périodiques .onepkg des blocs‑notes critiques (équipes/projets sensibles) → restauration sans tout remonter l’instance.
  • Teams : stratégie de rétention M365 et procédures de récupération des canaux (administration). Documenter les étapes pour recréer une équipe/canal et recharger les fichiers depuis SharePoint si nécessaire.
  • SQL : conserver des sauvegardes natives (Full/Diff/Log) en plus des snapshots.

Tableau de recommandations pratiques

Point cléPourquoi ?Action recommandéeCommande / Outil
Snapshots « application‑consistent »Assure un gel VSS, cohérence des IOActiver dans AWS Backup (WindowsVSS)Plan Backup → AdvancedBackupSettings
Scripts pré/post‑snapshotÉliminer les écritures concurrentesFermer OneNote/Teams, logguer VSSSSM Run Command / PowerShell
Test de restaurationValider l’intégrité après repriseRestaurer un volume et booter en laboEC2 + volume from snapshot
SurveillanceDétecter un freeze trop longAlertes CloudWatch/EventBridgeMétriques Backup / EC2 EBS
Plan granulaireRécupérer un bloc‑note/canal isoléExport OneNote / Procédure TeamsOutils M365 / Admin

FAQ rapide

Dois‑je toujours fermer OneNote/Teams ?
Ce n’est pas obligatoire si vous avez des snapshots application‑consistent stables, mais c’est recommandé (réduit encore le risque et la durée de resync).

Un snapshot EBS peut‑il corrompre mes données M365 ?
Non, les données cloud (OneNote/Teams) restent côté Microsoft. Le risque porte sur le cache local capturé en plein write — d’où l’importance de VSS/fermetures.

Le multi‑volume snapshot est‑il nécessaire ?
S’il existe plusieurs volumes EBS pour le même serveur, oui : il maintient une cohérence temporelle entre C:, D:, E:.

Et si VSS échoue ?
Relancer les services VSS et SwPrv, vérifier les writers en échec (SQL, Exchange, etc.), puis réessayer. Sur incident récurrent, basculer temporairement sur fermeture stricte des applis avant snapshot.

Erreurs fréquentes et comment les éviter

  • Oublier le post‑snapshot : ne laissez pas le serveur « muet » après la sauvegarde. Rouvrez les applis, créez un marqueur de santé.
  • Confondre crash‑consistent et application‑consistent : le premier suffit pour beaucoup de workloads, mais pas pour ceux très transactionnels (OneNote/Teams actifs, SQL, AD).
  • Snapshots sans tests : programmez un DR Day trimestriel pour valider la restauration réelle, y compris l’ouverture d’un bloc‑note OneNote et la connexion Teams.
  • Ne pas nettoyer le cache Teams après restauration : en cas d’erreurs récurrentes, supprimer %AppData%\Microsoft\Teams\Cache et relancer.

Checklist opérationnelle

  • [ ] Plan AWS Backup avec WindowsVSS activé pour EC2/Windows.
  • [ ] SSM Agent enregistré, documents Run Command prêts.
  • [ ] Script pré‑snapshot : fermeture OneNote/Teams + contrôle VSS.
  • [ ] Script post‑snapshot : relance applis + healthcheck.
  • [ ] Multi‑volume snapshots si plusieurs volumes EBS.
  • [ ] Tests de restauration périodiques (volume monté en labo).
  • [ ] Surveillances CloudWatch/EventBridge en place.

Bonnes pratiques supplémentaires

  • Fenêtre silencieuse : si possible, empêche les sessions utilisateurs pendant la sauvegarde nocturne.
  • Quotas & rétention : définissez une rétention adaptée (ex. 30/90 jours) et surveillez les coûts des snapshots incrémentaux.
  • Documentation : conservez des Runbooks à portée de main (opérations N1/N2) pour fermer/rouvrir les applis et diagnostiquer VSS.

Conclusion

Résumé pratique :

  1. Fermer ou synchroniser OneNote & Teams avant chaque snapshot ; à défaut, activez des snapshots application‑consistent via VSS.
  2. Pour les applis non connectées, le risque est marginal si les fichiers sont fermés, mais méfiez‑vous des caches RAM.
  3. Maintenez un plan de sauvegarde complet (snapshots + export applicatif), testez‑le régulièrement et tracez chaque étape.

Annexe : exemples d’automatisation

Déclenchement CLI d’un job AWS Backup sur l’instance

aws backup start-backup-job \
  --backup-vault-name "NightlyVault" \
  --resource-arn "arn:aws:ec2:eu-west-1:123456789012:instance/i-0abc123def4567890" \
  --complete-window-minutes 180 \
  --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupRole"

Automatiser via SSM Automation (pseudocode)

description: "EC2 app-consistent snapshot with pre/post"
schemaVersion: "0.3"
assumeRole: "arn:aws:iam::123456789012:role/SSMAutomationRole"
mainSteps:
  - name: PreSnapshot
    action: aws:runCommand
    inputs:
      DocumentName: "AWS-RunPowerShellScript"
      Parameters:
        commands:
          - "&amp; C:\\Scripts\\pre-snapshot.ps1"
  - name: CreateSnapshots
    action: aws:createSnapshots
    inputs:
      InstanceId: "i-0abc123def4567890"
      Description: "Nightly MVSS"
      CopyTagsFromSource: "volume"
  - name: PostSnapshot
    action: aws:runCommand
    inputs:
      DocumentName: "AWS-RunPowerShellScript"
      Parameters:
        commands:
          - "&amp; C:\\Scripts\\post-snapshot.ps1"

WBADMIN (optionnel) pour System State

# Nécessite la fonctionnalité Windows Server Backup
wbadmin start systemstatebackup -backupTarget:F: -quiet

Astuce : dans vos scripts, capturez l’horodatage exact (UTC) d’exécution pré/post et l’ID de snapshot. Cela accélère les corrélations lors des audits.


Rappels clés

  • OneNote & Teams ouverts au moment d’un snapshot : risque d’incohérence de cache → fermez ou basculez hors‑ligne.
  • VSS : c’est le standard Windows pour une cohérence applicative. Activez‑le via AWS Backup.
  • Scripts SSM : ils disciplinent l’environnement, même si VSS échoue.
  • Tests réguliers : la seule « vérité » d’une sauvegarde est une restauration réussie.
Sommaire