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).