IceWarp toutes versions -
Voici la procédure conseillée si vous voulez changer de serveur physique.
On suppose ici que le serveur cible est un serveur vierge du point de vue d'IceWarp. Si ce n'était pas le cas (il existe des domaines et comptes en production), il faut utiliser une autre procédure décrite dans ce document.
1 - Préparation du serveur cible
Sur le serveur cible : installer le serveur IceWarp ayant la même version que celle du serveur source et au même emplacement sur le disque (répertoires).
Le version doit être exactement la même y compris la notion 32/64 bits. Donc si vous passez d'une machine 32 bits à 64 bits, il faut d'abord installer une version 32 bits puis, une fois le serveur opérationnel installer la version 64 bits.
Pour la licence, vous utilisez une version d'évaluation de 30 jours.
Si vous utilisez une base de données sur le serveur source, installez le même logiciel base de données sur le serveur cible avec les mêmes noms.
Il est important que la configuration du serveur cible soit identique à celle du serveur source (répertoires, version IceWarp, bases de données), si des évolutions sont nécessaires, elles peuvent être effectuées après.
Si vous avez fait dans le serveur source des modifications directement dans les fichiers de l'application (certaines modifications de présentation en particulier), il faut les reporter sur la nouvelle installation (comme pour toute mise à jour).
Si le chemin principal d'installation d'IceWarp est différent et qu'il est difficile de le rendre identique, il faut faire l'opération suivante après restauration de la configuration du serveur (cf. § 3) :
- Ouvrir la console API (menu Fichier de la console d'administration)
- Mettre dans le filtre le nom de l'ancien chemin ("Program files" par exemple)
- Modifier toutes les lignes qui apparaissent pour donner le nouveau nom du chemin
2 - Copier les données volumineuses sur la nouvelle installation
Si tous vos fichiers sont de volumes faibles (copie possible en quelques minutes), vous pouvez sauter cette étape.
La difficulté vient du fait que le temps de recopie des données peut être important (pour le répertoire email en particulier) et qu'il est nécessaire de bloquer l'utilisation du serveur pendant ce temps pour ne pas perdre de messages ou des modifications effectuées par les utilisateurs.
La méthode consiste donc à faire une mise à jour incrémentale du serveur cible en utilisant un outil approprié. La mise à jour peut alors s'effectuer en plusieurs étapes de plus en plus courtes et le serveur d'origine n'est bloqué que pendant la dernière étape. Le principe est le suivant :
- lancer la copie du répertoire mail (il comprend les emails mais aussi tous les fichiers des comptes) en mode différentiel. Il est certain que cela va faire du trafic important sur votre serveur. Pour ne pas pénaliser le fonctionnement de la messagerie, vous pouvez faire la copie sur une deuxième carte réseau du serveur IceWarp (si possible).
- attendre que la copie se termine (même si cela prend plusieurs heures)
- pendant ce temps, des fichiers sont ajoutés/supprimés dans l'ancien serveur par les processus IceWarp
- lancer la copie une seconde fois. Cette fois-ci elle ne fera que le différentiel et doit donc durer beaucoup moins de temps
- répéter le processus 3-4 fois; vers la fin une copie ne durera que quelques minutes
Pour la copie des emails, il faut utiliser un outil de copie incrémental
qui conserve la date d'écriture des fichiers sinon, tous les messages
auront la date du jour de la copie. par exemple :
1/ rsync en ligne de commande
(http://sourceforge.net/projects/rsyncforwindows/files/) ou rsync +
deltacopy pour une interface graphique
(http://www.aboutmyx.com/files/DeltaCopy.zip)
Utiliser "-v -rlt -z -p --chmod=u=rwx,g=rwx,o=rwx" comme arguments
2/ robocopy (http://www.microsoft.com/en-us/download/details.aspx?id=17657)
robocopy D:\ICEWARPMAIL\Mail\ \\nouveauserveur\mail\ /MIR /SEC
Important: Quelle que soit la méthode, valider les arguments sur un répertoire de test
3 - Basculer de serveur
- Programmer une heure de transition et prévenir vos utilisateurs
- Arrêter tous les services sur le serveur source (il faut, le cas échéant, désactiver le contrôle des services)
- Faire une dernière copie du répertoire mail
- Faire une copie des autres données :
* restauration de la configuration serveur (Fichier -> Sauvegarder la configuration au format .zip)
* les bases externes (Si vous n'en avez pas, le .zip va contenir vos bases SQlite)
* le dossier archive s'il n'est pas trop volumineux (sinon, il faut l'inclure dans la procédure des mails)
* toutes les données spécifiques : sites ajoutés, fichiers modifiés manuellement...
- Vérifier le bon fonctionnement du nouveau serveur
- Faites pointer les emails vers le nouveau serveur par une de ces méthodes :
- Inverser les adresses IP des deux serveurs
- Changer les enregistrements MX du (des) domaine(s) pour pointer
vers le nouveau serveur (il faudra un certain temps de prise en compte)
- Modifier simplement les paramètres du routeur si les
deux serveurs sont dans le même réseau local
Ne plus lancer de copie du répertoire mail (ce qui supprimerait les nouveaux mails sur le nouveau serveur qui ne sont pas présents sur l'ancien serveur)
4 - Gérer la licence
Sur le serveur cible, vous ne bénéficiez plus que d'une licence provisoire de 7 jours à cause du changement de serveur. Pour ré-obtenir votre licence d'origine, il faut vous munir de l'identification de la commande d'origine (dans Aide -> Licence) et activer le bouton "Activer la Licence" ; entrez la commande et activez la licence.
Attention : cette opération n'est acceptée que 3 fois par an, au delà, il faudra vous adresser à votre revendeur.
Modifié le 15/07/2021