Vous regardez une version antérieure (v. /confluence/display/BM35/Plan+de+Reprise+d%27Activite+PRA) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 3) afficher la version suivante »

Présentation

Cette documentation décrit la façon de restaurer un serveur BlueMind à partir d'un backup. La restauration d'un serveur peut prendre beaucoup de temps et ne devrait être utilisé qu'en dernier recours.

Sur cette page :

En rapport :
Restauration unitaire - Navigation DataProtect

Pré-requis

  • installer BlueMind dans la même version que celui du backup sur un nouveau serveur.
  • Le dossier /var/backups/bluemind doit être accessible en lecture/écriture sur le nouveau serveur.
  • Le nouveau serveur doit avoir la même adresse IP que l'ancien serveur. Il est possible d'attribuer l'IP au serveur même s'il n'est pas dans le même réseau et d'utiliser la méthode de changement d'adresse IP par la suite.

Méthode automatique

Après avoir installé BlueMind depuis l'installateur et avoir copié ou monté le backup dans /var/backups/bluemind il faut cliquer sur "Restauration globale" puis "Lancer la restauration".

A noter que la restauration automatique ne restaure pas les index Elasticsearch, il faudra donc relancer la tâche ReconstructMailspoolIndexJob pour réindexer les mails.

Méthode manuelle

Dans certains cas, en présence d'une installation multi-serveur notamment, il peut ne pas être possible d'utiliser la méthode automatique. Il est alors possible de restaurer le serveur manuellement depuis les backups.

La restauration manuelle n'est possible qu'à partir de la version 3.0.39 et de la version 3.5.5 pour la branche 3.5

Déterminer le backup à utiliser

Le fichier /var/backups/bluemind/generations.xml liste les backups disponibles ainsi que les différents dossiers composant un backup, par exemple :

<?xml version="1.0" encoding="UTF-8"?>
<generations xmlns="http://www.blue-mind.net/xsd/generations.xsd">
<dataProtect bmVersion="3.0.13753" genId="5215" protectedAt="1454461207966" size="32611762176" version="1">
<parts>
  <part begin="1454461208390" end="1454466554780" genId="5210" genSize="28959571968" host="192.168.131.14" tag="mail/imap"/>
  <part begin="1454466566013" end="1454471453454" genId="5211" genSize="3539992576" host="192.168.131.14" tag="bm/core"/>
  <part begin="1454471454913" end="1454471455456" genId="5212" genSize="1048576" host="192.168.131.14" tag="mail/archive"/>
  <part begin="1454471462994" end="1454471467515" genId="5213" genSize="110100480" host="192.168.131.14" tag="bm/pgsql"/>
  <part begin="1454471467999" end="1454471468171" genId="5214" genSize="1048576" host="192.168.131.14" tag="elasticsearch/mailspool"/>
</parts>
</dataProtect>
</generations>

Dans cet exemple on voit qu'il existe un seul backup (noeud dataProtect) composé de 5 parts. Le genId correspond à l'incrément de ce backup dans les dossiers de backups de chaque partie. Ce backup est donc composé des dossiers :

  • /var/backups/bluemind/dp_spool/rsync/IP_SERVER/dataprotect/5215/
  • /var/backups/bluemind/dp_spool/rsync/IP_SERVER/mail/imap/5210
  • /var/backups/bluemind/dp_spool/rsync/IP_SERVER/bm/core/5211
  • /var/backups/bluemind/dp_spool/rsync/IP_SERVER/mail/archive/5212
  • /var/backups/bluemind/dp_spool/rsync/IP_SERVER/bm/pgsql/5213
  • /var/backups/bluemind/dp_spool/rsync/IP_SERVER/elasticsearch/mailspool/5214

Par soucis de clarté ces dossiers seront référencés respectivement par mail/imap/XXX, bm/core/XXX, mail/archive/XXX, bm/pgsql/XXX et elasticsearch/mailspool/XXX

Restauration des données

# rm -Rf /var/spool/cyrus/*
# cp -Rfp mail/imap/1/var/spool/cyrus/* /var/spool/cyrus/
# cp -Rfp mail/imap/1/var/lib/cyrus/* /var/lib/cyrus/
# cp -Rfp mail/archive/XXX/var/ /
# cp -Rfp bm/core/4/var/spool/bm-docs /var/spool/
# cp -Rfp elasticsearch/mailspool/3/* /

Restauration de la configuration

  1. Restauration de la configuration :

    # cp -rfp bm/core/XXX/var/backups/bluemind/work/conf/etc /
# cp -rfp bm/core/XXX/var/backups/bluemind/work/conf/usr /

  2. Restauration de la base de données :

    # bmctl stop
# /etc/init.d/bm-node stop

# su - postgres
$ dropdb bj
$ createdb bj
$ exit
# PGPASSWORD=bj psql -U bj -h localhost bj < bm/pgsql/XXX/var/backups/bluemind/work/bm_pgsql/bluemind.pgdump.sql
# /etc/init.d/bm-node start
# /etc/init.d/postfix restart
# bmctl start

Restauration des filtres Sieve

Pour regénérer les scripts Sieve, il suffit d’exécuter le script suivant avec comme argument le nom du domaine (à effectuer pour chaque domaine à restaurer)

updateAllFilters.py

Post-restauration

Se connecter à la console d'administration de BlueMind en tant qu'utilisateur admin0@global.virt puis:

  • Se rendre dans la partie Sécurité > Gestion du pare-feu et cliquer immédiatement sur le bouton "Enregistrer" pour forcer la re-génération des règles du parefeu BlueMind
  • Se rendre dans la partie Gestion du Système > Maintenance des mails, cliquer sur le bouton "Exécuter" pour re-générer les tables de routage de mails postfix

Enregistrer

Enregistrer

Enregistrer

  • Aucune étiquette