Sauvegarder et restaurer le site WordPress sur un serveur Linux sans plugin

Dans un précédent tutoriel, je vous ai montré comment installer WordPress sur un serveur Linux. Dans cet article, je vais vous montrer comment sauvegarder votre site WordPress et le restaurer sans plugin. Je suppose que vous avez accès à votre VPS Linux (serveur privé virtuel) ou serveur dédié via SSH et que vous connaissez quelques commandes Linux de base. Si vous disposez d'un plan d'hébergement partagé, je suis désolé que cet article ne soit pas pour vous.

Sauvegarder WordPress sans plugin

Vous savez donc probablement qu’il ne faut pas installer trop de plugins sur votre site WordPress car cela ralentirait votre site. Bonne nouvelle à ceux d’entre vous qui hébergent WordPress sur un serveur privé virtuel ou un serveur dédié. Vous pouvez utiliser les commandes Linux et MySQL pour automatiser votre processus de sauvegarde WordPress afin de pouvoir supprimer votre plugin de sauvegarde WordPress. Mieux encore, cette méthode de sauvegarde est gratuite !

Pour sauvegarder un site WordPress, nous devons sauvegarder la base de données et tous les fichiers de votre répertoire webroot. Je vais d’abord vous expliquer comment sauvegarder la base de données.

Sauvegarde de la base de données WordPress

La commande suivante s'applique à la fois à la base de données MySQL et à la base de données MariaDB. Pour ceux d’entre vous qui ne le savent pas, MariaDB est un remplacement immédiat de MySQL. Cela signifie que 99 % des commandes de MariaDB sont les mêmes que celles de MySQL. Et je vous recommande fortement de migrer vers MariaDB si vous utilisez MySQL comme serveur de base de données.

Vous pouvez vérifier si vous utilisez MariaDB ou MySQL en exécutant la commande suivante à l'invite du shell :

mysql --version

Exemple de sortie :

mysql Ver 15.1 Distrib 10.3.22-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Comme vous pouvez le voir, j'utilise MariaDB. Une autre méthode pour détecter si vous disposez de MySQL ou MariaDB consiste à vous connecter à votre serveur de base de données à l'aide du client MySQL.

sudo mysql -u root

Après vous être connecté, vous verrez un message de bienvenue :

Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 102
Server version: 10.3.22-MariaDB-0ubuntu0.19.10.1-log Ubuntu 19.10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Vous pouvez voir que j'utilise MariaDB Server version 10.3.22. Si vous utilisez une base de données MySQL, la version du serveur ressemblera à ceci :

8.0.7-MySQL Community Server (GPL)

Maintenant que vous savez quel serveur de base de données vous utilisez, effectuons la sauvegarde.

Après vous être connecté au serveur de base de données à l'aide de la commande sudo mysql -u root -p, exécutez la commande suivante pour afficher toutes les bases de données que vous avez sur votre serveur. Ne laissez pas de côté le point-virgule.

show databases;

Exemples de résultats :

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| wordpress          |
+--------------------+

Normalement, vous disposez de quatre bases de données. Chaque serveur MySQL/MariaDB comprend des bases de données infomation_schema, mysql et performance_schema. La dernière est la base de données de votre site WordPress, qui est la seule base de données que vous devez sauvegarder. Entrez la commande exit pour quitter votre serveur de base de données.

exit;

Nous utilisons maintenant l'utilitaire mysqldump pour sauvegarder la base de données wordpress.

sudo mysqldump -u root wordpress > wordpress.sql

La commande ci-dessus sauvegardera la base de données wordpress dans un fichier nommé wordpress.sql sous le répertoire de travail actuel. Vous pouvez modifier le nom du fichier de sauvegarde à votre guise, par exemple monsite.sql. Si vous rencontrez l'erreur suivante :

mysqldump: Error: Binlogging on server not active

Ensuite, vous devez activer la journalisation binaire en modifiant votre fichier de configuration /etc/mysql/my.cnf ou /etc/my.cnf en fonction de votre distribution Linux.

sudo nano /etc/mysql/my.cnf

sudo nano /etc/my.cnf

Mettez le texte suivant dans la section [mysqld].

log-bin=mysql-bin

Comme ça:

[mysqld]
 user = mysql
 pid-file = /var/run/mysqld/mysqld.pid
 socket = /var/run/mysqld/mysqld.sock
 port = 3306
 basedir = /usr
 datadir = /var/lib/mysql
 tmpdir = /tmp
 lc-messages-dir = /usr/share/mysql
 skip-external-locking
 log-bin=mysql-bin
 #

Enregistrez et fermez le fichier. Redémarrez ensuite votre serveur de base de données

sudo systemctl restart mysql

sudo systemctl restart mariadb

Utilisez maintenant la commande mysqldump ci-dessus pour sauvegarder toute votre base de données WordPress dans un fichier .sql.

