Sauvegarde Immuable pour MariaDB : Stratégies Combinées Locales et S3 pour une Sécurité Maximale en 2024
Dans l’ère numérique de 2024, la sauvegarde des données est devenue plus qu’une simple pratique de routine, c’est une nécessité absolue pour la sécurité et la pérennité de toute entreprise. Je vous propose donc aujourd’hui un guide complet sur la Sauvegarde Immuable pour MariaDB.
Votre guide complet pour établir un système de sauvegarde robuste et fiable. (sauvegarde de plusieurs bases de données, logs pour les erreurs, gestion de la rétention locale et cloud, planification avec CRON…)
Dans cet article, nous explorons les méthodes infaillibles pour sécuriser vos bases de données MariaDB ou compatible, en combinant des stratégies de sauvegarde locales avec la puissance et la flexibilité du stockage cloud S3.
Découvrez comment mettre en place des sauvegardes immuables qui protègent vos données contre toute altération ou perte, assurant ainsi une récupération sans faille en cas de sinistre.
Étape 1: Préparons le Terrain
Avant de plonger dans le vif du sujet, prenons un moment pour mettre en place notre espace de travail.
Je vous conseille d’utiliser un compte dédié à la sauvegarde, aussi bien pour MariaDB que pour l’exécution du script.
Pour cet exemple j’utilise Debian 12, MariaDB 11 et Wasabi pour le stockage S3
Il vous faudra également Python3 et PIP pour installer le plugin awscli-plugin-endpoint (si vous utilisez Wasabi)
sudo apt install python3 python3-pip python3.11-venv -y
Configurez et activez l’environnement virtuel python
python3 -m venv db_backup_venv
source db_backup_venv/bin/activate
Créez le bucket et un répertoire dédié au stockage des sauvegardes dans celui-ci, puis appliquez un politique de cycle de vie pour la gestion de la rétention des sauvegardes cloud
Attention il faut restez cohérent avec le réglage de immuabilité, choisissez un rétention plus élevée, dans mon exemple je défini plus tard dans le script 30 jours d’immuabilité donc je défini 31 jours de rétention dans le cycle de vie.
Voici un exemple pour Wasabi :
Ensuite pour il nous faut aussi configurer le verrouillage au niveau du bucket
C’est comme préparer sa cuisine avant de se lancer dans la réalisation d’une recette : un peu d’organisation préalable facilite grandement les choses !
Étape 2: Création d’un Fichier de Configuration Sécurisé
Pour protéger vos informations d’identification, créez un fichier de configuration db_config.cnf
pour la connexion aux bases de données :
[client]
user=votre_utilisateur
password=votre_mot_de_passe
Remplacez votre_utilisateur
et votre_mot_de_passe
par vos informations de connexion et stockez ce fichier dans un endroit sûr. Mettez également en place les permissions d’accès adaptées, par exemple si le fichier est dans le dossier home :
chown monutilisateur:mongroupe /home/monutilisateur/db_config.cnf
chmod 600 /home/monutilisateur/db_config.cnf
Étape 3: Configuration d’AWS CLI pour notre Sauvegarde Immuable pour MariaDB
J’utilise Wasabi qui est compatible avec l’API S3, vous trouvez plus d’infos ici : https://docs.wasabi.com/docs/how-do-i-use-aws-cli-with-wasabi
On doit donc installer AWS CLI et configurer la connexion à notre bucket Wasabi pour l’utiliser dans le script:
# Téléchargement
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
# Installation
sudo ./aws/install
# Vérification de la version
aws --version
# Configuration
aws configure --profile wasabi
Vous devrez fournir :
AWS Access Key ID
: Votre clé d’accès Wasabi.AWS Secret Access Key
: Votre clé secrète Wasabi.Default region name
: Pour paris par exemple : eu-west-2. liste complète des régions ICIDefault output format
: Laissez vide ou utilisez « json ».
On continue la configuration pour utiliser un endpoint personnalisé
# Installation de awscli-plugin-endpoint
pip install awscli-plugin-endpoint
aws configure set plugins.endpoint awscli_plugin_endpoint
aws configure set plugins.cli_legacy_plugin_path <site-packages-path> (à remplacer par le chemin vers le plugin)
Vous pouvez trouver le chemin de votre site-package avec la commande (vous devez être dans l’environnement virtuel créé précédemment)
python3 -m site
par exemple : /home/<username>/db_backup_venv/lib/python3.11/site-packages/
Et on finalise la configuration en définissant l’url personnalisé qui correspond à la région dans la quelle nous avons créé notre bucket
aws configure --profile wasabi set s3.endpoint_url https://s3.eu-west-2.wasabisys.com
Une fois terminé, vous pouvez tester le bon fonctionnement en listant les éléments du bucket (il sera surement vide mais si il n’y a pas d’erreur retournée, c’est OK)
aws s3 ls --profile wasabi
Pensez à désactiver l’environnement virtuel python :
deactivate
Étape 4: Mise en place du script de Sauvegarde Immuable pour MariaDB
Enfin ! on peut mettre en place notre script de sauvegarde, on détaille ça plus bas !
#!/bin/bash
PATH=/usr/bin:/usr/local/bin
# Variables de configuration
BACKUP_PATH="/mnt/backups/mariadb" # Chemin pour stocker les sauvegardes locales
DATABASES="<bdd1> <bdd2> <bdd3>" # Espaces entre les noms de bases de données
RETENTION_DAYS=14 # Nombre de jours de rétention locale
CONFIG_FILE="/home/<username>/db_config.cnf" # Chemin vers le fichier de configuration de la base de données
LOG_FILE="/home/<username>/db_backup_log.txt" # Chemin du fichier de log
WASABI_BUCKET="<bucket_name>" # Nom du bucket Wasabi
WASABI_PATH="mariadb" # Nom du répertoire dans le bukcet, assure-vous de le créer !
# Fonction pour créer les sauvegardes
backup_databases() {
for DB in $DATABASES; do
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
FILENAME="$BACKUP_PATH/${DB}_$TIMESTAMP.sql.gz"
echo "Sauvegarde de la base de données $DB dans $FILENAME"
mysqldump --defaults-file=$CONFIG_FILE --quick $DB | gzip > $FILENAME
if [ $? -eq 0 ]; then
echo "$(date +"%Y-%m-%d %H:%M:%S") - Sauvegarde réussie pour la base de données $DB" >> $LOG_FILE
# Téléchargement vers Wasabi
echo "Transfert de la sauvegarde $FILENAME vers Wasabi avec immuabilité"
aws s3 cp $FILENAME s3://$WASABI_BUCKET/$WASABI_PATH/ 2>&1 | tee -a $LOG_FILE
if [ ${PIPESTATUS[0]} -eq 0 ]; then
echo "$(date +"%Y-%m-%d %H:%M:%S") - Transfert réussi de $FILENAME vers Wasabi" >> $LOG_FILE
else
echo "$(date +"%Y-%m-%d %H:%M:%S") - Échec du transfert de $FILENAME vers Wasabi" >> $LOG_FILE
fi
else
echo "$(date +"%Y-%m-%d %H:%M:%S") - Échec de la sauvegarde pour la base de données $DB" >> $LOG_FILE
fi
done
}
# Fonction pour effacer les anciennes sauvegardes
cleanup_old_backups() {
echo "Suppression des sauvegardes plus anciennes que $RETENTION_DAYS jours"
find $BACKUP_PATH -type f -name '*.sql.gz' -mtime +$RETENTION_DAYS -exec rm {} \;
if [ $? -eq 0 ]; then
echo "$(date +"%Y-%m-%d %H:%M:%S") - Suppression réussie des anciennes sauvegardes" >> $LOG_FILE
else
echo "$(date +"%Y-%m-%d %H:%M:%S") - Échec de la suppression des anciennes sauvegardes" >> $LOG_FILE
fi
}
# Exécution des fonctions
backup_databases
cleanup_old_backups
- Configuration initiale : Le script définit des variables pour les chemins de sauvegarde, les noms des bases de données, le nombre de jours de rétention des sauvegardes locales, le fichier de log, le bucket Wasabi et le chemin dans ce bucket.
- Création de sauvegardes : Pour chaque base de données listée, le script utilise
mysqldump
pour créer une sauvegarde, la compresse au format.gz
, et enregistre le fichier résultant dans un répertoire local spécifié. - Vérification de la sauvegarde : Après la création de chaque sauvegarde, le script vérifie si l’opération a réussi et enregistre le résultat dans un fichier de log.
- Transfert vers Wasabi : Si la sauvegarde locale réussit, le script télécharge ensuite le fichier de sauvegarde compressé vers un bucket Wasabi spécifié, Il vérifie également cette opération et enregistre le résultat dans le fichier de log.
- Nettoyage des sauvegardes anciennes : Le script supprime ensuite les sauvegardes locales qui ont dépassé le nombre de jours de rétention défini et enregistre cette action dans le fichier de log.
Étape 5: Planification de la sauvegarde
Avant mise en place on s’assure que le fichier est bien exécutable :
chmod +x /home/<username>/backup_mariadb.sh
On va ensuite mettre en place la tâche CRON:
#ouverture du fichier de confiugration
crontab -e
#Ajout d'une ligne
#Cette configuration dans crontab va lancer le script toutes les six heures (à minuit, 6h, midi, 18h). Vous pouvez ajuster la fréquence des sauvegardes en modifiant l'expression cron
0 */6 * * * /home/<username>/backup_mariadb.sh
Enregistrez et fermez l’éditeur.
Pratique: LE CALCULATEUR CRON
Étape 6: Test de restauration MariaDB
On va maintenant tester la récupération d’une sauvegarde et la restauration.
En local il vous faudra juste décompresser l’archive
# Décompression de l'archive
gunzip /chemin/vers/les/sauvegardes/nom_de_la_sauvegarde.sql.gz
Pour le stockage Wasabi S3, on va d’abord récupérer la sauvegarde et ensuite la décompresser
# lister les sauvegardes disponibles
aws s3 ls s3://votre-nom-de-bucket/chemin/de/sauvegarde/dans/le/bucket/ --profile wasabi
# récupération d'une sauvegarde
aws s3 cp s3://votre-nom-de-bucket/chemin/de/sauvegarde/dans/le/bucket/nom_de_la_sauvegarde.sql.gz /chemin/vers/les/sauvegardes --profile wasabi
# Décompression de l'archive
gunzip /chemin/vers/les/sauvegardes/nom_de_la_sauvegarde.sql.gz
Maintenant que l’on a notre dump on peut le restaurer dans une base de test
mysql -u utilisateur -p -e "CREATE DATABASE test_restauration"
mysql -u utilisateur -p test_restauration < /chemin/vers/les/sauvegardes/nom_de_la_sauvegarde.sql
Conclusion
Et voilà, chers protecteurs des données ! Vous avez maintenant en main les clés pour sécuriser vos précieuses bases de données MariaDB avec une double dose de sauvegarde : locale et dans le nuage avec Wasabi, enrobée d’une couche d’immuabilité pour une tranquillité d’esprit inégalée en 2024.
Mais ne vous arrêtez pas en si bon chemin ! Pour parfaire votre stratégie de sauvegarde, pourquoi ne pas ajouter une pincée de notifications par e-mail ? Ainsi, vous serez toujours informé en temps réel du succès ou de l’échec de vos sauvegardes. Et pour les chefs étoilés de la prévoyance, envisagez le test de restauration automatisé. Rien de tel pour dormir sur vos deux oreilles, en sachant que vos données peuvent être restaurées à la minute près, comme par magie.
En somme, gardez en tête que l’avenir appartient à ceux qui préparent leurs sauvegardes la veille. Ne relâchez pas votre vigilance, et continuez à explorer de nouvelles avenues pour renforcer la sécurité de vos données. Après tout, dans le grand livre de la cybersécurité, chaque page compte !
A+ les Techies
Zalman VE500
Voila un outil indispensable que tout technicien doit avoir avec lui, c’est ce boitier qui contient un HDD/SSD et avec le quel on va pouvoir tout simplement booter sur l’image disque que l’on souhaite (ISO, IMG). d’autres options sont aussi présentes comme la sélection du mode HDD, VCD ou les deux ainsi que le cryptage du disque et le verrouillage en écriture.
On en parle sur le blog !IODD ST400 Boîtier 2,5" / USB-C/Bootable Virtual ODD&HDD / Chiffrement AES256 Max jusqu'à 76 chiffres/Protection en écriture / 2541 (ST400/Type USB-C/Modèle Next Gen) Fabriqué en Corée
IODD Mini USB 3.0 256 Bits Secure Encrypted SSD Drive 512 Go