Comme nous l’avons évoqué précédemment, les bases d’Exchange 2010 peuvent devenir très grosses. La problématique des sauvegardes en est donc directement impactée. Les sauvegardes sont destinées à répondre à plusieurs besoins :
administrateur aurait supprimés
Seul le dernier point ne peut être adressé par Exchange 2010 et nécessite toujours un process de sauvegarde sur bandes. Mais pour chacun des points précédents, Exchange 2010 peut apporter une solution. L’équipe produit a demandé à un panel important d’entreprises, le service qui est rendu aux utilisateurs en matière de restauration de messages supprimés.
La grande majorité a répondu : 30 jours au maximum. Ainsi, pour éviter de restaurer une base pour ce type de demande d’utilisateurs, il suffit de garder 30 jours d’éléments supprimés. L’utilisateur pourra alors les récupérer par lui-même. Cela a un impact sur la taille de la base, mais cette taille n’est plus bloquante. Nous vous rappelons qu’il est possible de récupérer les éléments même quand l’utilisateur l’a supprimé avec Shift+Suppression.
En ce qui concerne la suppression des boîtes aux lettres par les administrateurs, la possibilité de garder ces boîtes pendant une période paramétrable existe toujours sous Exchange 2010. Le point le plus critique concerne la corruption des données. Il est extrêmement rare qu’une base soit corrompue. Cela se produit quand un problème physique survient sur un disque ou qu’un anti-virus scanne une base Exchange sans passer par les API Exchange (dans ce cas, cela vient d’une erreur de configuration).
Nous avons vu précédemment, que les bases sont inspectées en continu par le serveur Exchange. Cette inspection permet de détecter des corruptions. Quand vous mettez en oeuvre un DAG Exchange 2010 avec au minimum deux copies d’une base, quand un serveur du DAG trouve une corruption dans une base active ou passive, il est capable de demander la page correspondante dans une des copies de la base. La probabilité que les deux copies soient corrompues sur la même page est pratiquement nulle. La base corrompue est ainsi capable de se réparer.
Les logs peuvent également transporter une corruption, mais ils sont inspectés lors de la réplication entre les bases. Il n’est donc plus nécessaire de restaurer une base pour cause de corruption. Quand un disque est perdu, dans un DAG, une copie de la base redémarre. Le disque défectueux est alors remplacé et la base est copiée à partir de la base active. Là non plus, il n’est pas nécessaire de disposer d’une sauvegarde pour retrouver un système opérationnel.
Enfin, le dernier point concerne l’externalisation des données en cas de destruction du site principal. Là encore, la solution DAG répond à ce problème en disposant d’un des membres du DAG sur le site distant et de configurer une réplique des bases sur ce site distant. Comme vous pouvez le constater, à part si vous avez une contrainte légale ou que vous souhaitez offrir une restauration longue durée à vos utilisateurs, vous n’avez plus de raison de faire des sauvegardes de votre messagerie, même si je vous l’accorde, l’idée est perturbante.
Mais faites une pause et réfléchissez à ce que vous coûtent vos sauvegardes et à quoi elles vous servent en imaginant que contrairement à maintenant, vous disposiez en ligne, en permanence, d’au moins deux copies de chaque base : avez-vous encore besoin de vos sauvegardes ? Si jamais vous avez besoin de continuer à faire des sauvegardes, sachez qu’il n’est plus possible de faire des sauvegardes par streaming, mais uniquement par VSS.
Mais il vous restera un problème technique à régler : que faire des To de données sauvegardées chaque jour que vous devez en plus les conserver des mois ?
L'évolution du paysage des menaces et les conséquences sur votre infrastructure, vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la synthèse des conseils et recommandations à appliquer dans votre organisation.