Vous pouvez également compresser le fichier de sauvegarde afin qu'il ne prenne pas trop de place.

sudo mysqldump -u root wordpress | gzip > wordpress.sql.gz

Sauvegarde de fichiers WordPress sous Webroot

Vos fichiers de programme WordPress, fichiers de thème, fichiers de plugins et images téléchargées se trouvent tous dans le répertoire racine Web. Votre répertoire racine Web peut être /var/www/html/ ou /usr/share/nginx/html/ ou quelque chose comme ça en fonction des configurations de votre serveur Web.

Pour sauvegarder ces fichiers WordPress, nous utiliserons un utilitaire de ligne de commande appelé tar, abréviation de tap archive. Entrez la commande suivante à l'invite de votre shell.

sudo tar -cpvzf filename.tar.gz /var/www/html/

La commande ci-dessus comporte 5 options, où :

-c signifie créer un fichier d'archive.
-p signifie préserver les autorisations des fichiers archivés.
-v : affiche des informations détaillées.
-z signifie compresser le fichier d'archive à l'aide de gzip.
-f signifie fichier.

filename.tar.gz est le nom du fichier d'archive et /var/www/html/ signifie que tous les fichiers et répertoires du répertoire webroot seront archivés et compressés. Votre répertoire racine Web peut être différent, alors vérifiez la configuration de votre serveur Web.

Restauration de la base de données et des fichiers WordPress sur le même serveur

Vous savez maintenant comment sauvegarder votre base de données et vos fichiers WordPress, mais cela ne sert à rien si vous ne savez pas comment les restaurer.

Restauration de la base de données WordPress

Disons que votre site WordPress a été piraté via une vulnérabilité dans un plugin. Si vous disposez d'une sauvegarde de la base de données, vous pouvez facilement restaurer l'état d'origine. Entrez la commande suivante pour importer la base de données précédemment sauvegardée sur le serveur de base de données MySQL/MariaDB.

sudo mysql -u root wordpress < wordpress.sql

Après cela, vous pouvez vous connecter à votre serveur de base de données et voir si toutes vos bases de données sont importées.

Restauration de fichiers WordPress

Tout d’abord, extrayez l’archive tar

tar -xzvf filename.tar.gz

Copiez ensuite les fichiers WordPress dans le répertoire webroot. Je suppose que votre répertoire racine Web est /var/www/html/.

