Réinstaller Dolibarr sur un serveur mutualisé OVH

Pré-requis

une sauvegarde de votre base de données (fichier dump, fait par mysqldump avec mysql par exemple).une sauvegarde de votre répertoire documents completconnaître le login et mot de passe de l'administrateur que vous utilisiez pour accéder au Dolibarr qui a été sauvegardé.

Première étape : Réinstaller le logiciel Dolibarr

Si vous avez désinstallé Dolibarr ou que vous ne l'avez pas encore installé (par ex. si vous êtes sur un nouveau serveur), installez Dolibarr comme si vous vouliez l'utiliser pour la première fois avec des données fraîches.

Attention à utiliser le même type de base de données qu'auparavant (Mysql, PostgreSQL…).Vous devez installer exactement la même version (vX.Y) que celle qui était utilisée lors de votre sauvegarde.Si vous voulez pour monter de version, il faut le faire dans un second temps.

Si la sauvegarde a été faite depuis Dolibarr, la version de Dolibarr sauvegardé est incluse dans le nom du fichier de sauvegarde de la base de données.

Autres étapes

Restaurer les fichiers documentsconnectez-vous en administrateur sur votre nouvelle installation de DolibarrDans la colonne de gauche, allez à Accueil > Outils d'administration > Restauration ; Dolibarr affiche l'emplacement de votre répertoire des fichiers documents :Extrayez le fichier archive (fichier zip par exemple) du répertoire documentsConnectez-vous à votre nouveau dolibarr via FTPVidez le répertoire dolibarr/documentsCopiez le contenu de votre répertoire sauvegardé dans le répertoire documents de votre nouvelle installation de dolibarr.Restaurer la base de données MySQL :Si votre fichier de sauvegarde est une archive compressée, décompresser le fichier auparavant → *.sqlSur votre nouvelle installation de Dolibarr, connectez-vous avec un compte administrateurAllez dans le menu Accueil > Outils d'administration > RestaurationParagraphe 2, méthode d'importation : MySQL
Dolibarr affiche une commande à lancer en ligne de commande avec le mot de passe masqué pour réaliser la restauration de la base de donnée.
Cliquez sur “Afficher la commande complète” pour avoir la commande complète avec le mot de passe non masqué. Par exemple, on aura :

mysql base_de_données -h nom_ou_ip_serveur -P 3306 -u utilisateur -pvotremotdepasse < monfichiersauvegarde.sql

base_de_données : nom de la base de données MySQL qui contiendra vos données Dolibarr,nom_ou_ip_serveur : nom de la machine sur laquelle sera restaurée la base de données. Cela peut être 'localhost' qui est le nom générique de la machine locale sur laquelle vous opérez. Si la base doit être restaurée sur un autre système que la machine locale, remplacer localhost par le nom ou l'adresse IP du système distant en question.-P 3306 : port TCP/IP utilisé par MySQL (peut être omis, sauf cas particuliers)utilisateur : utilisateur privilégié MySQL que Dolibarr utilise pour se connecter à la base de donnéesvotremotdepasse : mot de passe du compte utilisateur MySQL (attention pas d'espaces entre le p et le mot de passe)monfichiersauvegarde.sql : nom du fichier dump (ex. mysqldump_dolibarr_2.7.0_200812021800.sql)Dans un terminal,Allez dans le répertoire où est enregistré le fichier de sauvegarde à restaurer.Lancez la commande fournie précédemment (n'oubliez aucun espace, signe “-” ou “<”)Vous pouvez également utiliser Adminer :cliquez sur le lien Importercliquez sur Parcourir pour sélectionner votre fichier de sauvegarde (normalement, vous n'aurez à cocher aucune option en particulier, mais votre fichier de sauvegarde doit absolument désactiver FOREIGN_KEY_CHECKS, voir Problèmes connus)Cliquez sur ExécuterLes résultats de cette méthode ne sont pas garantis contrairement à la méthode précédente.

Conclusion

Problèmes connus

Si vous avez cette erreur, vous devez manuellement détruire la table llx_accounting_account et llx_accounting_system, avant de recommencer la tentative de chargement.

Votre dump sql doit désactiver les vérifications de Foreign Keys pendant la restauration, sinon votre backup SQL ne pourra pas être restauré à cause des clashs entre les Foreign Keys! Ceci devrait être le cas par défaut si vous avez effectué votre sauvegarde correctement.

Exemple: Ajouter FOREIGN_KEY_CHECKS au tout début et à la fin du fichier sql:

-- SQL Dump -- Server version: 5.5.8 SET FOREIGN_KEY_CHECKS=0; SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; CREATE TABLE IF NOT EXISTS `llx_accountingaccount` ( INSERT INTO ... CREATE TABLE ... INSERT INTO ... ... SET FOREIGN_KEY_CHECKS=1;

767 octets est la limite de préfixe indiquée pour les tables InnoDB dans MySQL version 5.6 (et versions antérieures). Elle fait 1 000 octets pour les tables MyISAM. Dans MySQL version 5.7 et supérieures, cette limite a été augmentée à 3072 octets.

Sachez aussi que si vous définissez un index sur un grand champ char ou varchar encodé en utf8mb4, vous devez diviser par 4 la longueur maximale du préfixe d'index de 767 octets (ou 3072 octets), ce qui donne 191. En effet, la longueur maximale d'un caractère utf8mb4 est de quatre octets. Pour un caractère utf8, elle serait de trois octets, ce qui donnerait une longueur maximale de préfixe d'index de 254.

Une solution est de placer une limite inférieure sur vos champs VARCHAR.

Une autre option (selon la réponse à ce problème) consiste à utiliser un sous-ensemble de la colonne plutôt que le montant total, c'est-à-dire :

ALTER TABLE `mytable` ADD UNIQUE ( column1(15), column2(200) );

Ajustez au fur et à mesure que vous devez obtenir la clé à appliquer, mais je me demande s'il vaudrait la peine de revoir votre modèle de données concernant cette entité pour voir s'il y a des améliorations qui vous permettraient d'implémenter les règles métier prévues sans atteindre la limitation MySQL.

Voir aussi

(fr) https://wiki.dolibarr.org/index.php?title=Restaurations

Basé sur « Restaurations » par wiki.dolibarr.org.