MICHEL CAMPILLO

Consultant chef de projet IT

INTEGRATION DE LOGICIEL
Gestion de projet - Déploiement - Implantation - Maintenance

Téléphone: 06 89 56 58 18 – Web: michelcampillo.com

La modélisation des processus est une des activités du consultant fonctionnel

Sauvegardes BDD automatisées avec CRON

Automatisation Les développeurs web et administrateurs systèmes savent qu'une base de données est au coeur d'un projet. Elle contient les utilisateurs, les contenus, parfois les secrets les mieux gardés. Un crash serveur, une erreur humaine, ou une mise à jour ratée, et c'est la catastrophe.

L'automatisation des sauvegardes de base de données via un script shell et un CRON permet de réduire le risque et le stress. Pas besoin de lancer une commande manuelle tous les soirs à 23h59. Le serveur s'en charge.

Cet article propose un parcours progressif : du débutant qui veut comprendre les bases, à l'intermédiaire qui fiabilise ses scripts, jusqu'à l'avancé qui compare des solutions plus robustes comme Borg ou Restic, ou des offres managées type AWS Backup.

Si vous cherchez un accompagnement clé en main, vous pouvez contacter un développeur web professionnel.

Illustration d'une automatisation des sauvegardes de base de données sous Linux avec CRON
Automatisez vos sauvegardes de bases de données avec un script shell et CRON.

🚀 Contexte et fondamentaux

Définitions et périmètre

Une sauvegarde est une copie fidèle des données stockées, restaurable en cas de problème. L'automatisation rend cette tâche récurrente sans intervention humaine.

Script shell : fichier texte contenant des commandes Bash.
CRON : planificateur Unix qui exécute des tâches selon une fréquence définie.
Base de données : MySQL, PostgreSQL, MariaDB, SQLite. La logique reste similaire quel que soit le moteur.

Choix techniques et contraintes

Fréquence : quotidienne, horaire, ou hebdomadaire selon la criticité et le RPO attendu.
Stockage : disque local, serveur distant via rsync ou scp, ou cloud objet (S3, GCS).
Restauration : une sauvegarde non testée n'existe pas. Il faut valider régulièrement une restauration complète.

Erreurs fréquentes à éviter

Oublier les permissions, ce qui bloque l'écriture du dump.
Laisser des mots de passe en clair dans un dépôt Git.
Omettre la rotation : un disque plein casse tous les CRON.

🚀 Mise en pratique guidée

Préparation de l'environnement

Accès SSH à un serveur Linux avec Bash.
Outils installés : mysqldump ou pg_dump, gzip, et éventuellement rsync ou aws CLI.
Service CRON actif :

	
systemctl status cron # Debian/Ubuntu
systemctl status crond # CentOS/RHEL/Alma/Rocky

Étapes pas-à-pas (avec snippets commentés)

Exemple MySQL/MariaDB : script minimal

	
  #!/bin/bash
  backup.sh : script de sauvegarde MySQL simple
  Usage: planifié via CRON pour un dump quotidien compressé

  set -euo pipefail

  DB_NAME="ma_base"
  DB_USER="mon_user"
  DB_PASS="${DB_PASS:-}" # lire depuis variable d'environnement
  BACKUP_DIR="/var/backups/mysql"
  DATE="$(date +'%Y%m%d_%H%M')"

  mkdir -p "$BACKUP_DIR"

  # Dump transactionnel pour minimiser les verrous
  mysqldump --single-transaction -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql"

  # Compression
  gzip -9 "$BACKUP_DIR/${DB_NAME}_${DATE}.sql"

  # Sortie explicite
  echo "OK : $BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"

Bonne pratique : ne mettez pas le mot de passe en clair dans le script. Exportez la variable avant exécution :

	
  export DB_PASS='motdepasse' /chemin/vers/backup.sh

Planification CRON à 2h du matin tous les jours :

	
  crontab -e 0 2 * * * DB_PASS='motdepasse' /chemin/vers/backup.sh >> /var/log/backup.log 2>&1

Exemple PostgreSQL

	
  #!/bin/bash

  # backup_pg.sh : sauvegarde PostgreSQL simple

  set -euo pipefail

  PGDATABASE="ma_base"
  PGUSER="mon_user"
  PGPASSWORD="${PGPASSWORD:-}" # lire depuis variable d'environnement
  export PGPASSWORD

  BACKUP_DIR="/var/backups/postgres"
  DATE="$(date +'%Y%m%d_%H%M')"

  mkdir -p "$BACKUP_DIR"

  pg_dump -U "$PGUSER" "$PGDATABASE" > "$BACKUP_DIR/${PGDATABASE}${DATE}.sql"
  gzip -9 "$BACKUP_DIR/${PGDATABASE}${DATE}.sql"
  echo "OK: $BACKUP_DIR/${PGDATABASE}_${DATE}.sql.gz"

Restauration de test

	
  # MySQL/MariaDB
  gunzip -c /var/backups/mysql/ma_base_20240101_0200.sql.gz | mysql -u mon_user -p ma_base
  # PostgreSQL
  gunzip -c /var/backups/postgres/ma_base_20240101_0200.sql.gz | psql -U mon_user -d ma_base