sudo cp var/www/html/* /var/www/html/ -R

Envoyez des fichiers de sauvegarde par e-mail dans votre boîte de réception

Si vous souhaitez envoyer par courrier électronique votre fichier de sauvegarde de base de données et votre fichier de sauvegarde WordPress dans votre boîte de réception, suivez les étapes ci-dessous.

Tout d’abord, installez heirloom mailx. Heirloom mailx est un fantastique agent utilisateur de messagerie (client de messagerie). Il prend en charge les pièces jointes et peut envoyer des e-mails à l'aide de serveurs SMTP externes tels que Gmail. Nous allons envoyer notre fichier de sauvegarde de base de données et nos fichiers de sauvegarde WordPress sous forme de pièces jointes en utilisant Gmail comme serveur SMTP.

Installation de Heirloom Mailx

Sur le serveur CentOS/RHEL, exécutez la commande suivante :

sudo yum install -y mailx

Sur le serveur Fedora :

sudo dnf install -y mailx

Sur le serveur Debian/Ubuntu :

sudo apt-get install -y heirloom-mailx

C'est ça!

Définir Gmail comme serveur SMTP externe pour relayer les e-mails

Modifiez le fichier mailrc. Sur le serveur CentOS/RHEL/Fedora :

sudo vi /etc/mail.rc

sur le serveur Debian/Ubuntu

vi ~/.mail.rc

Mettez le texte suivant dans le fichier.

set smtp-use-starttls
set ssl-verify=ignore
set smtp=smtp://smtp.gmail.com:587
set smtp-auth=login
set smtp-auth-user=user-account@gmail.com
set smtp-auth-password=user-password
set from="user-account@gmail.com(Your_Name)"

Remplacez les textes verts par les informations d'identification de votre compte Gmail. Enregistrez et fermez le fichier. Nous pouvons désormais envoyer des e-mails à l'aide de la commande mail comme ceci :

echo "website backed up" | mail -v -a backup.sql -a filename.tar.gz -s "wordpress backed up" [email

Le texte qui suit echo est le contenu du courrier qui sera redirigé vers la commande mail.

-v signifie verbeux, il affichera l'état de votre connexion avec Gmail.
-a signifie pièce jointe. vous pouvez utiliser plusieurs options -a pour ajouter plusieurs pièces jointes à votre e-mail.
-s signifie sujet.
Le dernier argument est l'adresse e-mail du destinataire, par exemple [email . À propos, vous pouvez vous envoyer des e-mails. Cela signifie que l'adresse De et l'adresse À peuvent être les mêmes. Vous pouvez également ajouter plusieurs adresses e-mail de destinataires.

Le serveur CentOS/RHEL/Fedora doit ajouter une ligne supplémentaire au fichier mail.rc. Tout d’abord, téléchargez ces trois fichiers sur votre serveur, placez-les dans le répertoire .certs de votre domicile. Si vous utilisez Firefox sur un ordinateur de bureau Linux, vous pouvez également trouver ces fichiers dans le répertoire ~/.mozilla/firefox/.default.

Ajoutez ensuite la ligne suivante au fichier /etc/mail.rc.

set nss-config-dir=/home/<username>/.certs/

Enregistrez et fermez le fichier. Vous pouvez désormais envoyer des e-mails en utilisant Gmail comme relais.

Contourner la limitation de la taille des fichiers joints de Gmail

Gmail limite la taille totale des pièces jointes de l'expéditeur à 25 Mo, bien qu'un compte Gmail puisse recevoir une pièce jointe de 34 Mo. Votre base de données ne grossira peut-être pas très bientôt, cependant, les fichiers WordPress ont tendance à grossir très rapidement. Si votre fichier d'archive fait plus de 25 Mo, vous souhaiterez peut-être diviser votre fichier d'archive en plusieurs parties et les envoyer par courrier électronique une par une.

Fractionner le fichier

Pour cela, nous allons utiliser la commande split. Sa syntaxe est la suivante :

split -b 5M -d filename.tar.gz <prefix>

La commande ci-dessus signifie diviser filename.tar.gz en une taille de fichier de 5 mégaoctets. Vous pouvez remplacer 5M par quelque chose de inférieur à 25M. est le nom qui sera ajouté au préfixe des fichiers fractionnés.

Par exemple, si j'exécute la commande suivante :

split -b 5M -d linux-terminal.tar.gz wordpress

Je vais récupérer les fichiers suivants.

-rw-rw-r-- 1 user user 15M Nov 21 01:57 linux-terminal.tar.gz
-rw-rw-r-- 1 user user 5.0M Nov 21 13:46 wordpress00
-rw-rw-r-- 1 user user 5.0M Nov 21 13:46 wordpress01
-rw-rw-r-- 1 user user 4.5M Nov 21 13:46 wordpress02

Le fichier linux-terminal.tar.gz est divisé en trois fichiers. Disons que votre fichier d’archive fait 40 mégaoctets. Vous pouvez utiliser la commande suivante :

split -b 25M -d filename.tar.gz wordpress

pour obtenir un fichier de 25M et un autre fichier de 15M. Vous pouvez maintenant envoyer ces deux fichiers sur votre compte Gmail. Mais vous devez utiliser la commande mail deux fois pour envoyer chacun des fichiers, vous ne pouvez pas les envoyer tous les deux en pièce jointe à la fois.

Comment les réunir

Lorsque vous restaurez votre site Web, vous devez joindre ces fichiers divisés. Nous pouvons utiliser la commande cat pour y parvenir.

cat wordpress00 wordpress01 > wordpress.tar.gz

Automatisation du processus

Oui! Vous pouvez automatiser les processus ci-dessus. Qui n'aime pas l'automatisation ? Nous allons installer cron et l'utiliser pour planifier une tâche de sauvegarde. Installez-le avec les commandes suivantes :

Pour le serveur Debian/Ubuntu :

sudo apt-get install cron

Pour CentOS/RHEL :

sudo yum install crontabs

Pour le serveur Fedora :

sudo dnf install crontabs

Si vous utilisez systemd, vous devez le démarrer après l'installation.

sudo systemd start crond

Activer le démarrage au démarrage du système :

sudo systemd enable crond

Planification d'une tâche de sauvegarde

Entrez la commande suivante dans le terminal :

crontab -e

Cela ouvrira la table cron dans laquelle nous ajouterons des tâches. Par exemple, si nous voulons sauvegarder la base de données à 4 heures du matin tous les jours, insérez-y le texte suivant.

0 4 * * * mysqldump -u root -pyourpassword --all-databases --master-data | gzip > backup.sql.gz

0 4 * * * signifie tous les jours à 16h00. Remplacez le texte vert par le mot de passe root de votre base de données.

Ensuite, nous sauvegarderons les fichiers WordPress dans webroot. Ajoutez le texte suivant dans la ligne suivante.

5 4 * * * tar -cpzf filename.tar.gz /var/www/html/

Si votre racine Web n'est pas /var/www/html/ mais quelque chose d'autre comme /usr/share/nginx/html, modifiez-la. Nous sauvegardons donc le fichier WordPress à 16h05 tous les jours. Ensuite, nous devons les envoyer en pièces jointes à notre adresse e-mail.

10 4 * * *  echo "website backed up" | mail -a backup.sql.gz -a filename.tar.gz -s "wordpress backed up" [email

La commande ci-dessus enverra notre sauvegarde de base de données et notre sauvegarde de fichiers à 16h10 tous les jours. Je sépare les trois tâches à intervalle de 5 minutes. Si vous souhaitez qu'ils se produisent juste après le précédent, vous pouvez procéder comme suit.

0 4 * * * mysqldump -u root -pyourpassword --all-databases --master-data | gzip > backup.sql.gz && tar -cpzf filename.tar.gz /var/www/html/ && echo "website backed up" | mail -a backup.sql.gz -a filename.tar.gz -s "wordpress backed up" [email

La double esperluette (&&) signifie exécuter la commande suivante lorsque la commande précédente s'est terminée avec succès. Vous n’avez donc pas besoin d’attendre 5 minutes. Mais ce format rendra votre fichier crontab un peu compliqué.

Si vous souhaitez supprimer la sauvegarde de la base de données et la sauvegarde des fichiers après leur envoi par courrier électronique pour économiser de l'espace sur votre serveur, vous pouvez ajouter

15 4 * * * rm backup.sql.gz filename.tar.gz

ou ajoutez simplement la commande rm en utilisant &&.

Si vous souhaitez que votre tâche cron s'exécute toutes les heures, vous pouvez effectuer :

0 * * * *

ou une fois toutes les deux heures

0 */2 * * *

