Hello,
Comme annoncé sur les listes, il y a eu récemment un beau plantage
d'un des serveurs hébergeant des bouts de spip. Parmi ces bouts, il y
avait le svn, c'est à dire le service contenant tout l'historique du
code de spip.
Grace à des sauvegarde et du temps passé par des gens bien balaises,
le tout a pu être remis en fonctionnement assez rapidement, mais c'est
un avertissement qui doit nous faire réfléchir.
Ceci d'autant plus qu'hier, la machine de remplacement avait l'air de
se sentir un peu mal malgré une config bien large d'épaules.
Actuellement, spip utilise pas mal de services (mailing lists, svn,
trac, sites spip.net, spip-contrib, doc.spip.org, sedna, plein de
blogs et de wikis, ...).
Ça consomme du cpu (mais pas trop) et surtout de l'espace disque
(plusieurs Go), et faire des sauvegardes de tout ça, en bouffe encore
plus.
Aujourd'hui, tous ces services sont hébergés sur des serveurs amis,
en clair, spip est un squatteur 
Ça a l'énorme avantage de ne pas poser de problèmes d'argent, sans
quoi, il faudrait une structure pour gérer un compte en banque, avec
tous les risques de dérive que ça comporte. Il n'est pas question de
reconsidérer ce point pour l'instant, donc pas de débat sur ce sujet
svp.
Il s'agit donc de trouver de l'espace disque (et du cpu
éventuellement, mais pas forcement) pour déposer des sauvegardes ou
des services en backup (web de secours près à démarrer à la place du
principal par exemple), mais surtout de trouver des gens près à passer
du temps sur la question.
Autant le prêt d'espace disque n'est pas une servitude à vie (on
trouvera toujours des bouts de serveurs qui s'ennuient), autant il
faut du "temps homme" pour mettre en place le machin, le maintenir,
et s'en servir en cas de pépin. Il ne s'agit pas d'un sacerdoce, mais
plutôt de l'espoir d'avoir suffisamment de gens sur le coup pour en
trouver rapidement au moins un en cas de panique (on va mettre en
place des astreintes ;-).
Il y a apparemment de l'espace disque qui peut se rendre disponible,
plusieurs volontaires s'étant déclarés, mais il faudrait aussi savoir
QUOI en faire, et QUI peut le faire.
Voici, en vrac, un état de mes réflexions sur l'aspect "quoi". C'est
un peu long, mais l'idée est d'aboutir à quelque chose de suffisamment
précis pour savoir ce qu'on peut faire avec un risque minimal de perte
de données, et sans que ça mette des mois à se mettre en place.
Il faudra ensuite compter les troupes et les disques ... et agir
Tout d'abord, qu'y a t'il à "sécuriser" ? svn, trac, des apache et
des mysql, les listes, c'est tout ?
Ensuite, comment les sécuriser ? Pour moi, il y a 3 approches :
- la sauvegarde : les infos importantes sont stockées. En cas
d'accident, il faut remonter les choses à partir de la dernière
sauvegarde
- la réplication : un mécanisme duplique les données d'un serveur
primaire, vers un (des) serveur(s) secondaire(s). En cas d'accident,
on bascule sur l'autre serveur.
- la répartition de charge : plusieurs serveurs se partagent le boulot,
et sont donc réplicats l'un de l'autre. En cas d'accident d'un des
serveurs, il n'y a aucune interruption de service.
Ça, c'est la théorie, la pratique maintenant :
- la sauvegarde : il faut s'assurer qu'elle n'est pas foireuse et
qu'elle contient tout ce qui est suffisant à reconstruire le service
(données mais aussi config). Il faut se débrouiller pour garder au
moins 2 exemplaires et ne surtout pas écraser la sauvagarde de la
veille avec celle du jour. Il peut même être nécessaire de garder
plus d'historique (si on ne remarque pas tout de suite une destruction
accidentelle de données, il ne faut pas que la sauvegarde qui les
contient ait disparu).
Elle consomme beaucoup d'espace, et pose des problèmes de synchro
(entre le début et la fin de la sauvegarde, on a des fichiers qui
peuvent changer et donc être incohérents entre eux. Au boulot, j'ai
découvert récemment que la sauvegarde d'un serveur interne durait 6
heures chaque jour).
Des systèmes de sauvegardes incrémantales permettent d'alléger pas
mal le temps et le volume de sauvegarde, mais ça complique d'autant
la restauration.
En termes d'indispo, la réinstallation peut prendre très longtemps.
- la réplication : elle oblige à avoir un serveur complet "pour rien",
mais en même temps, ça permet de tester son état et d'être sur qu'en
cas de pépin, il peut prendre le relai très vite (l'idéal étant
d'échanger les rôles régulièrement, pour valider que tout va bien).
Elle protège très efficacement du plantage du principal (si c'est
pas fait n'importe comment), mais pas du problème applicatif ou de
l'acte de sabotage : si un truc commence à tout effacer, la répli
va conciencieusement faire pareil de l'autre coté.
L'idéal là dessus, c'est la répli à la mysql, associée à une
sauvegarde : le primaire génère un journal de tout ce qu'il fait, et
le secondaire le rejoue dans l'ordre. Une sauvegarde permet alors de
revenir à l'état d'une date donnée, et le journal de rejouer jusqu'à
l'accident, ou jusqu'à "juste avant l'acte de sabotage". C'est "tout
fait" dans mysql, mais pour les fichiers, c'est une autre histoire.
De plus, ça nécessite un lien permanent entre les serveurs.
- la répartition de charge : elle nécessite une répli croisée entre les
serveurs, et c'est un vrai casse tête. Ça existe pour mysql, pour des
fichiers, c'est à mon avis super galère. Une variante consiste à
faire les écritures sur un serveur unique, et la lecture partout
(intéressant pour répartir la charge réseau et cpu), mais dans le cas
qui nous interesse ça me parait difficile à mettre en place.
Bref, à mon avis, c'est pas pour nous.
Maintenant, reprenons la liste des trucs à sécuriser :
- mysql (je commence par le plus facile 
:
- version light : mysqldump nocturne + copie dans un coin. Le reload
est assez facile. J'ai sous le coude un script permettant de dumper
toutes les bases d'un serveur (en csv, et pas en ordres mysql qui
prennent des plombes à remonter en bdd) et générant le bout de
fichier mysql pour remonter le tout (testé et approuvé).
- version luxe : si on convertit les bdd en innodb, on peut se
contenter d'un gros dump par semaine (par exemple) et d'une récup du
log du jour chaque nuit. Soit on rejoue le tout sur un (ou plus)
serveur, soit on les garde pour ne les rejouer qu'en cas de pépin.
- trac : y'a une bdd en dessous ? sinon, c'est comme pour les fichiers
- svn :
- version light : gros tar des fichiers .db
- version luxe : install de svn 1.4 + svnsync. Si ce svnsync permet en
plus de stocker à part le journal des choses à répliquer, on peut
partir sur une solution tar+journal pour rejouer un morceau afin
d'annuler une opération destructrice. À moins que svn permette en
standard de retourner en arrière de façon définitive ? (c'est à
dire revenir avant un gros remove, sans créer une branche ou je ne
sais quoi).
- les fichiers : c'est le gros morceau, surtout si on inclu les quelques
Go de mails. Fil, quand tu parlais de 1Go de spip.net+forum, c'est
surtout de la bdd je suppose ?
- version light : tar+copie ... si les autres services sont répliqués
on peut détarrer la dernière sauvegarde pour avoir un backup près à
l'emploi
- version luxe : "find -mtime ..." ou code à base de FAM ou rsync pour
balancer les fichiers au fil de l'eau, via un script permettant de
mettre les fichiers modifiés au chaud. Là, y'à peut être des trucs
tout faits, sinon, faut se palucher un script + tests intensifs.
- la config de tout ces machins : il suffit de tout mettre dans un coin,
à condition de rien oublier, et c'est souvent le plus dur
Un dernier point, qui est loin d'être le moins important, est d'avoir
une doc expliquant tout ce qui est en place, et les procédures de
bascule, histoire de pas être trop pris au dépourvu le jour ou y'en
a besoin. On dit toujours que la doc c'est chiant, pour ce genre de
trucs, c'est vital. Des restaurations qui font plus de dégats que
l'accident initial, ça arrive et c'est pas drôle du tout.
Bref, désolé d'avoir fait tout un roman, mais j'aime bien mettre les
choses à plat avant de rentrer dedans
Reste à voir ce qu'on fait de tout ça, le plus simple étant de
commencer par la version light, et de mettre la solution luxe en
place petit à petit, là où c'est faisable sans nécessiter des super
pro de la question.
Je peux m'occuper de l'aspect scripts pour les fichiers et les dump
mysql.