vous trouverez en version finale le script de sauvegarde automatisée.
Salut Matthieu, j'ai regardé ton script, et les deux idées sont intéressantes :
- sauvegarde au format MySQL plutôt que xml-spip
- sauvegarde automatique quotidienne
Le script n'est pas intégrable en l'état (l'histoire du cookie, par exemple,
me paraît bizarre), mais on pourrait en prendre quelques morceaux, si tu
précises sous quelle licence tu le distribues.
Salut Matthieu, j'ai regardé ton script, et les deux idées sont intéressantes :
- sauvegarde au format MySQL plutôt que xml-spip
- sauvegarde automatique quotidienne
Le script n'est pas intégrable en l'état (l'histoire du cookie, par exemple,
me paraît bizarre),
bizarre ? quoi donc ? c pour pas scanner le répertoire des sauvegarde à chaque fois. en effet je liste les sauvegardes (oendir et tout le tralala), je regarde la plus récente et calcule si l'intervalle de sauvegarde est dépassé.
mais on pourrait en prendre quelques morceaux, si tu
précises sous quelle licence tu le distribues.
ca c le truc auquel je dois réfléchir. à priori GPL mais j'annoncerais "officiellement" tout ca rapidement.
Le script n'est pas intégrable en l'état (l'histoire du cookie, par exemple,
me paraît bizarre), mais on pourrait en prendre quelques morceaux, si tu
précises sous quelle licence tu le distribues.
vu ce que m'apporte SPIP, ca me parait normal que je rende l'appareil.
voilà j'ai ajouté la licene GPL au script. je m'y connais trop dans ce domaine, j'ai suivi les conseils du fichier licence_fr.html fourni avec SPIP.
Salut Matthieu, j'ai regardé ton script, et les deux idées sont intéressantes :
- sauvegarde au format MySQL plutôt que xml-spip
Justement, la sauvegarde format MySQL, c'est déjà ce que
fait phpMyAdmin. Ce n'est pas lisible et ça n'apporte pas
grand'chose (à part que c'est un peu plus rapide à la
restauration). Ce n'est pas non plus facilement réutilisable,
hors injection directe dans MySQL. A mon avis ce serait
une régression.
- sauvegarde automatique quotidienne
Ca ne fait pas trop ramer le site, ça ?
Et puis, la sauvegarde a beau être quotidienne, si on la
laisse sur le même disque dur que la base MySQL...
Justement, la sauvegarde format MySQL, c'est déjà ce que
fait phpMyAdmin. Ce n'est pas lisible et ça n'apporte pas
grand'chose (à part que c'est un peu plus rapide à la
restauration). Ce n'est pas non plus facilement réutilisable,
hors injection directe dans MySQL. A mon avis ce serait
une régression.
Une option, pas une régression
(La plupart de mes sauvegardes spip sont faites automagiquement avec
mysqldump, c'est pas si horrible que ça, et c'est standard, ce qui peut
avoir quelques avantages.)
> - sauvegarde automatique quotidienne
Ca ne fait pas trop ramer le site, ça ?
A propos de faire ramer le site, je me disais qu'on devrait mettre les trucs
qui rament (statistiques, etc) ailleurs qu'en pied de page html. Par
exemple, la partie BOUTONS_ADMIN pourrait envoyer, à l'heure dite et même
aux non admins, un jajascript qui charge silencieusement un URL dont on se
contrefiche qu'il dure longtemps.
Et puis, la sauvegarde a beau être quotidienne, si on la
laisse sur le même disque dur que la base MySQL...
Walk proposait de l'envoyer par mail ; on peut aussi imaginer un mail
qui envoit au webmestre un URL où y'a qu'à cliquer pour récupérer la
sauvegarde...
Enfin, je dis ça, mais personnellement je n'en aurais pas l'usage.
(La plupart de mes sauvegardes spip sont faites automagiquement avec
mysqldump, c'est pas si horrible que ça, et c'est standard, ce qui peut
avoir quelques avantages.)
Justement, si tu utilises mysqldump, tu n'as pas besoin de SPIP
pour faire tes sauvegardes (en PHP, ce qui est cent fois plus
pénible).
A propos de faire ramer le site, je me disais qu'on devrait mettre les trucs
qui rament (statistiques, etc)
Faut surtout voir ce qui rame et améliorer les choses. Je ne
vois rien de très gênant.
Quand même, un truc chiant : quand on désactive puis réactive le
moteur de recherche, ça réindexe tout le site...
Par
exemple, la partie BOUTONS_ADMIN pourrait envoyer, à l'heure dite et même
aux non admins, un jajascript qui charge silencieusement un URL dont on se
contrefiche qu'il dure longtemps.
Tout le monde n'utilise pas #FORMULAIRE_ADMIN. Et puis, pourquoi
la durée d'exécution du Jaja n'aurait-elle pas d'importance ?
A priori le navigateur a besoin que le chargement soit terminé
pour afficher correctement la page (il n'est pas censé savoir
qu'il charge un truc bidon).
Walk proposait de l'envoyer par mail ; on peut aussi imaginer un mail
qui envoit au webmestre un URL où y'a qu'à cliquer pour récupérer la
sauvegarde...
Le dump ne doit pas être accessible via HTTP (pour l'instant il est
dans ecrire/data, qui est protégé par un .htaccess).
J'étais en train de me dire qu'on pourrait utiliser l'extension
XML pour rendre la restauration plus rapide, mais en fait le
dump.xml n'est pas valide à cause des colonnes "0minirezo" & co
dans spip_groupes_mots...
Walk proposait de l'envoyer par mail ; on peut aussi imaginer un mail
qui envoit au webmestre un URL où y'a qu'à cliquer pour récupérer la
sauvegarde...
Enfin, je dis ça, mais personnellement je n'en aurais pas l'usage.
-- Fil
Moi je trouve l'URL par mail très intéressant pour les non-pros. L'idée du mail
contenant le dump est bien aussi pour les petits sites (yen a des tonnes,
webgene fait 400ko en gz, c'est encore supportable par mail toutes les semaines
et c'est très pratique quand on a 10 sites).
Ceci dit, le lien par mail est très astucieux Fil :o)
Faut pas oublier la fonction aide-mémoire de l'alerte email, tout le monde ne
tient pas une check-liste de pro ou n'a pas un cerveau d'ordi.
si on la laisse sur le même disque dur que la base MySQL...
J'ai vu plusieurs fois des bases plantées sur levillage, et le dump pas touché,
ça peut donc être utile quand même.
QUESTION TRANSFERT:
Comment se fait-il qu'on puisse transférer automatiquement les fichiers SPIP de rezo.net chez un hébergeur avec le spip_loader, et qu'on ne puisse pas
transférer automatiquement un dump de free sur lycos ? (pour séparer les disques
durs base-site et sauvegarde)