Déplacez votre site WordPress vers un nouveau serveur

Si le processus de restauration est sur votre serveur d'origine, alors vous avez terminé. Votre site WordPress fonctionne désormais correctement comme avant. Mais si vous transférez votre site de votre serveur d'origine vers un autre serveur, suivez les instructions ci-dessous.

Tout d’abord, vous devez installer la pile LAMP ou la pile LEMP sur le nouveau serveur.
Ensuite, vous devez copier votre fichier d'hôte virtuel Apache ou Nginx et votre fichier de certificat SSL sur le nouveau serveur. Assurez-vous de tester le fichier hôte virtuel et de recharger votre serveur Web.
Ensuite, copiez les fichiers WordPress sur le nouveau serveur sous le répertoire webroot.
Après cela, vous devez créer une base de données vide dans MySQL/MariaDB sur le nouveau serveur, décrit ci-dessous.

Ouvrez le fichier de configuration WordPress par défaut sous le répertoire webroot.

sudo nano /var/www/html/wp-config.php

Cela ouvrira votre fichier wp-config.php et dans ce fichier, vous pourrez trouver l'utilisateur de base de données que vous avez créé lors de la première installation de WordPress et le mot de passe de l'utilisateur comme suit. :

/** The name of the database for WordPress */
 define('DB_NAME', 'database-name');
/** MySQL database username */
 define('DB_USER', 'database-username');
/** MySQL database password */
 define('DB_PASSWORD', 'user-password');

Connectez-vous maintenant au serveur de base de données à l'aide de la commande suivante :

sudo mysql -u root

Créez la base de données.

create database database-name;

Accordez tous les privilèges de la base de données WordPress à l'utilisateur :

grant all privileges on database-name.* to database-username@localhost identified by 'user-password';

Vider les privilèges de la base de données.

flush privileges;

Quittez le serveur de base de données.

exit;

Copiez maintenant le fichier SQL sauvegardé sur le nouveau serveur et restaurez la base de données.

sudo mysql -u root wordpress < wordpress.sql

Vous avez transféré avec succès votre site WordPress vers le nouveau serveur. Modifiez votre enregistrement DNS et vous devriez voir votre site WordPress fonctionner correctement !

Points à surveiller avant de supprimer un VPS

Je fais normalement les choses suivantes avant de supprimer un VPS dont je n’ai plus besoin. Ils m'aident à éviter la suppression de logiciels ou de données importants sans migration.

Répertoriez les certificats TLS Let's Encrypt sur le VPS avec les certificats sudo certbot.
Répertoriez les services en cours d'exécution sur le VPS avec sudo netstat -lnptu.
Vérifiez l'utilisation du disque avec sudo ncdu /. Oui, vous devez installer l'utilitaire ncdu : sudo apt install ncdu.
Vérifiez s'il y a des tâches Cron sur le VPS avec sudo crontab -l.
Vérifiez le répertoire personnel pour voir si j'y ai des fichiers.

Emballer

Bravo! Vous venez de sauvegarder votre site WordPress à l’aide de commandes Linux et la meilleure partie est que vous pouvez automatiser le processus de sauvegarde et que vous n’avez pas besoin d’acheter un plugin de sauvegarde WordPress. De plus, votre site WordPress se chargera plus rapidement car vous venez de supprimer un plugin de votre site.