Procédure de sauvegarde/copie et restauration d'une application TYPO3
Description d’une situation type, avec 2 serveurs identiques, 1 pour le site en production (prod-server
) et 1 pour le site en développement/tests (dev-server
). Chaque serveur prend en charge les fichiers et les bases de données (Apache/PHP + MySQL).
L’utilisateur système utilisé est user
.
Les fichiers du site sont dans /var/www/dev-site
sur le serveur de dev-server et dans /var/www/prod-site
sur prod-server
En situation mono-serveur, le principe est strictement identique sauf que les copies de fichiers se font par cp
(attention aux optionsde préservation des permissions) au lieu de scp
et les chemins d’accès ne comprennent plus la partie de connextion ssh au serveur distant.
Les bases de données s’appellent typo3_dev
et typo3_prod
et sont accessibles par l’utilisateur mysql typo3
, avec le mot de passe typo3
.
Il est important que cet utilisateur ait le droit FILE
dans les privilèges de MySQL pour pouvoir faire des imports/exports de/vers des fichiers.
Sauvegarde ponctuelle
La base de données
prod-server: mkdir -p /var/backup/typo3/DUMPDIR/typo3_prod
prod-server: cd /var/backup/typo3/DUMPDIR
prod-server: chmod a+w /var/backup/typo3/DUMPDIR/typo3_prod
prod-server: mysqldump -u typo3 -ptypo3 -Q --tab=typo3_prod typo3_prod
prod-server: tar -czf typo3_prod.tgz typo3_prod
A ce stade, la base typo3_prod
est totalement sauvegardée, dans une archive compressée /var/backup/typo3/DUMPDIR/typo3_prod.tgz
.
Cette archive contient autant de fichiers que de tables dans la base. Un fichier ma_table.sql
contient la structure de la table et un fichier ma_table.txt
contient les données de la table. Cette séparation permet de recréer la structure sans les données et/ou d’injécter les donénes sans toucher à la structure.
Il est conseillé de nommer les archives avec la date du jour, par exemple typo3_prod-20080501.tgz
, cela permet de conserver plusieurs versions de sauvegardes et de savoir à quelle date exactement elles ont été faites, indépendamment de la date de création du fichier.
Les fichiers du site et ceux de TYPO3
prod-server: cd /var/www/
prod-server: tar -xzf /var/backup/typo3/prod-site.tgz prod-site
Les fichiers du site sont alors sauvegardés et compressés sur la partition de sauvegarde.
Si les fichiers du cœur de TYPO3 n’ont pas été changés, il suffit de copier l’archive officielle de TYPO3, qui reste normalement à côté de sa version décompressée. Par exemple :
prod-server: cp typo3_src.4.1.1.tar.gz /var/backup/typo3/typo3_src.4.1.1.tar.gz
Sinon, on recrée l’archive contenant nos fichiers sources et on la copie
prod-server: tar -xzf /var/backup/typo3/typo3_src.4.1.1.mod.tar.gz typo3_src
Sauvegarde régulière
la procédure est identique, mais on peut l’automatiser dans un script shell, déclenché régulièrement par un tâche CRON.
Restauration d’une sauvegarde
Si les données sauvegardées sont stockées sur un autre serveur que celui sur lequel elles doivent être restaurées, il faut d’abord les rapatrier. Imaginons qu’elles soient sur le dev-server
et qu’elles doivent être mises sur prod-server
.
prod-server: mkdir -p /var/backup/typo3/DUMPDIR
dev-server: cd /var/backup/typo3/
dev-server: scp ./DUMPDIR/typo3_prod.tgz user@prod-server:/var/backup/typo3/DUMPDIR/typo3_prod.tgz
dev-server: scp ./typo3_prod.tgz user@prod-server:/var/backup/typo3/typo3_prod.tgz
dev-server: scp ./typo3_src.4.1.1.mod.tar.gz user@prod-server:/var/backup/typo3/typo3_src.4.1.1.mod.tar.gz
La base de données
On restaure la structure de la base. Ici les tables existantes dans la sauvegardes seront détruites avant d’être recrées
prod-server: cat /var/backup/typo3/DUMPDIR/*.sql | mysql -u typo3 -ptypo3 typo3_prod
Puis on restaure les données dans la base.
prod-server: mysqlimport --local -u typo3 -ptypo3 typo3_prod /var/backup/typo3/DUMPDIR/*.txt
Les données sont injectées table après table dans la base de données, avec un arrêt en cas d’erreur sur une table.
La progression est indiquées, avec le nombre de lignes traitées, ainsi que le nombre d’avertissements et d’erreurs.
Lorsqu’on n’a pas procédé à la ré-initiamisation des tables, il est possible de fournir des options à mysqlimport
, telles que :
-r
(ou--replace
) permet de remplacer les lignes qui comportent la même clé (et donc ne provoque pas d’erreur et d’arrêt de l’import). C’est à utiliser lorsqu’on veut mettre à jour la table en conservant ce qui n’existe pas dans l’import.-d
(ou--delete
) permet de vider la table avant la lecture du fichier d’import. C’est à utiliser lorsqu’on veut totalement remplacer le contenu des tables.
Le cœur de TYPO3
La restauration du cœur de TYPO3 n’est nécessaire que si les fichiers sources ont été corrompus.
cd /var/www/
mv typo3_src typo3_src_trashed
tar -xzf /var/backup/typo3/typo3_src.4.1.1.mod.tar.gz
Si tout est OK, on peut supprimer typo3_src_trashed
rm -rf typo3_src_trashed
Restauration des fichiers du site
Le principe est identique, sauf qu’il risque d’être beaucoup plus long selon le nombre de fichiers stockés dans le site.
cd /var/www/
mv prod-site prod-site_trashed
tar -xzf /var/backup/typo3/prod-site.tgz
Si tout est OK, on peut supprimer prod-site_trashed
rm -rf prod-site_trashed
Mise en production d’un site préparé en développement
Compression et transfert
Il faut commencer par exécuter toutes les étapes de la sauvegarde ponctuelle.
Cette fois, la sauvegarde de la base se fait dans le répertoire du site ce qui nous permet de tout compresser et transférer de dev-server à prod-server en une seule fois
dev-server: mkdir -p /var/www/typo3_dev/DUMPDIR/typo3_dev
dev-server: cd /var/www/typo3_dev/DUMPDIR
dev-server: chmod a+w /var/www/typo3_dev/DUMPDIR/typo3_dev
dev-server: mysqldump -u typo3 -ptypo3 -Q --tab=typo3_dev typo3_dev
dev-server: cd /var/www/
dev-server: tar -czf typo3_dev.tgz typo3_dev
dev-server: scp typo3_dev.tgz user@prod-server:/var/www/
Restauration
prod-server: cd /var/www/
prod-server: tar -xzf typo3_dev.tgz
prod-server: cd typo3_dev
Avant toute chose, il faut faire pointer cette copie vers la base de données de prod.
Cette config se situe dans typo3_dev/typo3conf/localconf.php
.
La variable à vérifier est : $typo_db
On peut aussi vérifier les autres variables d’accès à la base : $typo_db_host, $typo_db_password et $typo_db_username
Il faut restaurer la base de données :
prod-server: cat ./DUMPDIR/\*.sql | mysql -u typo3 -ptypo3 typo3_prod
prod-server: mysqlimport --local -u typo3 -ptypo3 typo3_prod /var/www/typo3_dev/DUMPDIR/*.txt
Si les sources de TYPO3 ont été modifiées, il faut aussi les transférer :
dev-server: cd /var/www/
dev-server: tar -xzf typo3_src.4.1.1.mod.tgz typo3_src
dev-server: scp typo3_src.4.1.1.mod.tgz user@prod-server:/var/www/
prod-server: cd /var/www/
prod-server: tar -xzf typo3_src.4.1.1.mod.tgz
Dans tous les cas, il faut vérifier si le lien symbolique qui est dans typo3_dev pointe bien vers le dossier du cœur de TYPO3
Ensuite on renomme :
prod-server: mv typo3_prod typo3_prod_old
prod-server: mv typo3_dev typo3_prod
On vérifie en ligne si le changement est bien fait.
Si tout est OK, on supprime l’ancien dossier.
prod-server: rm -rf typo3_prod_old
Ajustements dans TYPO3
Dans l’interface d’admin de TYPO3, il y a quelques points à vérifier et adapter le cas échéant.
- vider tous les caches (2 liens en bas de la colonne de gauche)
- vérifier les paramètres
baseURL
des configs TYPOScript de chaque site - vérifier les
domaines
de réponse si on a plusieurs sites (enregistrements de type “domaine” sur la première page de chaque site) - dans le cas de la recherche indexée des pages, vérifier les paramètres
baseURL
dans la “configuration TS de la page” (sur la première page de chaque site)
Mise à jour du 6 mai :
Avant de faire un mysqldump, il faut vérifier si le dossier cible est accessible en écriture à l’utilisateur système “mysql” ainsi que l’utilisateur courant. Pour faciliter celà, j’ai ajouté l’écriture à tout le monde. Après tout, ça n’est qu’un répertoire de dump, très éphémère.
Mise à jour du 8 mai :
Il n’est pas nécessaire de donner les droits en lecture sur les dumps à tout le monde. Par contre il est impératif d’avoir le droit FILE dans les privilèges MySQL, aussi bien pour la phase d’export (mysqldump) que pour la phase d’import (mysqlimport).
Mise à jour du 31 août 2011 :
En utilisant la directive --local
(ou -L
), il n’est plus nécessaire que l’utilisateur mysql
ait accès aux fichier TXT en lecture, (cf. la documentation).