Tests, validation, et dépannage

Vérifier la présence et la taille des fichiers .sql.gz.
Journaliser : rediriger stdout et stderr vers un fichier de log.
Si CRON ne tourne pas : consulter /var/log/syslog ou journalctl -u cron.
Tester une restauration complète sur une base temporaire pour valider l'intégrité.

🚀 Cas concrets et comparaisons

Cas A (exigences, implémentation, pièges)

Contexte : projet vitrine à faible volumétrie. Objectif : simplicité maximale.

Implémentation : script local + CRON quotidien + rotation simple par date dans le nom de fichier.

Pièges : le stockage local reste un SPOF. Prévoir une copie distante hebdomadaire via rsync.

✎ Pour aller plus loin dans votre approche technique

L'utilisation du spool SQL dans une base de données Oracle (Posté le mercredi 12 novembre): Vous travaillez sur des bases de données Oracle? Vous utilisez très certainement l'outil Oracle SQL*Plus qui permet de générer des fichiers plats CSV en utilisant le spool d'une requête de base de données. Cela permet d'extraire des données dont l'affichage n'est pas prévu nativement dans les écrans de l'ERP.

Cas B (alternative, trade-offs)

Contexte : application e-commerce. Objectif : RPO faible et conservation 30 jours.

Implémentation : dump horaire vers un bucket S3 compatible, chiffrement au repos, cycle de rétention côté objet, alerte en cas d'échec.

Trade-offs : dépendance réseau et coût de stockage, mais résilience supérieure et restauration rapide.

Table courte de comparaison si utile

Méthode	Simples	Sécurité	Coût	Cas d'usage
Script local	++	-	0	Petits projets
Rsync/SSH	+	++	faible	Petites prod
S3/Cloud objet	+	+++	variable	Prod critique
Borg/Restic	+	+++	faible	Archivage, déduplication

🚀 Optimisations et bonnes pratiques

Performance, sécurité, accessibilité

Pour MySQL : --single-transaction et éventuellement --quick pour réduire la mémoire.
Pour PostgreSQL : privilégier pg_dump en format custom -Fc pour des restaurations sélectives.
Gérer les secrets via variables d'environnement, fichiers .my.cnf ou .pgpass avec permissions strictes.
Ajouter un message clair en cas d'échec pour aider l'accessibilité des logs.

Maintenance et évolutions possibles

Notifier sur Slack, Discord ou email après chaque backup.
Passer à des snapshots filesystem LVM ou ZFS pour réduire le temps de freeze applicatif.
Intégrer la vérification de restauration dans une CI planifiée.

FAQ ciblée

Question 1

Peut-on automatiser plusieurs bases en même temps ? Oui, bouclez sur une liste de bases dans le script et faites un dump par base.

Question 2

CRON est-il fiable à 100 % ? Il est robuste, mais surveillez les logs et l'espace disque. Ajoutez des alertes.

Question 3

Quelle rétention choisir ? 30 jours est une base courante. Ajustez selon la criticité et les obligations légales.

🚀 Conclusion

Un script shell avec CRON suffit pour une sauvegarde simple et automatique.
La sécurité réelle vient des tests de restauration réguliers.
Pour la production critique, examinez rsync, S3, BorgBackup ou Restic.

Avec l'automatisation des sauvegardes de base de données, vous réduisez les risques et gagnez du temps. Prochaine étape : écrire votre script, planifier CRON, et valider une restauration complète. Vous aimez cet article ? Retrouvez-en plus sur le blog Symplyweb.

Annexes

Références

Outre l'email / téléphone, les visioconférences sur Google Meet sont une moyen privilégié de me contacter. La simplicité d'utilisation de cet outil en fait un choix évident, n'imposant aucune installation. Renseignez mon adresse email pour une invitation via Google Agenda.

Pays de Provence, le 23 septembre 2025

Michel Campillo

Michel Campillo
Consultant chef de projet IT
☎ 06 89 56 58 18 ✉ contact par email

➽ Autres billets pour consultants ERP travaillant sur des bases de données Oracle: Comment changer la taille de police dans Oracle SQL Developer?, Configuration de SQL Developer pour MySQL (3813).

Ce post vous a aidé? Alors partagez-le avec d'autres utilisateurs en cliquant sur les boutons ci-dessous:

Merci de vos partages! 👷🏻‍

Comment Form is loading comments...

🎯 À consulter : Mentions légales. Derniers articles : La DSP2, tournant stratégique en informatique bancaire, L'illusion du pilotage de projet Agile, Piloter un projet ERP, Page entreprise sur Linkedin, Déboires lors d'une formation utilisateurs, Factures manuelles, Consultant sur un logiciel métier, Déblocage de téléphone mobile, Ma playlist du moment, Aix-en-Provence, Le BRD, maillon oublié mais essentiel des projets IT, les modèles de structure de répartition du travail, L'intelligence artificielle, levier de performance et transformation du BTP, un consultant logiciel, Réussir sa migration ERP, stratégies et bonnes pratiques.
⛅ L'automne est arrivé, un temps propice au travail non? ☂️