# LVM ou exports WP-CLI : deux façons de sauvegarder un serveur WordPress

> Sauvegarde infrastructure ou sauvegarde applicative : le bon niveau de granularité évite les mauvaises surprises au moment de restaurer un site en urgence.

- Auteur : Clément Hadrot
- Publié le : 2020-03-09
- Mis à jour le : 2020-03-09
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/lvm-ou-wp-cli-sauvegarder-serveur-wordpress/

## L’essentiel

- Le snapshot LVM sauve tout, y compris les erreurs
- wp-cli exporte proprement, site par site
- Les deux se complètent rarement en remplacement l'un de l'autre

Une agence qui gère une dizaine de sites WordPress sur un même serveur mutualisé finit toujours par se poser la même question : faut-il sauvegarder la machine dans son ensemble, ou site par site ? La réponse dépend moins des outils disponibles que de ce qu'on attend vraiment d'une restauration, et c'est précisément ce point qui est souvent négligé au moment de choisir.

Deux approches dominent sur un serveur Linux hébergeant plusieurs installations WordPress : le snapshot LVM, qui capture l'état du système de fichiers à un instant T, et l'export applicatif via WP-CLI, qui extrait la base de données et les fichiers d'un site précis. Elles ne répondent pas au même besoin, et les confondre conduit à de mauvaises décisions au pire moment.

## Le snapshot LVM : rapide, complet, aveugle

LVM (Logical Volume Manager) permet de créer un instantané d'un volume logique en quelques secondes, sans interrompre les services qui écrivent dessus. Le principe repose sur le copy-on-write : le snapshot ne duplique rien au moment de sa création, il se contente de suivre les blocs modifiés depuis cet instant.

```
lvcreate --size 5G --snapshot --name snap_www /dev/vg_data/lv_www
mount /dev/vg_data/snap_www /mnt/snapshot
rsync -a /mnt/snapshot/ /backup/www-$(date +%F)/
umount /mnt/snapshot
lvremove -f /vg_data/snap_www
```

L'avantage principal est la rapidité et l'exhaustivité : tout ce qui est sur le volume est capturé, y compris les fichiers de configuration serveur, les logs, les certificats TLS, et les sites qui ne sont pas gérés en WordPress. C'est une sauvegarde d'infrastructure, pensée pour reconstruire une machine entière après un sinistre.

## L'export WP-CLI : ciblé, portable, dépendant du contexte applicatif

> L'essentiel à retenir : Le snapshot LVM sauve tout, y compris les erreurs ; wp-cli exporte proprement, site par site ; Les deux se complètent rarement en remplacement l'un de l'autre

À l'opposé, WP-CLI travaille au niveau de l'application. Un export classique combine une extraction de la base et une archive des fichiers propres au site :

```
wp db export backup-db-$(date +%F).sql
tar czf backup-files-$(date +%F).tar.gz wp-content/
```

Cette sauvegarde a un atout que le snapshot LVM n'a pas : elle est portable. Le dump SQL et l'archive de `wp-content` peuvent être restaurés sur n'importe quel serveur, chez n'importe quel hébergeur, tant que les versions de PHP et de MySQL restent compatibles. C'est le format à privilégier pour migrer un site ou le dupliquer en environnement de recette.

## Comparer les deux approches sur les critères qui comptent

| Critère | Snapshot LVM | Export WP-CLI |
| --- | --- | --- |
| Granularité | Serveur entier | Un site précis |
| Portabilité | Faible (même distribution, même partitionnement) | Élevée (tout hébergeur compatible) |
| Temps de restauration | Rapide pour tout reconstruire | Rapide pour un seul site |
| Cohérence applicative | Capture aussi les erreurs en cours (site cassé) | Dépend d'un site fonctionnel au moment de l'export |
| Coût de mise en œuvre | Nécessite LVM configuré dès le partitionnement | Fonctionne sur tout hébergement avec accès SSH |

## Le cas qui départage vraiment les deux méthodes

Le vrai test arrive rarement en cours de service normal, mais lors d'un incident précis : un plugin mal mis à jour corrompt une table, ou une erreur de configuration bloque tous les sites d'un coup. Dans ce scénario, le snapshot LVM pris juste avant la mise à jour permet de revenir en quelques minutes à un état de fonctionnement global, sans avoir à identifier lequel des dix sites a causé le problème.

À l'inverse, si un seul client demande à récupérer une version de son site vieille de trois semaines pendant que les neuf autres continuent de tourner normalement, l'export WP-CLI ciblé est nettement plus adapté : il ne touche qu'à la base et aux fichiers de ce site, sans risque de régresser les autres installations qui partagent le même volume.

- Un snapshot LVM protège contre les pannes systèmes, les erreurs de configuration serveur, ou une mise à jour de distribution ratée.
- Un export WP-CLI protège contre les erreurs applicatives : un plugin qui corrompt du contenu, une mauvaise manipulation dans l'éditeur.
- Aucun des deux ne remplace une copie hors du serveur : un snapshot stocké sur le même disque physique ne survit pas à une panne matérielle.

> Sur nos serveurs de production, la règle est simple : snapshot LVM avant toute opération risquée à l'échelle de la machine, export WP-CLI programmé chaque nuit pour chaque site individuellement. Les deux tournent en parallèle, jamais l'un à la place de l'autre.

## Notre verdict

Opposer LVM et WP-CLI revient à comparer une assurance habitation à une assurance objet précieux : elles ne couvrent pas le même risque. Une agence qui gère plusieurs sites WordPress sur un serveur mutualisé a intérêt à combiner les deux, avec des fréquences différentes selon la criticité. Le snapshot protège la plomberie, l'export WP-CLI protège le contenu. Négliger l'un des deux, c'est accepter de perdre soit du temps, soit des données, le jour où l'incident arrive.