Un des soucis récurrent du webmestre d’un site sous SPIP c’est d’avoir la certitude qu’en cas de « crash » de son site (serveur planté, mauvaise manip...) il puisse récupérer l’ensemble des données de la base MySQL afin de pouvoir rétablir son site « à l’identique ».
Cela implique d’avoir une sauvegarde de cette base de données qui inclut tous les éléments saisis par les utilisateurs (articles, brèves, sites référencés, auteurs...) au fur et à mesure que ceux-ci enrichissent le contenu du site.
Alors si votre site est actif, à moins que vous ne soyez un forcené de la sauvegarde manuelle en utilisant l’outil intégré dans l’administration de SPIP, il y a fortes chances que votre dernière sauvegarde ne soit pas à jour...
Ce plugin, reprise d’une « vieille » contrib de Silicium (publiée à l’époque sur le site japanim.net), permet d’automatiser le processus de sauvegarde de votre base de données afin que vous n’ayez jamais à annoncer à vos rédacteurs que « ...le serveur à planté, il va falloir refaire la saisie de vos n derniers articles... ».
1. Ce plugin permet :
- de réaliser une sauvegarde complète de la base de données du SPIP selon une fréquence déterminée. Cette sauvegarde est au format .sql (ou gzippé si votre serveur le permet). Elle est totalement compatible avec le format des fichiers sql utilisés par votre phpmyadmin.
- de paramétrer les tables à sauvegarder (ou au contraire à ne pas sauvegarder) : la sauvegarde étant réalisée au niveau de la base, par défaut elle comprend l’ensemble des tables (pas seulement celles de SPIP) mais vous pouvez configurer précisément les tables que vous désirez inclure dedans.
- de stocker ces sauvegardes dans un répertoire de votre choix
- d’envoyer les fichier de sauvegarde par mail à une adresse de votre choix
- de configurer la « durée de vie » des fichiers de sauvegarde stockés
2. Installation du plugin saveauto :
En fonction de votre SPIP récupérez le zip correspondant sur https://plugins.spip.net/saveauto/, décompactez le et placez le dossier « saveauto_X_Y » obtenu dans votre répertoire /plugins (à créer à la racine de votre spip si nécessaire), rendez vous sur l’interface de gestion des plugins (menu Configuration > Gestion des plugins), cochez le plugin « saveauto » et validez.
Ce plugin ne modifie pas les tables de la base données de SPIP, il n’en crée pas de nouvelles : pour sa désinstallation complète, il suffira d’effacer le répertoire /plugins/saveauto.
3. Versions
Ce plugin existe en 4 versions : saveauto_1_9_2 pour spip 1.9.2, saveauto_2_0 pour spip 2.0.*, saveauto_2_1 pour spip 2.1.* et saveauto_3_0 pour spip 3.0.*.
[ v. 1_9_1 ]
Lorsque la configuration du plugin est modifiée (via l’interface d’administration) le fichier /plugins/saveauto/inc/saveauto_conf.php qui stocke le paramétrage des sauvegarde est réécrit : selon la configuration du serveur qui vous héberge, il sera peut être nécessaire de modifier ses droits afin que cette réécriture soit possible (en cas de problème vous en serez averti lors de la validation d’une nouvelle config par l’interface d’administration).
[ v. 1_9_2]
L’enregistrement de la configuration et l’interface de gestion de celle-ci est basé sur le plugin config (cfg). Ce plugin doit être installé et activé pour que saveauto_1_9_2 fonctionne. Ce plugin permet la sérialisation des données de configuration et leur enregistrement dans la table spip_meta (de cette façon il n’est plus nécessaire de gérer un répertoire à accès en écriture pour le serveur comme le fait la version saveauto_1_9_1).
[ v. 2_0]
Passage en version compatible SPIP 2.0.*. L’interface de configuration est désormais accessible via le menu Configuration > CFG > Saveauto (le bouton dans le menu à été supprimé vu s le peu de fois où il était utilisé dans la vie du site)
Pour l’instant pas d’incompatibilités repérées avec d’autres plugins (pas de surcharge des fichiers du core de spip).
[ v. 3_0]
Passage en version compatible SPIP 3.0.*.
L’interface de configuration est désormais accessible via le menu Configuration > Sauvegarde automatique avec de nombreuses nouvelles options (en particulier pour l’envoi par mail des sauvegardes).
Désormais dans la page Maintenance > Sauvegarder la base (ecrire/ ?exec=sauvegarder) il est possible de déclencher « manuellement » une sauvegarde et l’outil propose aussi :
- une possibilité de déclenchement manuel
- la liste des sauvegardes disponibles, téléchargeables
4. Fonctionnement obtenu lorsque l’on intègre ce plugin :
Les sauvegardes ne sont PAS déclenchées par un « programmateur » (spip_cron) mais sont lancées lorsqu’un utilisateur (auteur ou administrateur selon le paramètre « Sauvegarde déclenchée lors de la connexion d’un auteur ») se connecte dans l’espace privé. De cette façon tant qu’il n’y a pas d’accès à l’espace privé (cad que le contenu du SPIP ne change pas) il n’y a pas de création d’éventuels « doublons » des sauvegardes.
En revanche à chaque connexion à l’espace privé, le script est lancé : il vérifie si le temps écoulé depuis la dernière sauvegarde est supérieur à la fréquence déterminée dans la configuration (paramètre « Fréquence de la sauvegarde »), et , si c’est le cas, crée un nouveau fichier de sauvegarde dans le répertoire indiqué par le paramètre « Répertoire de stockage » de l’interface d’admin.
Si l’option « Zipper le fichier de sauvegarde » est activée, le fichier sql généré est zippé (version 0.5.2 minimum).
Par défaut ces sauvegardes sont stockées dans le répertoire /tmp de votre SPIP, si vous modifiez ce paramètre vous devez vous assurer que le répertoire utilisé est autorisé en écriture pour le serveur (777 avec votre client FTP en général) et que le chemin (relatif à la racine de votre spip) indiqué se termine bien par un « / » (par ex. : /tmp/sauvegardes/).
Si vous utilisez un répertoire différent de celui par défaut, gardez à l’esprit que celui-ci devrait être sécurisé pour qu’il ne puisse pas être accessible depuis internet : les fichiers de sauvegardes contiennent l’ensemble des données des articles, rubriques, brèves publiés ou non (et là, pas question « d’accès restreint »...)
Si la configuration le précise (paramètre « Sauvegardes envoyées à l’adresse ») et si votre hébergement autorise la fonction mail() de php, le fichier de sauvegarde obtenu sera envoyé à l’adresse mail de votre choix. Il est conseillé d’installer le plugin Facteur pour ajouter le fichier de sauvegarde en pièce jointe.
En fonction du nombre de jours configuré dans le paramètre « Sauvegardes considérées obsolètes après », le script va effacer les fichiers de sauvegardes dont l’âge est supérieur au nombre de jours configuré.
Les tables à sauvegarder (ou non) sont déterminées par les paramètres « Tables acceptées » et « Données ignorées » : par défaut le plugin sauvegarde toutes les tables (y compris celles qui n’appartiennent pas à SPIP) sauf celles dont le nom comprend « _index », « _temp » ou « _cache » (qui sont utilisées par SPIP pour stocker des données volumineuses mais non-indispensables pour rétablir son intégrité : leur structure seule est sauvegardée).
De la même manière, le paramètre « Eléments à sauvegarder » permet de choisir (de façon globale) si vous voulez sauvegarder la structure et/ou les données des tables (option réservée aux administrateurs maitrisant ces concepts : si cela ne vous parle pas, choisissez « oui » pour les 2 choix proposés dans ce paramètre !).
Pour finir avec les options configurables vous pourrez également préciser :
- le nom de la base de données de votre SPIP : ce paramètre ne sert qu’à composer le nom des fichiers de sauvegarde (par défaut de la forme : « nom_base_spip_2006 »). De façon complémentaire le paramètre optionnel « Préfixe pour les sauvegardes » permet de composer des noms de fichiers encore plus complets : ce qui peut donner des noms de la forme « prefixe_nom_base_spip_2006 ».
- si vous souhaitez qu’un message s’affiche lorsque la sauvegarde à été effectuée (à éviter si vous choisissez de faire déclencher la sauvegarde lors de la connexion des auteurs...)
5. Restauration des sauvegardes à partir des fichiers générés par le plugin :
[*Attention !!!*] les sauvegardes réalisées ne sont pas au format de celles de SPIP : Inutile d’essayer de les utiliser avec l’outil d’administration de Spip.
Pour toute restauration il faut utiliser l’interface phpmyadmin de votre serveur de base de données : dans l’onglet « SQL » utiliser le bouton « Emplacement du fichier texte » pour sélectionner le fichier de sauvegarde (cocher l’option « gzippé » si nécessaire) puis valider.
Les sauvegardes xxxx.sql.zip ou xxx.sql sont au format SQL c’est à dire qu’ils contiennent les commandes permettant d’effacer les tables existantes du SPIP et de les remplacer par les données archivées. Les données plus récentes que celles de la sauvegarde seront donc PERDUES !
6. Ce qu’il reste à faire :
- la sauvegarde des données de la base est une chose, mais de plus en plus les sites sous SPIP ont toute une partie de leur contenu sous forme de fichiers « annexes » (images, pdf, sons, images...) qui sont stockés dans le répertoire /IMG : il serait donc intéressant d’avoir la possibilité de faire une sauvegarde de ceux-ci sous forme d’un fichier compressé qui serait transféré par FTP sur un autre serveur (je n’imagine pas l’envoi par mail vu le volume que cela représente !)
- les fichiers de langues pour les utilisateurs ne causant pas le french
Comme pour beaucoup d’autres plugins, afin de faciliter le developpement collaboratif, vous trouverez l’ensemble des fichiers en cours sur le SVN de spip-zone : avis aux motivés !
Discussions par date d’activité
79 discussions
Bonjour,
Pour ma part depuis la MàJ du plugin en v.1.1.5 sur un SPIP 3.016, j’ai des envois par mails qui m’arrivent mais les messages sont incompréhensibles et aucune pièce jointe zippée n’y est jointe (ce qui fonctionnait parfaitement avec les versions précédentes).
Voici ce que je lis dans ces mails :
Les XXXXXXXXXXXX remplace le vrai nom de la base...
Aurais-tu une solution ?
T’en remerciant par avance.
Répondre à ce message
Bonjour,
pour ma part, depuis la MAJ vers spip 3.0.13, la sauvegarde régulière ne se fait pas.
Mes dossier tmp et dump sont en 777, les sauvegardes manuelles fonctionnent bien. Je n’arrive pas à voir d’où vient le problème.
Idem pour moi apparemment (spip 3.0.14, saveauto 1.1.3, plusieurs sites en mutualisation spip)
Pour aller plus loin dans le débogage de ce problème, il faudrait tester le déclenchement de la tache de sauvegarde via l’utilitaire de gestion des tâches cron de SPIP (job_queue) et scruter les éventuelles erreurs.
Pour cela :
define('_LOG_FILTRE_GRAVITE', 8);
cf http://www.spip.net/fr_article5543.html#_LOG_FILTRE_GRAVITE
Hello, voici le résultat de la manip, pas contre impossible de comprendre quoi que ce soit :/ je suis une bille ...
visible via ce lien :
https://www.dropbox.com/s/hvr6ts7l6cxus75/spip_log.rtf
comme constaté via IRC et pour fermer ce fil de discussion, il semblerait que les sauvegardes et l’envoi des messages avec le zip soient OK (cf « Executer maintenant » de saveauto dans Maintenance / Liste des travaux) mais que le site n’ayant pas une fréquentation suffisante, le cron SPIP ne se déclenche pas.
Pour ceux qui seraient dans ce cas et qui ont un accès à l’administration des crons de leur serveur, une solution est d’utiliser le « supercron » : cf http://www.mediaspip.net/documentat...
Merci pour les précisions.
A partir de quand la fréquentation est suffisante ? Là j’ai des sites avec 100, 200, 300 visites par jour, et la sauvegarde auto régulière ne se fait pourtant pas (spip 3.0.13).
Mais peut-être que ça vient du fait qu’ils sont en « mutualisation du noyau spip » ? (le chemin qui se met automatiquement dans la config Sauvegardeauto étant « ../sites/mesdomaines.net/tmp/dump/ »)
Pourtant, j’ai un autre site spip en 30.13 standard (installation unique), mais rien ne se sauvegarde non plus, celui-ci à très peu de visites en revanche, mais rien ne se sauvegarde aux connections admins ni aux moments des modifications de contenus du site.
Apparemment, sur mon hébergeur Gandi Simple hosting, il y a anacron pour programmer des tâches, mais je ne connais pas, jamais utilisé ces fonctions là...
Après avoir activé l’envoi par email des zip de sauvegardes régulières, j’ai testé " Executer maintenant » de saveauto dans Maintenance / Liste des travaux", et là en effet j’ai bien reçu le mail avec la base.
Donc, je vais passer mes sites en envoi par mail des zip pour mes sauvegardes régulières, et là ça devrait marcher ?
en principe si le déclenchement manuel de la sauvegarde via job_queue est OK (Maintenance > Liste des travaux) alors la sauvegarde par cron devrait faire exactement le même résultat. Si ce n’est pas le cas cela est quasi forcément lié à un non-déclenchement du cron SPIP.
En principe une fréquentation même faible doit suffire.
Ok, donc les envois auto des bases zippées par email devraient marcher, d’ailleurs je crois que j’en ai eu un déjà.
En revanche, en cas de sauvegarde auto dans un dossier dump, l’activation manuelle d’une sauvegarde dans « Maintenance > Liste des travaux » ne donnait rien dans dump.
Rectification, les envois auto des bases zippées par email ne marchent pas non plus, je n’en ai pas reçues. Ca fonctionne seulement si on clique sur le bouton dans la liste des travaux
pour ma part sur un site avec 200 à 300 visites par jour, je n’ai effectivement plus de sauvegarde automatique, le cron ne tournant plus. Peut-être un souci avec SPIP ?
Vu que cela date de la version 3.0.13 c’est sans doute qu’un changement à eu lieu.
Je confirme : sur un site avec une cinquantaine de visites par jour, plus de sauvegardes automatiques depuis la mi-janvier. Donc, à priori depuis SPIP 3.0.13 ou 3.0.14 (je ne me souviens plus quand j’ai fait la mise à jour).
Bonjour,
Pour moi non plus les sauvegardes automatiques ne fonctionnent plus (pas de dump généré, pas d’email envoyé) sur des sites en SPIP 3.0.16 [21266] avec ce plugin version 1.1.4 SVN [82084]. Dernière sauvegarde par CRON dans les logs : 04/04/14
Les sites ont pour les 2 plus gros 600 visites/jour en moyenne.
Le déclenchement manuel de la sauvegarde fonctionne (mais pas de mail reçu)
La réinitialisation des tâches cron n’y change rien.
C’est bien bloquant car cette méthode a(vait) l’avantage de générer des dump SQL et pas Sqlite (sqlite fout le bazar dans l’encodage des caractères).
Si c’est aidant je veux bien envoyer des logs.
dd
Le pb n’était pas dans la mise à jour de SPIP, mais bien dans celle du plugin, qui a eu lieu en même tps. La version 1.1.5, qui devrait être disponibles dans la mise à jour automatique des plugins après 18h30 devrait résoudre ce pb (cf http://zone.spip.org/trac/spip-zone/changeset/82617).
Tout remarche parfaitement pour moi depuis la MAJ.
Suppression des anciennes sauvegardes : Ok
Sauvegarde automatique CRON : OK
Merci
alors honte sur moi pour cette maj pas suffisamment testée...
...et merci Maïeul pour le débogage !
Tout est rentré dans l’ordre depuis la dernière maj. merci !
Répondre à ce message
Bonjour,
Je viens d’installer la dernière version 1.1.3, dans le menu de sauvegarde automatique il est est indiqué :
souhaitez choisir précisément les tables à sauvegarder (ainsi que des tables non SPIP) ouvrez la liste en décochant la case ci-dessous...
Mais lorsque je décoche la case, il ne me propose que les tables spip du site courant.
Les tables spip des sites mutualisés n’apparaissent pas ainsi que les tables extra !
Il faudrait une case à cocher pour proposer de sauvegarder toutes les tables de la base sans exception !
C’est si difficile que ça à faire ?
Sans cette option, ce plugin ne m’est d’aucune utilité.
Merci.
oui c’est difficile de faire du débogage de fonctionnalités que l’on ne maintient que pour un très petit nombre d’utilisateurs (un seul semble-t-il dans ce cas...) surtout quand ceux-ci font des rapports de bogues aussi peu précis et sur un ton aussi désagréable que celui de tes commentaires !
Bref, la version 1.1.4 devrait corriger ce problème : merci de tester et de faire un retour précis et détaillé si ça ne convenait toujours pas...
je plussoie à cy_altern. Les dev de plugins ne sont pas aux services des raleurs...
Répondre à ce message
Salut,
j’ai un truc bizarre : ma BDD est en UTF-8, mais le .sql produit encode mal l’UTF-8, j’ai des signes cabalistiques.
Une idée de la cause possible ?
J’ai un souci similaire. Je ne sais pas si c’est le même, mais, disons que j’ai aussi un gros souci de caractères accentués. J’avais d’ailleurs posé un commentaire (voir au 10 avril) :
Si j’importe dans phpmyadmin un base exportée par saveauto, je me retrouve avec des � un peu partout.
Si, au contraire, j’exporte la base originale par phpmyadmin puis que je l’importe par phpmyadmin, l’importation se déroule sans souci (=par de souci avec les caractères accentués)...
Quel est ce mystère mystérieux ?
@Maïeul : est-ce pareil pour toi ?
Un petit up… (Pas de réponse… elle était pas bien notre petite question ?
Répondre à ce message
Bonjour,
je viens de passer mes sites spip en v3 (j’étais en v2), et j’ai donc mis à jour tous mes plugins.
J’utilise maintenant la version1.06 de ce plugin.
Malheureusement, bien que je clique sur ’Sauvegarder toutes les tables’, ce plugin ne sauvegarde que les tables du site en question, et non pas les tables des autres sites mutualisés, ni les tables supplémentaires, ce que faisait l’ancienne version !
Donc, si ce plugin ne fait rien de plus que ce que fait par défaut spip, quel est son intérêt ?
Lorsque l’on clique sur ’Sauvegarder toutes les tables’, merci de sauvegarder toutes les tables de la base de données.
Merci,
Chris.
L’intérêt principal de ce plugin est de générer automatiquement des sauvegardes au format dump MySQL donc utilisables avec tous les outils MySQL et en particulier PhpMyAdmin (contrairement aux sauvegardes SPIP).
Pour ce qui est de la sauvegarde des tables non SPIP, la version 1.1.1 sortie ce jour rétabli la possibilité de les sauvegarder (décocher l’option « Sauvegarder toutes les tables de SPIP » pour les choisir).
Bonjour,
Je viens de mettre à jour avec la version 1.1.2, et on peut maintenant en effet sélectionner toutes les tables dans le menu ’Sauvegarder la base’, mais pas dans le menu de configuration du plugin.
Encore un petit effort, et ce sera parfait.
Merci.
Répondre à ce message
choix du répertoire de sauvegarde
Sur un SPIP 3 + saveauto, il n’y a apparemment plus la possibilité de choisir le répertoire de sauvegarde…
Sur mes sites en SPIP 2, je mettais ça toujours dans un répertoire spécifique en dehors de top : je trouvais ça plus clair et moins… dangereux car des vidages un peu brutaux de tmp, ça peut arriver !
Y-a-t-il un moyen de pouvoir choisir une destination ?
Merci d’avance
Ouppps, petite erreur de frappe dans mon message ci dessus :
il fallait lire
Sur mes sites en SPIP 2, je mettais ça toujours dans un répertoire spécifique en dehors de tmp/ (et pas : en dehors de top )
la version 1.1.1 sortie ce jour rétabli la possibilité de choisir le répertoire dans lequel stocker ses sauvegardes.
Attention ! ce répertoire doit exister et être accessible en écriture par le serveur.
Super !
Merci beaucoup !
Répondre à ce message
Bonjour,
je viens de m’apercevoir que la sauvegarde automatique installée sur mon site ne fonctionnait pas (ou plus). Le répertoire tmp/dump est vide.
En lançant une sauvegarde manuelle, j’obtiens le message suivant :
Fatal error : Allowed memory size of 134217728 bytes exhausted (tried to allocate 124256360 bytes) in /home/www/37ed00d3b7b4d8da7c19d082a00db6f8/web/plugins/auto/saveauto/v1.0.6/inc/saveauto.php on line 146
Je suis sous Spip 3.0.11 et Sarka-Spip 3.2.32. La version du plugin est la dernière (1.0.6).
Merci d’avance à qui pourra m’aider.
Cordialement.
Pour ce problème ce sont les ressources du serveur (la quantité de mémoire pour ton compte) qui sont en cause. Pas d’autre solution que de trouver un hébergement qui est plus généreux.
Répondre à ce message
Bonjour,
Je ne comprends pas pourquoi j’ai plein de caractères bizarres après la récupération d’une sauvegarde dans phpmyadmin (5.5.32).
Mon site est UTF8, la base aussi et le meta charset est bien UTF8 dans le header.
Dans les tables de la base les caractères sont corrects mais pas l’affichage du site (public et privé).
config : SPIP 3.0.11
saveauto : 1.0.6 SVN [74715]
merci
dd
Répondre à ce message
Bonjour
Ce plugin ne fonctionne pas sur mes sites en Spip 2.1.23 et je nee comprends pas pourquoi.
Un étonnement, d’ailleurs, pas de paramétrage possible ou visible du déclenchement de la sauvegarde.
Version du plugin : 0.75
Y aurait-il quelque chose à faire ou à vérifier ?
Merci
Répondre à ce message
Je me demande si il n’y a pas un petit soucis avec saveauto 0.7.5
- D’une part, j’ai deux fois le même texte « Détermine à partir de combien de jours une archive est considérée comme obsolète et automatiquement supprimée du serveur. Mettez -1 pour désactiver cette fonctionnalité » pour l’item Fréquence de la sauvegarde : tous les et l’tem Sauvegardes considérées obsolètes après :
- D’autre part, « l’item Sauvegarde déclenchée lors de la connexion d’un auteur » et ses boutons radios n’apparaissent pas chez moi (SPIP 2.1.10 [17657])
J’ai zappé qqchose ?
Même soucis de mon côté sur un SPIP 2.1.20 [20327] avec le script en 0.75.
Je n’ai pas le choix « Sauvegarde déclenchée lors de la connexion d’un auteur » donc pas de sauvegarde de générée.
Avez-vous résolu le soucis ?
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
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.
Suivre les commentaires : |