Récupération d'une base corrompue et restauration d'un élément

Je ne commence pas par la copie retardée : elle représente 5 jours de perte potentielle, alors que la copie passive n'a que 12 minutes de retard, ce qui respecte le RPO de 15 minutes.

1. Vérifier que la corruption est bien limitée à SRV-A01 et que SRV-B02 n'est pas affecté. Contrôler les logs et l'état de la copie.
2. Basculer l'activation sur SRV-B02. La perte est de 12 minutes de logs, dans le RPO. Le RTO de 2 heures est tenable car aucun restore bande n'est nécessaire.
3. Si SRV-B02 s'avère également corrompu, utiliser la copie retardée SRV-B04 : suspendre la copie, vérifier la chaîne de logs, activer avec l'option qui ignore les contrôles de retard, puis rejouer les logs jusqu'au point précédant la corruption. Le truncation lag de 2 jours signifie que les logs sont conservés 2 jours après le point de rejeu ; si la corruption date de plus de 2 jours après ce point, la copie retardée ne permettra pas de revenir juste avant la corruption.
4. Si la copie retardée ne permet pas d'atteindre le point voulu et que le RTO de 2 heures prime, monter une base vide (dial tone) sur un serveur sain, laisser les utilisateurs travailler, puis fusionner les données récupérées depuis la copie ou la bande.
5. Ne restaurer la bande qu'en dernier recours : le restore de 60 Go plus le rejeu des logs dépasse probablement 2 heures.

Exchange 2016 ne propose pas de sauvegarde incrémentale ou différentielle VSS : seules les sauvegardes complètes ou de copie existent. Augmenter la fréquence des sauvegardes complètes ne réduit donc pas la fenêtre ; il faut changer de stratégie.

• Sauvegarder depuis une copie passive, jamais depuis l'active, pour ne pas impacter les utilisateurs.
• Utiliser les copies du DAG comme première ligne de restauration : la copie passive saine et la copie retardée couvrent la plupart des corruptions logiques. La bande devient un archivage hors site, pas le mécanisme principal de RPO.
• Réduire le nombre de bases sauvegardées chaque nuit : par exemple, une sauvegarde complète VSS par semaine et par base, étalée sur plusieurs nuits, avec une vérification d'intégrité. Le RPO de 15 minutes est tenu par la réplication continue, pas par la bande.
• Pour les bases critiques, ajouter une copie retardée supplémentaire ou une copie sur un stockage tiers, avec un truncation lag adapté.
• Tester la restauration d'une base dans une Recovery Database et mesurer le temps réel ; un RTO de 2 heures ne peut pas reposer sur une bande si le restore dépasse ce délai.

La fenêtre de 9 heures doit être mesurée après réduction du nombre de bases et parallélisation des flux, sinon elle reste un point de rupture.

La rétention des éléments supprimés est de 14 jours et aucune conservation n'est active : le message a donc été purgé de la boîte après 14 jours. Il n'est plus dans les éléments récupérables et la recherche ne le retrouvera pas.

Options :

1. Restaurer la boîte ou la base depuis une sauvegarde antérieure à la suppression, dans une Recovery Database, puis utiliser une demande de restauration de boîte avec fusion vers la boîte cible. Il faut une sauvegarde qui contient encore le message et qui date d'avant les 45 jours.
2. Vérifier si le message existe dans le journal : si le journaling est activé et conservé, on peut le récupérer depuis l'archive de journal, mais cela dépend de la politique de conservation.
3. Vérifier les règles de rétention et les holds : si un hold avait été appliqué, le message serait dans les éléments récupérables. Ici, rien n'est actif.

Avant de promettre, il faut vérifier la profondeur de conservation des bandes, la date exacte de suppression, et si la sauvegarde contient bien la boîte. Si la bande ne remonte pas à 45 jours, la restauration est impossible. La leçon de conception est d'activer une conservation ou une période de rétention suffisante pour les boîtes sensibles, et de documenter que la rétention de 14 jours ne couvre pas les demandes au-delà.