Sauvegardes, restauration et migration de versions de Bases SPIP

Une particularité de SPIP est sa capacité des gestion multi-base, tant au sens d’utiliser simultanément plusieurs jeux de tables en interrogation, en utilisant l’inter-opérabilité XML, qu’également plusieurs SGBD (MySQL historiquement, PostGresSQL , plutot SQLite, sans oublier les portages presque complets en Oracle notamment..).

Les versions successives de SPIP garantissent la compatibilité ascendante des données (et de la plupart des squelettes), mais le rechargement d’un export de base sur une autre version de SPIP, expose en général à des problèmes [1] .

En ces périodes de migration de versions SPIP, petit retour d’informations générales sur les diverses options utilisables pour transporter les données sans pertes.

Déplacer ou convertir une base de données SPIP met en jeux deux aspects :
-  le changement de moteur de base de données (ou même de serveur),
-  le changement de structure des tables SPIP entre deux versions.
et il ne faudrait pas omettre la gestion des champs ou tables spécifiques complémentaires, liés aux plugins ou améliorations personnalisées à SPIP.

Les Formats de la base de données

Une base de données SPIP est stockée dans un serveur de bases de données(MySQL, SQLite..) dans un jeu de tables normalisées, éventuellement avec un $prefix distinct du préfixe standard spip_.
Le format natif n’est pas toujours facilement transportable sans difficultés (encodages, moteur interne..) entre serveurs du même type, sans parler d’un changement de moteur de SGBD.

En plus de leur format interne, tous les moteurs SQL savent généralement faire un « dump » à un format spécifique, et un « export SQL » uniquement avec les instructions standard SQL [2] ; malheureusement ces « dump SQL » ne sont pas tous compatibles entre eux.

D’autre part, reprendre un format SQL nécessite souvent l’accès à un outil particulier (le moteur mysqld, ou PhpMyAdmin rendu intégré à spip par un plugin), nettement moins convivial que SPIP et pas toujours accessibles (meme par le webmestre), selon les contraintes système et sécurité posées par l’hébergeur.

SPIP avait donc depuis longtemps intégré dans son interface privée un outil de gestion des sauvegarde et restauration à un format natif -texte- inspiré de XML. Celui-ci est actuellement abandonné dans la nouvelle version SPIP3, en attendant qu’un plugin equivalent [3] soit finalisé ; mais cela pose le problème des imports et exports entre bases lors de la transition de SPIP2 en SPIP3.

