Dans ce chapitre, nous allons voir comment configurer des sauvegardes automatiques pour vos sites.
Il est essentiel d’effectuer des sauvegardes de façon régulière. Il est inévitable qu’à un moment donné, vous ayez besoin de restaurer des données, que ce soit en raison d’une erreur de l’utilisateur, d’une corruption ou d’une faille de sécurité. On ne sait jamais ce qui peut mal tourner, alors avoir une sauvegarde récente à portée de main peut vraiment vous faciliter la vie en tant qu’administrateur de systèmes.
Il existe généralement deux types de sauvegardes que nous vous recommandons d’effectuer. Le premier est une sauvegarde complète du système et le second est une sauvegarde de chaque site individuel hébergé sur le serveur.
Les sauvegardes complètes du système sont mieux effectuées par CommVault.
Une sauvegarde complète du système est généralement réservée aux situations où vous devez récupérer un serveur entier. Par exemple, dans le cas d’une panne rare et catastrophique où toutes les données de votre serveur ont été perdues. Vous ne voudrez pas restaurer l’ensemble du système si un seul site doit être restauré.
La sauvegarde d’un site unique enregistre la base de données et tous les fichiers du site, ce qui vous permet de restaurer uniquement ce site. Pour un site WordPress, vous pourriez penser que tout ce dont vous avez besoin de sauvegarder est la base de données et le répertoire des téléchargements. Après tout, les fichiers de base, les thèmes et les plugins de WordPress peuvent être retéléchargés si nécessaire. Vous envisagez peut-être même de ne pas effectuer de sauvegardes pour votre répertoire de téléchargement si vous utilisez un plugin comme WP Offload Media, car les fichiers sont automatiquement envoyés vers votre fournisseur de stockage configuré lorsqu’ils sont ajoutés à la médiathèque. Cette approche des sauvegardes peut entraîner des problèmes à long terme.
Il y a deux raisons pour lesquelles nous recommandons d’inclure toutes les données et tous les fichiers dans une seule sauvegarde du site.
Premièrement, certains plugins WordPress peuvent avoir une fonctionnalité qui stocke les fichiers dans le répertoire de téléchargement, souvent dans un emplacement distinct de la structure de répertoire de la médiathèque WordPress. Un exemple courant est celui des plugins de formulaires qui permettent aux utilisateurs de télécharger des fichiers depuis le front-end. Votre solution de déchargement des médias ne déplacera pas ces fichiers vers le fournisseur de stockage hors site. Si vous excluez le répertoire de téléchargement de votre sauvegarde, vous ne serez pas en mesure de les restaurer.
Deuxièmement, si vous ne sauvegardez que votre base de données et le répertoire des téléchargements, vous devrez télécharger manuellement les fichiers de base de WordPress et tous les thèmes ou plugins. Ce n’est pas idéal si vous hébergez des sites à fort trafic, comme des sites de commerce électronique, d’adhésion ou communautaires. Vous devez pouvoir vous remettre rapidement d’une panne, ou vous perdrez votre activité.
Une sauvegarde hebdomadaire devrait suffire pour les sites qui ne sont pas mis à jour souvent, mais vous pouvez vouloir les effectuer plus fréquemment. Par exemple, pour un site de commerce électronique, vous pouvez effectuer des sauvegardes toutes les quelques heures, en fonction de la fréquence des nouvelles commandes.
Pour configurer les sauvegardes d’un site, commencez par créer un nouveau répertoire de sauvegardes dans le répertoire racine du site. C’est là que seront stockés tous vos fichiers de sauvegarde.
cd /home/ashley/ashleyrich.com
mkdir backups
Si vous avez suivi le reste de ce guide, le répertoire des sauvegardes se trouve à côté des répertoires existants (cache, logs et public).
Ensuite, nous allons créer un nouveau script shell appelé backup.sh.
#!/bin/bash
NOW=$(date +%Y%m%d%H%M%S)
SQL_BACKUP=${NOW}_database.sql
FILES_BACKUP=${NOW}_files.tar.gz
DB_NAME=$(sed -n "s/define( *'DB_NAME', *'\([^']*\)'.*/\1/p" wp-config.php)
DB_USER=$(sed -n "s/define( *'DB_USER', *'\([^']*\)'.*/\1/p" wp-config.php)
DB_PASSWORD=$(sed -n "s/define( *'DB_PASSWORD', *'\([^']*\)'.*/\1/p" wp-config.php)
DB_HOST=$(sed -n "s/define( *'DB_HOST', *'\([^']*\)'.*/\1/p" wp-config.php)
# Backup database
mysqldump --add-drop-table -u$DB_USER -p$DB_PASSWORD -h$DB_HOST $DB_NAME > ../backups/$SQL_BACKUP 2>&1
# Compress the database dump file
gzip ../backups/$SQL_BACKUP
# Backup the entire public directory
tar -zcf ../backups/$FILES_BACKUP .
Ce que fait ce script :
NOW), une variable de nom de fichier SQL (SQL_BACKUP) qui inclut la date actuelle dans le nom du fichier, et une variable de nom de fichier d’archive (FILES_BACKUP), qui inclut également la date actuelle.SQL_FILE dans le répertoire des sauvegardes. Il s’assure également que le fichier SQL inclut la commande MySQL drop table. Ceci est utile lorsque vous utilisez ce fichier pour restaurer une base de données sur une autre qui a des tables existantes avec le même nom.gzip pour compresser le fichier SQL afin qu’il prenne moins de place. Le nom de fichier compressé résultant ressemble à ceci : 20211028191120_database.sql.gz.Vous remarquerez également qu’à chaque fois que nous faisons référence à l’emplacement du répertoire de sauvegarde, nous utilisons …/. Cette syntaxe du système de fichiers Linux signifie en fait « aller un répertoire au-dessus du répertoire actuel », ce que nous faisons parce que nous exécutons le script depuis le répertoire public. Nous devrons également en tenir compte lorsque nous mettrons en place la tâche cron planifiée plus tard.
Appuyez sur <CTRL> + X suivi de Y pour enregistrer le fichier.
L’étape suivante consiste à s’assurer que le script nouvellement créé dispose des droits d’exécution afin qu’il puisse être exécuté par une tâche cron du serveur.
Au fil du temps, ce processus de sauvegarde va créer un tas d’archives SQL et de fichiers dans le répertoire des sauvegardes, ce qui peut être une raison courante de manquer d’espace disque sur le serveur. En fonction des données présentes sur votre site et de la fréquence de leur mise à jour, vous n’aurez probablement pas besoin de conserver des sauvegardes de plus d’un mois. Ce serait donc une bonne idée de nettoyer les anciennes sauvegardes du site dont vous n’avez pas besoin.
Pour supprimer les anciennes sauvegardes, ajoutez une ligne au bas du script backups.sh.
# Remove backup files that are a month old
rm -f ../backups/$(date +%Y%m%d* --date='1 month ago').gz
Cette ligne utilise une commande date pour obtenir la date d’il y a un mois et crée une chaîne de noms de fichiers avec le caractère générique *. Cela correspondra à tout nom de fichier commençant par la date d’il y a un mois et se terminant par .gz, et supprimera ces fichiers. Par exemple, si le script est exécuté le 24 juillet, il supprimera tous les fichiers de sauvegarde créés le 24 juin. Tant que votre script s’exécute tous les jours, il supprimera toujours les sauvegardes d’il y a un mois.
Un problème avec les sauvegardes du site que nous venons de mettre en place est que les fichiers de sauvegarde résident toujours sur votre serveur local. Si le serveur tombe en panne, il emportera les sauvegardes avec lui. Par conséquent, c’est une bonne idée de stocker vos sauvegardes de sites individuels ailleurs que sur votre serveur. Une bonne option pour cela est de les déplacer vers un bucket S3.
Maintenant que les bases du script de sauvegarde sont en place, passons en revue le script et voyons si nous pouvons l’améliorer. Ce serait génial si le script était plus générique et pouvait être utilisé pour n’importe quel site.
Voici la version mise à jour du script de sauvegarde, avec ces ajouts en place.
#!/bin/bash
# Get the bucket name from an argument passed to the script
BUCKET_NAME=${1-''}
if [ ! -d ../backups/ ]
then
echo "This script requires a 'backups' folder 1 level up from your site files folder."
exit
fi
NOW=$(date +%Y%m%d%H%M%S)
SQL_BACKUP=${NOW}_database.sql
FILES_BACKUP=${NOW}_files.tar.gz
DB_NAME=$(sed -n "s/define( *'DB_NAME', *'\([^']*\)'.*/\1/p" wp-config.php)
DB_USER=$(sed -n "s/define( *'DB_USER', *'\([^']*\)'.*/\1/p" wp-config.php)
DB_PASSWORD=$(sed -n "s/define( *'DB_PASSWORD', *'\([^']*\)'.*/\1/p" wp-config.php)
DB_HOST=$(sed -n "s/define( *'DB_HOST', *'\([^']*\)'.*/\1/p" wp-config.php)
# Backup database
mysqldump --add-drop-table -u$DB_USERNAME -p$DB_PASSWORD -h$DB_HOST $DB_NAME > ../backups/$SQL_BACKUP 2>&1
# Compress the database dump file
gzip ../backups/$SQL_BACKUP
# Backup the entire public directory
tar -zcf ../backups/$FILES_BACKUP .
# Remove backup files that are a month old
rm -f ../backups/$(date +%Y%m%d* --date='1 month ago').gz
# Copy files to S3 if bucket given
if [ ! -z "$BUCKET_NAME" ]
then
aws s3 cp ../backups/$SQL_BACKUP.gz s3://$BUCKET_NAME/ --quiet --storage-class STANDARD
aws s3 cp ../backups/$FILES_BACKUP s3://$BUCKET_NAME/ --quiet --storage-class STANDARD
fi
Voilà donc une configuration assez simple pour sauvegarder un site WordPress et le stocker à distance. Vous pouvez également envisager d’utiliser notre plugin WP Offload Media pour copier les fichiers vers S3 au fur et à mesure qu’ils sont téléchargés dans la médiathèque. Vous économisez de l’espace disque en stockant ces fichiers dans S3 au lieu de votre serveur. Vous pouvez également activer le versioning sur le bucket afin que tous vos fichiers soient restaurables en cas de suppression accidentelle.