Les tribulations d’un astronome

Spip et sqlite : sauvegarde de la base de données

jeudi 11 juin 2015 par Guillaume Blanc

Début avril, peu de temps après la migration de mon site sur OVH, hébergeur payant, j’avais un problème de base de données corrompue. J’ai pu réinstallé une sauvegarde antérieure de la dite base de données et tout fonctionna à nouveau correctement. Jusqu’à début juin.

Mercredi 3 juin. Mon site fonctionne. Mon site ne fonctionne plus. Ne fonctionne plus ?!!?? Ben oui, il indique stupidement :

Site en travaux
Attention : un problème technique (serveur SQL) empêche l’accès à cette partie du site. Merci de votre compréhension.


Un tour sur les forums spip ne me donnent pas d’indication prégnante si ce n’est que le problème semble récurrent au fil des ans. S’ensuit un long échange avec le support de mon hébergeur, OVH, qui me suggèrera un certain nombre de solutions, qui toutes échouèrent les unes après les autres, jusqu’à la dernière.

J’ai renommé le répertoire /tmp, ce qui déclencha la page de réinstallation côté administration du site. J’ai donc réinstallé spip. Évidemment, il était tout neuf après, mes articles en avaient disparu. J’avais par miracle une sauvegarde de la base de données qui datait un peu (un mois et demi), mais en la restaurant j’ai pu récupérer la quasi-totalité des articles, ne perdant que les derniers.

En creusant encore un peu la chose avec le support d’OVH, il m’a finalement expliqué que ma base de données étant sous sqlite, les sauvegardes standards d’OVH pour celle-ci ne fonctionnent pas (car en MySQL). En revanche, ma base est entièrement contenue dans un seul fichier qui se trouve dans le répertoire spip /config/bases/ sous le nom de la base .sqlite. Or OVH fournit des sauvegardes de l’ensemble de l’arborescence ftp que l’on peut récupérer par ftp selon la recette décrite ici. J’ai donc pu transférer le fichier .sqlite correspondant à l’état de mon site avant le problème, pour le mettre ensuite sur mon site actuel, et ainsi retrouver la quasi-totalité de mes articles (seuls quelques commentaires sont passés à la trappe, ce dont je m’excuse platement auprès de leurs auteurs).

Il est possible de faire une sauvegarde de la base de données via la partie administrateur de mon site, mais cette manipulation est manuelle, il faut penser à la faire, etc. D’ailleurs, je me pose la question de savoir, pour un site sous sqlite, comment est faite cette sauvegarde. Le plus simple étant de faire une copie du fichier .sqlite qui se trouve dans /config/bases/ pour le mettre dans /tmp/dump/.

Je vais réfléchir à écrire un script qui me fasse ça automatiquement à intervalle régulier. Ce serait pas mal du tout !


Addendum

Il y a le plugin spip autosave qui permet de configurer une sauvegarde automatique de la base de données. Mais cette sauvegarde est faite en format SQL (et non sqlite), qui n’est pas utilisable ensuite par l’outil spip de récupération de la base de données. En revanche il l’est par phpmyadmin, outil qui se trouve sur le serveur, en général (en tout cas chez OVH et Free). J’ai donc installé et configuré ce plugin.

Néanmoins, la possibilité évidente de récupérer le fichier entier de la base sqlite me titillait, j’ai donc mis au point un petit script en perl pour copier et renommer ce fichier dans /tmp/dump/, son exécution par une tâche cron sur le serveur OVH fait le reste.

Voici le script en question dans lequel il suffit de remplacer « NOM_BDD » par le nom de votre base de données. Puis de le transférer sur votre site par ftp, de ne pas oublier de le mettre en exécutable et enfin de configurer votre cron tab via l’interface de votre serveur.

#! /usr/bin/perl

use Cwd;

my $racine = cwd();
print "Racine = $racine \n";

$fichiersqlite = $racine . '/www/config/bases/NOM_BDD.sqlite';
print "Fichier source = $fichiersqlite \n";

$repertoirecible = $racine . '/www/tmp/dump/';
$fichiercible = $repertoirecible . '/NOM_BDD.sqlite';
system("cp  $fichiersqlite $repertoirecible");
($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime;
$date = sprintf("_%4s-%02s-%02s-%02sh%02s", $year+1900, $mon, $mday, $hour, $min);
$newname = $racine . '/www/tmp/dump/NOM_BDD' . $date . '.sqlite';
print "Fichier cible = $newname \n";
rename $fichiercible, $newname;

Accueil | Contact | Plan du site | | Statistiques du site | Visiteurs : 682 / 549430

Suivre la vie du site fr  Suivre la vie du site Blog  Suivre la vie du site Informatique   ?

Site réalisé avec SPIP 3.0.17 + AHUNTSIC

Creative Commons License

Visiteurs connectés : 6