Remarquons qu’un problème analogue est plus souvent traité, à savoir transférer un site distant vers un serveur local pour mise-au-point de nouveaux squelettes, ou au contraire Transférer un site local vers un site distant, ces démarches mettent en évidence l’ensemble des fichiers et étapes à respecter, mais restent implicitement sur la même version de base SPIP, voire une montée de version(cf.#migration ).

Certains plugins de Sauvegardes (Sauvegarde Automatique, et Mes_Fichiers..) apportent des facilités complémentaires, pour permettre l’envoi d’une sauvegarde par mail, ou la récupération aussi des documents [4] sans apporter de réponse au changement de format, voir au contraire en régression liée à phpMyAdmin.


Par ailleurs, un autre plugin « migration » permet de « transporter » [5] une base SPIP vers un autre serveur (base et documents joints et squelettes, donc sur le meme contenu déjà récupérable par Mes_Fichiers : lire la documentation de cet outil prodigieux, malheureusement uniquement référencé et documenté chez Nursit !

Le cas particulier du passage à SPIP 3

La version SPIP3est déjà largement utilisée [6] de façon fiable, et vous pourrez avoir envie d’y passer : cela est parfaitement raisonnable, après en avoir compris les implications, car le retour en arrière est quasiment impossible !

-  Il vous faut savoir que des modifications importantes de la structure de base de données sont automatiquement réalisées lors de la mise à jour, en particulier sur la gestion des tables liées aux Mots-clés [7] une extension de SPIP toujours considérée comme standard : tout retour en arrière vous obligera a des manipulations plus complexes, car vous seriez obligé de restaurer totalement une ancienne structure de base, donc avec PhpMyAdmin ou MySQL.

-  le système des plugins a également connu des modifications, liées à l’intégration de Bonux et la modification du descriptif traditionnel plugin.xml devenu paquet.xml pour la nouvelle version ; les plugins ne sont pas portés immédiatement : vérifier la compatibilité d’une nouvelle version avec un site testé en SPIP3 !

La démarche qui semble conseillée en tenant compte de ces deux points majeurs est la suivante :

  1. sauvegarde complète du site (y compris IMG , -base de donnée [8]- squelettes et répertoire des plugins installés
  2. suppression des repertoires de programmes, extensions et de cache, téléchargement de la nouvelle version [9].
    Spip 3 ouvre ou reconnaît la vieille base en MySQL sans problème (ou devrait) sans qu’il soit nécessaire de l’importer au départ....
  3. la prochaine connexion administrateur lance la procédure de montée de version,
    à faire suivre immédiatement d’une nouvelle sauvegarde (celle-ci génère un fichier sqlite).
  4. si vous voulez passer votre base en sqlite, détruisez votre connect.php [10] pour relancer une installation neuve SPIP 3 (qui propose sqlite par défaut.

A la fin de l’installation vous mettant en interface privé, il vous suffit de ré-importer la sauvegarde réalisée en SQLite à l’issue de l’étape 3.


Il vous reste désormais à découvrir les nouveautés de SPIP 3, exposées dans des articles (encore « privés ») sur les sites de la galaxie...

Notes

[1Plantages immédiats ou tardifs, les dysfonctionnements constatés ultérieurement s’expliquant par des changements sur la gestion des tables et index...

[2Les commandes du DDL : CREATE TABLE.... et INSERT des données.

[3Dump_xml ?

[4Les documents liés sont rangés à leur format d’origine dans les sous-répertoires d’un dossier ./IMG et autres fichiers liés[[.htaccess, Jeu de squelettes personnalisés, fichiers de fonctions...

[5Le transport est réalisé en ligne, directement entre les deux serveurs, et en temps réel !

[6Rappel : php 5 obligatoire...

[7Si vous utilisez cette extension dans vos squelettes, en navigation ou dans des plugins, vous devriez effectuer des tests intensifs sur une copie avant de vous lancer en migration d’un site de production...

[8Rappel : la sauvegarde Spip 2 est considérée comme « non-fiable » : vous pourriez/devriez faire aussi un export SQL

[9Je n’ai pas remis ici le lien du spip_loader.php ou du dernier .zip

[10Celui-ci fait référence au moteur MySQL..

Pour citer un expert des spipeurs :

1) SPIP 3 ne lit pas les dump.xml mais crée des dumps au format sqlite (il faut donc que sqlite soit présent sur l’hébergement, ce qui est le cas normalement avec les distributions de PHP par défaut ; cela n’est pas synonyme d’utiliser une base SQLite !!).

Si vous avez un dump.xml (SPIP 2.x ou antérieur) il faut d’abord ré-installer la version correspondante de SPIP (à la version du dump), importer le dump, puis mettre à jour le SPIP en 3.0 (c’est la procédure normalement qui devrait être faite à chaque fois). Un dump .xml n’est valable que pour une version de SPIP donnée. Cela dit, ça ne sera plus vraiment le cas à partir de SPIP 3 car le nouveau format de sauvegarde doit permettre justement de restaurer une base même depuis une version antérieure (une sauvegarde SPIP 3 lorsqu’on sera en SPIP 4 quoi).

2) un dump n’est qu’une méthode de sauvegarde. Vous pouvez tout aussi bien passer par phpmyadmin, exporter la table au format .sql (ou compressé) et la réimporter dans le phpmyadmin du nouveau serveur

3) vous pouvez même importer un dump.sql en ligne de commande via mysql si le fichier est trop gros pour phpmyadmin/php (une limite de taille est fixée en général).

En ligne de commande, ça donne (en supposant que vous êtes dans le répertoire où est votre sauvegarde .sql nommée ici ma_base.sql)

mysql -u nom_utilisateur -p
// saisie du password
// puis indiquer la bdd sur laquelle on veut importer les donnees
// (souvent le même nom que l'utilisateur chez un hébergeur)
use nom_de_la_base
// importer
source ma_base.sql
// s'enfuir
quit

N.B. : transporter le dump.sql vers un autre moteur de bases de données n’est pas garanti, car certaines définitions de champs ne sont pas compatibles : bidouillages garantis, succès non garanti !

Discussion

Une discussion

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom