Comment sauvegarder manuellement WordPress sans plugin (2026)

Il existe plusieurs façons de sauvegarder un site WordPress : un plugin de sauvegarde, le service intégré de votre hébergeur, une plateforme gérée, ou encore la sauvegarde manuelle. Ce guide traite de cette dernière option : sauvegarder WordPress sans plugin, à la main, en utilisant SFTP pour les fichiers et phpMyAdmin pour la base de données.

Les sauvegardes manuelles vous offrent un contrôle total et ne dépendent d'aucun plugin. Elles constituent une solution idéale lorsque vous souhaitez disposer d'un filet de sécurité avant une mise à jour, d'un instantané ponctuel avant une migration ou d'une archive vérifiable dont la création ne dépend pas d'un plugin.

En revanche, ils présentent des lacunes en matière de planification récurrente sur plusieurs sites, et ils ne sont certainement pas plus rapides qu'un simple clic. Prévoyez entre 15 et 60 minutes la première fois que vous effectuez cette opération, selon la taille de votre site et votre niveau de maîtrise du protocole SFTP.

Vous trouverez ci-dessous les raisons pour lesquelles on pourrait préférer une sauvegarde manuelle à un plugin, la procédure complète pour les fichiers et la base de données, les étapes de restauration, ainsi qu'une liste de contrôle pour vérifier que votre sauvegarde fonctionne bien.

Que sont les sauvegardes de WordPress ?

Une sauvegarde WordPress est simplement une copie complète de tout ce dont votre site web a besoin pour fonctionner. Elle comprend tous les fichiers principaux de WordPress, vos plugins, vos thèmes et la base de données dans laquelle se trouve votre contenu.

Il s'agit d'un instantané de votre site à un moment précis. Si des pirates informatiques attaquent votre site ou si votre serveur tombe en panne, vous disposez de cette sauvegarde pour tout restaurer au lieu de tout reconstruire à partir de zéro. Votre sauvegarde vous permet de revenir en ligne rapidement et de satisfaire vos clients.

Sauvegarde complète d'un site web vs. sauvegarde partielle d'un site web

Il existe deux grands types de sauvegardes WordPress. Une sauvegarde complète inclut tout (noyau, thèmes, plugins, fichiers téléchargés, base de données) ; elle vous permet ainsi de restaurer l'intégralité du site à partir d'une seule archive, mais nécessite davantage d'espace de stockage et prend plus de temps à transférer. Une sauvegarde partielle ne sauvegarde que les fichiers ou uniquement la base de données ; elle est plus rapide et moins volumineuse, mais la restauration prend plus de temps car vous devez assembler des éléments provenant de différents ensembles.

Pour les sauvegardes manuelles, il vaut presque toujours mieux opter pour une sauvegarde complète : le coût de stockage est négligeable par rapport au temps perdu lors de la restauration à essayer de deviner, sous la pression, ce qui manque.

Pourquoi des sauvegardes régulières sont-elles importantes ?

Des sauvegardes régulières de WordPress constituent le seul filet de sécurité fiable contre la perte de données, les failles de sécurité, les échecs de mise à jour et les pannes de serveur. Sans une copie récente et restaurable de vos fichiers et de votre base de données, n'importe lequel de ces incidents peut mettre votre site hors ligne pour une durée indéterminée.

Il est recommandé de sauvegarder le thème de votre site web, ses fichiers (tels que les plugins) et sa base de données (y compris les articles, les utilisateurs, les commentaires, etc.).

Les sauvegardes, c'est un peu comme enregistrer des documents importants sur Google Drive, Dropbox ou le bureau de votre ordinateur.

En général, il est toujours judicieux de sauvegarder vos fichiers importants à plusieurs endroits et sur différents supports, comme un disque dur externe, une clé USB ou votre ordinateur. Il en va de même pour votre site web. Voici pourquoi vous devriez sauvegarder votre site web :

Prévenir la perte de données : le fait de disposer de sauvegardes vous protège lorsque quelqu'un supprime accidentellement votre page d'accueil ou écrase un contenu essentiel. C'est particulièrement important lorsque plusieurs membres de l'équipe ont accès à votre site.

Failles de sécurité : lorsque des pirates informatiques s'introduisent sur votre site, ils laissent souvent derrière eux du code malveillant ou suppriment du contenu. Une sauvegarde intacte datant d'avant l'attaque vous permet d'effacer toute trace du piratage sans perdre votre site.

Selon le rapport « State of WordPress Security in 2025 » publié par Patchstack, 33 % des failles de sécurité WordPress révélées en 2024 n’avaient pas été corrigées avant leur divulgation publique. Lorsqu’un tiers des failles divulguées sont exploitées sans qu’aucun correctif n’ait été fourni par le fournisseur, chaque administrateur dispose d’au moins un site exécutant un code connu pour être exploitable, sans qu’aucune solution ne soit disponible. La seule protection réaliste consiste à disposer d’une sauvegarde récente et réutilisable.

Mises à jour et modifications : les mises à jour des extensions et des thèmes peuvent parfois provoquer des plantages de votre site ou altérer sa mise en page. Grâce à une sauvegarde, vous pouvez rapidement revenir à la version qui fonctionnait correctement pendant que vous identifiez la cause du problème. Cela se traduit par une réduction des temps d'indisponibilité et des appels de panique de la part des clients.

Pannes de serveur : si votre serveur d'hébergement tombe en panne ou si votre hébergeur rencontre des problèmes, votre site risque de disparaître complètement. Disposer de votre propre sauvegarde vous évite de dépendre du système de sauvegarde de votre hébergeur (qui peut lui aussi tomber en panne). Vous pouvez rapidement migrer vers un nouveau serveur et restaurer votre site, souvent en quelques heures seulement, plutôt qu'en plusieurs jours.

Pourquoi ne pas utiliser un plugin de sauvegarde ?

Les plugins de sauvegarde constituent la solution la plus simple pour la plupart des utilisateurs de WordPress, et ce n'est pas sans raison : il suffit de les installer, de les configurer, de programmer les sauvegardes, et le tour est joué.

Alors, pourquoi renoncer au plugin pour effectuer une sauvegarde manuelle à la place ? Voici cinq raisons fondées sur l'expérience des opérateurs.

1. La compatibilité des plugins tombe en panne au pire moment. Les plugins de sauvegarde cessent souvent de fonctionner après une mise à jour du cœur de WordPress, de PHP ou d'un plugin sans rapport. C'est précisément au moment où votre sauvegarde est la plus précieuse, juste après une mise à jour risquée, que le plugin est le plus susceptible de ne plus fonctionner.
2. Délais d'attente du serveur sur les sites volumineux. L'hébergement mutualisé impose généralement des limites d'exécution PHP comprises entre 30 et 60 secondes. Les plugins de sauvegarde qui exécutent mysqldump ou créent des fichiers ZIP wp-content atteignent régulièrement ces limites, ce qui donne lieu à des archives partielles qui semblent correctes mais qui ne sont pas récupérables. Les sauvegardes manuelles via SFTP et SSH ne sont pas soumises à cette contrainte.
3. Interdiction des plugins de sauvegarde tiers par certains hébergeurs. Les hébergeurs WordPress gérés tels que WP Engine, Kinsta et Pagely limitent ou désactivent purement et simplement les plugins de sauvegarde tiers, car ceux-ci sollicitent excessivement les ressources d'E/S du serveur. Si votre hébergeur interdit les sauvegardes via plugin, la seule solution consiste à effectuer ces opérations manuellement ou via WP-CLI.
4. Des sauvegardes « réussies » qui ne le sont pas vraiment. Un plugin qui signale que la sauvegarde a réussi alors qu’il n’a produit qu’un dump partiel de la base de données est pire que l’absence totale de sauvegarde, car il donne un faux sentiment de sécurité. Les exportations manuelles vous permettent de vérifier directement la taille des fichiers et le nombre de lignes avant de vous fier à l’archive.
5. Dans certains cas ponctuels, un plugin est superflu. Un instantané avant la migration, un simple filet de sécurité avant une mise à jour majeure, la mise en pause d'un site avant de le remettre au client. Il est plus rapide de procéder manuellement que d'installer et de configurer un plugin que vous désinstallerez une heure plus tard.

Quand est-ce qu'il ne faut pas opter pour le mode manuel ?

Les sauvegardes régulières pour les portefeuilles multi-sites, les boutiques WooCommerce avec des données de transactions horaires, ou tout simplement pour ceux qui risquent d'oublier de s'en occuper. Si c'est votre cas, un plugin de sauvegarde ou une plateforme gérée est la meilleure solution. Consultez notre guide complet sur les sauvegardes WordPress pour avoir un aperçu de toutes les options disponibles.

Et si vous avez besoin de sauvegardes régulières sur plusieurs sites avec une restauration vérifiable, c'est exactement ce qu'offrent des plateformes comme WP Umbrella sont là pour ça.

Comment sauvegarder votre site Web sans plugin ?

La manière la plus simple d'effectuer une sauvegarde sur un site WordPress consiste à utiliser une plateforme gérée ou un plugin de sauvegarde. Cependant, pour les cas particuliers et les situations ponctuelles évoqués plus haut, une approche manuelle vous offre un contrôle qu'aucun plugin ne peut vous garantir. Il est essentiel de sauvegarder régulièrement votre site web. Vous pouvez effectuer cette procédure manuellement si vous ne souhaitez pas installer de plugin dédié ou si vous n'en trouvez pas qui réponde à vos besoins.

C'est ainsi que vous pouvez sauvegarder l'ensemble de votre site WordPress sans plugin.

Étape 1 : Sauvegardez vos fichiers WordPress (via SFTP)

Votre site WordPress comprend de nombreux fichiers : les fichiers d'installation du cœur de WordPress, les plugins, les thèmes, les fichiers multimédias téléchargés, le code personnalisé, et wp-config.php (le fichier de configuration principal contenant vos identifiants de base de données et vos clés de sécurité).

Au quotidien, on ne touche généralement qu'aux extensions, aux thèmes et aux fichiers téléchargés. Sauvegardez tout de même l'intégralité du site : une sauvegarde partielle vous oblige à déterminer ce qui manque lorsque vous devez restaurer le site, et c'est justement à ce moment-là que vous ne voulez pas avoir à deviner.

Voici les étapes à suivre pour sauvegarder les fichiers de votre site WordPress :

1. Téléchargez et installez le client FileZilla (gratuit et open source, disponible pour macOS, Windows et Linux).
2. Dans le Gestionnaire de sites de FileZilla, créez un nouveau site. Sélectionnez « SFTP – SSH File Transfer Protocol » comme protocole, indiquez le port 22, puis saisissez vos identifiants d'hébergement.
3. Connectez-vous à votre serveur. Le panneau distant affiche l'arborescence de votre site.
4. Accédez au répertoire racine de WordPress (généralement public_html/, www/, ou htdocs/ (selon l'hébergeur). Il s'agit du dossier contenant wp-config.php, wp-content/et wp-includes/.
5. Cliquez avec le bouton droit de la souris sur le dossier racine et sélectionnez « Télécharger ». FileZilla copie tous vos fichiers sur votre ordinateur. Pour les sites disposant de bibliothèques multimédias volumineuses, cette opération peut prendre entre 30 minutes et plusieurs heures.
6. Une fois le transfert terminé, vérifiez dans le journal de transfert de FileZilla s'il y a des fichiers qui n'ont pas été transférés. Une sauvegarde comportant des fichiers ignorés n'est pas une sauvegarde complète. Retransférez tous les fichiers qui n'ont pas été transférés.

Vous trouverez généralement vos identifiants SFTP dans le panneau de configuration de votre hébergement, sous « Comptes SFTP » ou « Accès SSH ». Si vous ne les trouvez pas, l'équipe d'assistance de votre hébergeur pourra vous confirmer l'hôte, le port, le nom d'utilisateur et la méthode d'authentification.

Une fois le téléchargement vérifié, vous disposez de votre sauvegarde de fichiers. La moitié du travail est faite ; passons maintenant à la base de données.

Étape 2 : Sauvegarder votre base de données WordPress

Il ne suffit pas de simplement sauvegarder les fichiers de votre site. WordPress stocke tous vos articles, vos pages, vos commentaires, vos utilisateurs, vos paramètres, les configurations de vos plugins et la plupart des éléments qui font de votre site ce qu’il est dans une base de données MySQL. Si vous ne sauvegardiez que vos fichiers, vous vous retrouveriez avec un site web vide : sans articles, sans pages et sans éléments dans la médiathèque.

Voici comment procéder correctement avec phpMyAdmin, l'outil d'administration MySQL accessible via le Web et intégré à la plupart des panneaux de contrôle d'hébergement.

Étape préliminaire : trouver la bonne base de données. Dans le cadre d'un hébergement mutualisé, votre compte d'hébergement comporte souvent plusieurs bases de données. Sélectionner la mauvaise base de données est l'erreur la plus courante lors d'une sauvegarde manuelle. Ouvrir wp-config.php (que vous avez déjà obtenu à l'étape 1) dans n'importe quel éditeur de texte et recherchez les lignes suivantes :

define( 'DB_NAME', 'your_database_name_here' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' )
define( 'DB_HOST', 'localhost' );
$table_prefix = 'wp_';

Notez que DB_NAME valeur : il s'agit de la base de données que vous devez exporter. Remarque DB_USER, DB_PASSWORDet DB_HOST aussi ; vous en aurez besoin pour la restauration. Le $table_prefix Cette ligne vous indique quelles tables de cette base de données appartiennent à cette installation WordPress (ce qui est pertinent si plusieurs sites WordPress partagent une même base de données).

Exporter avec phpMyAdmin (mode « Personnalisé », et non « Rapide »). Connectez-vous à votre panneau de contrôle d'hébergement et ouvrez phpMyAdmin. Ensuite :

1. Dans la barre latérale gauche, cliquez sur le nom de la base de données correspondant à DB_NAME de wp-config.php. Assurez-vous que c'est bien le bon.
2. Cliquez sur l'onglet « Exporter » en haut de la page.
3. Dans la section « Méthode d'exportation », sélectionnez « Personnalisée » pour afficher toutes les options disponibles. L'option par défaut « Rapide » omet un paramètre essentiel et génère un fichier d'exportation qui ne peut pas être restauré par-dessus une base de données existante.
4. Dans la section « Tables », vérifiez que toutes les tables correspondant à votre $table_prefix sont sélectionnés.
5. Dans la section « Sortie », conservez l'option « Enregistrer la sortie dans un fichier » et activez la compression (les formats zip ou gzip sont recommandés pour les bases de données volumineuses).
6. Dans « Format », sélectionnez SQL.
7. Dans la section « Options de création d'objets », cochez la case « Ajouter l'instruction DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER ». C'est le paramètre essentiel que la plupart des tutoriels omettent de mentionner.
8. Conservez les paramètres par défaut des « Options de création des données » (instructions INSERT, format hexadécimal pour les BLOB).
9. Cliquez sur « Go ». Le fichier se télécharge sur votre ordinateur.

Pourquoi la commande DROP TABLE est importante. Lorsque vous restaurerez ultérieurement cette exportation sur une base de données contenant déjà des tables, l'importation supprimera d'abord les tables existantes avant de les recréer. Sans DROP TABLE, la restauration échoue en raison d'erreurs du type « la table existe déjà », ou pire encore, fusionne partiellement les anciennes et les nouvelles données.

Erreurs courantes commises par les opérateurs :

• En utilisant l'exportation « rapide » et en partant du principe qu'elle peut être restaurée dans une base de données contenant déjà des tables.
• Choix d'une base de données inadaptée lorsque l'hébergement mutualisé héberge plusieurs installations WordPress sur un seul serveur MySQL. Vérifiez toujours DB_NAME.
• En oubliant que cela n'exporte que la base de données. Les fichiers (thèmes, plugins, fichiers téléchargés, wp-config.php) sont toujours nécessaires pour effectuer une sauvegarde complète.
• Décalage de jeu de caractères ou de collation. Si la base de données source est utf8mb4 et la cible est utf8, les caractères spéciaux sont corrompus lors de la restauration. Vérifiez que les jeux de caractères correspondent dans l'onglet « Opérations » de phpMyAdmin avant l'importation.

Si votre base de données dépasse 500 Mo, phpMyAdmin aura du mal à la gérer. La documentation officielle de phpMyAdmin recommande plutôt d'utiliser directement les commandes MySQL ou MariaDB. Reportez-vous à la section WP-CLI ci-dessous. Pour plus d'informations, le Guide d'administration avancée de WordPress.org consacré aux sauvegardes de bases de données présente ces options en détail.

Étape 3 : Restaurer à partir de votre sauvegarde

Une sauvegarde que l'on ne peut pas restaurer n'est pas vraiment une sauvegarde. Voici comment récupérer vos fichiers et votre base de données, ainsi que les pièges dans lesquels tombent la plupart des administrateurs lors de leur première restauration.

Restaurez les fichiers via SFTP. Connectez-vous au serveur cible à l'aide de FileZilla (utilisez les mêmes paramètres SFTP qu'à l'étape 1). Accédez au répertoire racine de WordPress. Glissez-déposez votre dossier de sauvegarde local dans le répertoire racine distant. Confirmez les éventuelles écrasements. Sur un serveur vierge, cette opération peut prendre un certain temps ; le journal de transfert de FileZilla vous indique quand chaque fichier est en place.

Restaurez la base de données via phpMyAdmin. Dans phpMyAdmin de votre hébergement cible, sélectionnez la base de données de destination dans la barre latérale gauche. Cliquez sur le Importer onglet. Choisissez votre .sql (ou .sql.gz) fichier. Sous « Format », sélectionnez SQL. Cliquez sur Aller. La restauration s'exécute, supprimant toutes les tables existantes et les recréant à partir de votre exportation. C'est pourquoi la DROP TABLE Le paramètre défini à l'étape 2 avait son importance.

Mettez à jour le fichier wp-config.php sur le nouveau serveur. Si vous effectuez une restauration sur un autre serveur, modifiez wp-config.php et mettre à jour DB_NAME, DB_USER, DB_PASSWORDet DB_HOST pour s'adapter à la nouvelle base de données. Sur un hébergement mutualisé, DB_HOST est rarement simplement localhost. Vérifiez la valeur exacte dans le panneau d'hébergement.

Les cinq pièges qui font trébucher tout le monde :

1. Remplacement de l'URL ou du domaine lors de la restauration vers un environnement de test ou un nouveau domaine. WordPress stocke l'URL de votre site dans la base de données, souvent sous forme de tableaux PHP sérialisés qui peuvent être corrompus si vous les modifiez naïvement via une requête SQL. La méthode la plus sûre consiste à utiliser WP-CLI :

wp search-replace 'old.com' 'new.com' --all-tables --precise --dry-run

1. Vérifiez le résultat du test, puis relancez l'opération sans --dry-run. Le --precise L'indicateur gère correctement les données sérialisées.
2. Incompatibilité entre les jeux de caractères et les collations (utf8 et utf8mb4). Si vos bases de données source et cible utilisent des jeux de caractères différents, les caractères spéciaux risquent d'être corrompus lors de la restauration. Veuillez soit faire correspondre les jeux de caractères dans l'onglet « Opérations » de phpMyAdmin avant l'importation, soit ouvrir votre .sql fichier et rechercher/remplacer utf8mb4 avec utf8 (ou inversement) pour qu'ils correspondent.
3. Les droits d'accès aux fichiers sont incorrects après le téléchargement via SFTP. Les répertoires doivent avoir les droits 755, les fichiers 644, et wp-config.php 600 ou 640. Via SSH :find /path/to/wp -type d -exec chmod 755 {} \; find /path/to/wp -type f -exec chmod 644 {} \; chmod 600 /path/to/wp/wp-config.php
4. Les liens permanents ne fonctionnent pas ou .htaccess manquant. Une fois la restauration effectuée, connectez-vous à wp-admin, puis rendez-vous dans Paramètres → Liens permanents, puis cliquez sur Enregistrer les modifications sans rien modifier. WordPress régénère .htaccess.
5. Le cache et l'opcache diffusent du contenu obsolète. Videz le cache de votre site (via le panneau de configuration du cache de l'hébergeur, WP Rocket ou W3 Total Cache, en sélectionnant « Tout vider »). Videz le cache de votre navigateur. Si vous utilisez Cloudflare ou un autre CDN, videz-le également. Via WP-CLI : wp cache flush.

Si le site se charge, que l'interface d'administration fonctionne et que la page d'accueil n'affiche pas d'erreur de base de données, vous avez presque terminé. Testez maintenant correctement la sauvegarde.

Procédez avec prudence. Assurez-vous que votre version de WordPress, votre version de PHP et la sauvegarde que vous restaurez sont bien compatibles. Une fois la restauration effectuée, testez minutieusement votre site pour vérifier que tout fonctionne correctement.

À quelle fréquence devez-vous effectuer des sauvegardes manuelles ?

La fréquence dépend du rythme des modifications. Les boutiques WooCommerce ou tout site traitant des transactions ont besoin de sauvegardes toutes les heures ou en temps réel ; les sites dont le contenu est fréquemment mis à jour devraient effectuer des sauvegardes quotidiennes ou hebdomadaires ; les sites de présentation et les pages archivées peuvent se contenter de sauvegardes mensuelles.

Combien de temps dure réellement une sauvegarde manuelle ? Pour un petit blog (moins d'1 Go), il faut compter entre 15 et 30 minutes au total. Pour un site riche en contenu doté d'une vaste bibliothèque multimédia ou une boutique WooCommerce proposant des milliers de produits, il faut compter une heure, voire plus. C'est le téléchargement via SFTP qui constitue le goulot d'étranglement, et non phpMyAdmin.

Meilleures pratiques pour la sauvegarde d'un site web WordPress

Mettre en place des sauvegardes régulières

Effectuez vos sauvegardes selon un calendrier adapté à la fréquence de mise à jour de votre site. Si vous publiez du nouveau contenu tous les jours, sauvegardez quotidiennement. Si vous effectuez rarement des mises à jour, une sauvegarde hebdomadaire suffit. Les sauvegardes manuelles ne sont utiles que si elles sont réellement effectuées ; programmez-les donc dans votre agenda ou optez pour une solution automatisée.

Stocker les sauvegardes en toute sécurité

Conservez vos sauvegardes sur un serveur différent de celui qui héberge le site en ligne, en utilisant des identifiants distincts de ceux de votre hébergement. L'objectif est d'éviter un point de défaillance unique : une compromission de votre compte d'hébergement ne devrait pas entraîner la perte de vos sauvegardes.

Cryptage des fichiers de sauvegarde

Les fichiers de sauvegarde contiennent une copie complète de votre site, y compris toutes les données sensibles relatives à vos clients présentes dans votre base de données. Cryptez-les pendant leur stockage et leur transfert. Pour les archives locales, utilisez VeraCrypt ou gpg (intégré à la plupart des distributions Linux et à macOS) gèrent bien cela. Pour le stockage dans le cloud, optez pour un fournisseur qui prend en charge le chiffrement côté serveur par défaut.

Appliquez la règle du 3-2-1

La règle du 3-2-1 est la méthode de sauvegarde la plus simple qui résiste aux véritables défaillances : trois copies de votre site, sur deux supports de stockage différents, dont une hors site. C'est cette exigence de « hors site » qui pose le plus de problèmes aux opérateurs. Une sauvegarde qui reste sur /home/user/backups sur le même serveur que celui qui héberge votre site en ligne ne constitue pas une solution hors site, car un seul incident d'hébergement (suspension de compte, ransomware, incendie du centre de données) les affecterait tous les deux.

Une configuration 3-2-1 réaliste pour un administrateur WordPress :

• 3 copies : le site de production + une sauvegarde quotidienne sur le serveur d'hébergement + une archive hebdomadaire sur votre ordinateur portable
• 2 supports : système de fichiers serveur + stockage d'objets dans le cloud (Backblaze B2, Wasabi ou AWS S3)
• 1 hors site : une archive à faible accès mensuelle stockée dans un autre compte cloud ou sur un disque dur externe situé dans un autre lieu physique

C'est cette dernière copie qui subsiste lorsque votre compte d'hébergement disparaît.

Testez régulièrement vos sauvegardes

L'étape 4 porte sur le processus de vérification. La mesure la plus importante : un exercice de restauration trimestriel programmé. Les sauvegardes non testées échouent en silence, et on ne s'en rend compte que le jour où une restauration réelle s'avère indispensable.

Connaître le processus de restauration

Passez en revue les étapes de restauration décrites à l'étape 3 avant d'en avoir réellement besoin. Deux pièges liés à la compatibilité piègent la plupart des administrateurs : la divergence de version de WordPress (restaurer une sauvegarde de la version 6.4 sur une version 6.6 ne pose pas de problème ; l'inverse peut entraîner des dysfonctionnements) et la divergence de version de PHP (une sauvegarde réalisée sous PHP 7.4 peut échouer sous PHP 8.2 si un plugin utilise des fonctions supprimées). Vérifiez que les deux versions correspondent à celles du serveur de destination avant de procéder à l'importation.

Méthode WP-CLI / SSH (pour les développeurs)

Si vous disposez d'un accès SSH à votre serveur (la plupart des offres d'hébergement de qualité l'incluent), WP-CLI (l'interface de ligne de commande officielle de WordPress) est nettement plus rapide et plus fiable que phpMyAdmin pour la gestion de la base de données. Les extraits de code ci-dessous partent du principe que vous êtes connecté via SSH et que vous vous trouvez dans le répertoire racine de WordPress. Vérifiez que WP-CLI est installé à l'aide de la commande wp --info; sinon, vous trouverez les instructions d'installation dans la documentation de votre hébergeur.

Exportation de la base de données avec DROP TABLE (correspond au flux personnalisé de phpMyAdmin décrit ci-dessus) :

wp db export --add-drop-table db-backup-$(date +%Y-%m-%d).sql

Exportation de la base de données compressée :

wp db export - | gzip > db-backup-$(date +%Y-%m-%d).sql.gz

Sauvegarde de fichiers avec des exclusions judicieuses :

tar --create --gzip \
  --exclude='wp-content/cache' \
  --exclude='wp-content/uploads/cache' \
  --exclude='wp-content/debug.log' \
  --exclude='*.log' \
  --file=files-backup-$(date +%Y-%m-%d).tar.gz \
  /var/www/html

Script de sauvegarde combiné (enregistrer sous /usr/local/bin/wp-backup.sh, puis chmod 700) :

#!/bin/bash
SITE_PATH="/var/www/html"
BACKUP_DIR="/var/backups/wp"
DATE=$(date +%Y-%m-%d-%H%M)
cd "$SITE_PATH" || exit 1
wp db export "$BACKUP_DIR/db-$DATE.sql" --add-drop-table
tar --create --gzip \
  --exclude='wp-content/cache' \
  --exclude='*.log' \
  --file="$BACKUP_DIR/files-$DATE.tar.gz" \
  "$SITE_PATH"

Tâche cron quotidienne à 3 h du matin (crontab -e) :

0 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Une astuce utile à connaître concernant le crontab : le % Le caractère a une signification particulière dans les fichiers crontab. En intégrant la logique de date dans un script (comme ci-dessus), on contourne le problème. Si vous écrivez $(date +%Y-%m-%d) directement dans une ligne de crontab, échappez-le comme suit : \%Y-\%m-\%d.

Pour les sites plus volumineux (plus de 2 Go), utilisez le swap tar+gzip pour pigz (gzip parallèle) ou utiliser rsync pour les transferts par tranches. La référence complète pour wp db export se trouve sur le Guide du développeur WordPress.org.