DPM 2010 prend en charge les DAG Exchange server 2010. Il est assez intéréssant de comprendre la gestion des bases, des logs et des points de restauration.

J’ai installé un DAG Exchnage 2010 sur deux serveurs Exchange, avec deux bases dans ce DAG.

Ensuite, j’ai téléchargé la béta publique de DPM 2010 à cette adresse: DPM Beta release

Mise en place de la protection:

Comme avec DPM 2007 SP1 créer un nouveau group de protection.

Selectionner le DAG. On y retrouve bien nos 2 noeuds Exchange et nos 2 bases de données.

Entrer un nom et choisir le mode de stockage.

Il est maintenant possible d’utiliser le cloud comme solution de stockage pour la protection long-term. :)

DPM s’appuie toujours sur eseutil pour le check d’intégrité des données Exchange.

Déclarer vos bases comme “Full Backup” database ou “Copy Backup” database.

Ce point est important, car il détermine la gestion des logs Exchange. Faisons un parenthèse, et prenons un exemple:

J'ai créé une DB3 active sur Node1 et sa copie sur Node2

Avec DPM2010 je créer un PG et je choisis Node2. Je déclare la DB3 comme une copy backup.

Première synchro. PG status: OK.

Je génère des logs (j'envoie une belle pièce jointe à 4 collègues, tous sur DB3). Je monte à plus de 100 logs...

Je constate les mêmes logs sur les Node1 et Node2: Normal!

->Je créer un recovery point de DB3. Stauts:Ok. Aucun log n'a été tronqué. Rien.

Je fais basculer mon DAG, pour que DB3 devienne active sur Node2.

->Je créer un recovery point de DB3. Stauts:Ok. -> rebelote Aucun log n'a été tronqué.

J'ai fait plusieurs fois l'opération. C'est net et sans bavure, une DB déclarée dans DPM comme une "Copy Backup" ne permet ni de synchroniser les logs toutes les 15 minutes, ni de tronquer les logs.

Je créer un nouveau PG, je choisi DB3 sur Node1 (actuellement en mode copie d'un point de vue Exchange), je la déclare "Full Backup" dans DPM.

-> Je créer un recovery point. Les logs sont tronqués sur Node1 et Node2.

-> Sur Node1 la "copie" à ce moment il y a quelques logs supplémentaires de reste (10 logs de marge de sécurité)

Reprenons…

Dans le cas d’un DAG sur 2 nœuds, où chaque nœud héberge des bases actives, vous pouvez choisir de déclarer ces bases, sur ce nœud, comme "Full backup” dans DPM. Vous gardez ainsi une logique entre DPM et Exchange en vous assurant que les bases préférées d’un nœud Exchange (bases habituellement en prod sur ce noeud1) sont aussi les bases préférées de DPM (Full Backup). Nous pourrions choisir justement de déclarer en Full backup une copie de ces bases, sur un autre nœud, pour limiter la charge du nœud Exchange, mais ceci n’a pas de sens si DPM doit de toute manière intervenir sur ce nœud pour faire une sauvegarde de copies d’autres bases… J’espère que vous me suivez :)

Il est possible faire un test de consistance automatiquement si le replica apparait comme inconsistant.

Pour chaque DB, DPM créer une partition “replica”et une partition “recovery points”

DPM va synchroniser son contenu avec le DAG Exchange pour provisionner la partition “replica” de chaque base. (Premier Express Full)

Actuellement, DB1 est active sur CEX1, DB2 est active sur CEX2

Comme pour le “preferred node” d’un cluster CCR Exchange 2007, DPM effectue toujours la synchro des logs sur la db déclarée préférrée ou “Full backup” lorsque celle ci est disponible. Ainsi, seul le replica de cette DB dispose des derniers logs synchronisés

Les recovery points créés après cette synchro ne seront disponibles que pour les Bases “Full Backup”.

Même après une bascule du DAG,DPM continu de contacter les DBs Déclarées comme “Full Backup

Lors de l’opération de Full Express, DPM effectue une synchro pour chaque DB.

Le recovery point qui sera créé après cette opération sera disponible pour chaque base, et chaque base dispose rigoureusement de la même info.

Tout est dans le titre!

http://msexchangeteam.com/archive/2009/10/08/452775.aspx