Comprendre la sauvegarde d'une base MariaDB : mon dialogue avec l'IA Claude

Un peu réticent à utiliser une IA, j'ai fini par sauter le pas en testant Claude, qui semblait apprécié des programmeurs.

Ci-dessous, vous pourrez suivre mes questions et les réponses de l'IA à propos de la sauvegarde des données de la base d'une application nommée Gestiasso.

Cet échange m'a permis de bien comprendre les tenants et aboutissants de la sauvegarde d'une base MariaDB — et je le partage tel quel, tâtonnements compris, car c'est justement ce cheminement qui aide à comprendre.

Question 1 : Si l'on modifie des données d'une base dans phpMyAdmin, faut-il mettre à jour le fichier `.sql` de l'application ?

Réponse : non, pas besoin !

Le fichier database.sql est juste un script d'installation initial. Il sert uniquement à :

créer la structure de la base de données (tables, colonnes)
insérer les données de démonstration
une seule fois, au tout début

Après l'installation :

✅ Vous modifiez les données dans phpMyAdmin → ça change directement la base de données
✅ Vous modifiez via l'application web → ça change directement la base de données
❌ Le fichier database.sql n'est jamais relu ni réutilisé

Quand mettre à jour `database.sql` ?

Uniquement si vous voulez :

réinstaller l'application sur un autre serveur avec vos données actuelles
partager votre structure avec quelqu'un d'autre
sauvegarder la structure ET les données pour réinstaller plus tard

Dans ce cas, on peut régénérer le fichier SQL :

# Export complet (structure + données)
mysqldump -u papinou -p asso_culturelle > /var/www/asso/database_backup.sql

# Ou juste la structure (sans données)
mysqldump -u papinou -p --no-data asso_culturelle > /var/www/asso/database_structure.sql

En résumé

phpMyAdmin ──┐
             ├──> BASE DE DONNÉES (source unique de vérité)
Application ─┘

database.sql = fichier d'installation initial (utilisé une seule fois)

Workflow normal :

On installe l'application → database.sql crée la base
On utilise l'application ou phpMyAdmin → modifications dans la base de données
Le fichier database.sql reste tel quel (pas besoin de le toucher)

Le fichier database.sql ne sert qu'à l'installation ! On modifie nos données dans phpMyAdmin ou l'application, tout est synchronisé automatiquement dans la base.

C'est important de bien distinguer :

le fichier SQL = script d'installation (statique)
la base de données = données vivantes (dynamiques)

Question 2 : Si j'ai bien compris, phpMyAdmin ou l'utilisation de mysql depuis le terminal renseignent automatiquement le fichier `database.sql` ? Mais sous quelle forme les nouvelles données sont-elles inscrites dans la base ?

Réponse : Ah non, petite confusion ! Clarifions précisément.

❌ Ce qui est faux

phpMyAdmin ne modifie pas le fichier database.sql
MySQL depuis le terminal ne modifie pas le fichier database.sql
Le fichier database.sql ne change jamais automatiquement

✅ Ce qui est vrai

Le fichier database.sql et la base de données sont deux choses complètement séparées.

1. Le fichier database.sql

C'est un fichier texte qui contient des commandes SQL — comme une recette :

CREATE TABLE adherents (...);
INSERT INTO adherents VALUES (...);

Il est utilisé une seule fois :

mysql -u papinou -p asso_culturelle < database.sql

Cette commande lit le fichier et exécute les instructions SQL qu'il contient. Après ça, le fichier ne sert plus à rien : il reste là, mais n'est jamais ni modifié ni relu.

2. La base de données (MariaDB/MySQL)

C'est un système de stockage qui garde les données dans des fichiers binaires sur le disque dur :

ls -la /var/lib/mysql/asso_culturelle/

On y trouve des fichiers comme :

adherents.ibd            ← données de la table adherents
cotisations.ibd          ← données de la table cotisations
transactions_compta.ibd  ← etc.

Ces fichiers sont binaires (illisibles avec un simple éditeur de texte).

Flux des données

┌─────────────────────┐
│  database.sql       │  (fichier texte SQL - installation uniquement)
└──────────┬──────────┘
           │ mysql < database.sql   (UNE SEULE FOIS)
           ↓
┌─────────────────────────────────────────────┐
│     BASE DE DONNÉES MariaDB                  │
│  /var/lib/mysql/asso_culturelle/             │
│                                               │
│  adherents.ibd (fichiers binaires)           │
│  cotisations.ibd                             │
│  transactions_compta.ibd                     │
└─────────────────────────────────────────────┘
           ↑                    ↑
     ┌─────┴─────┐       ┌─────┴─────┐
     │ phpMyAdmin│       │ Application│
     └───────────┘       └───────────┘

Quand on ajoute un adhérent via phpMyAdmin ou l'application, l'instruction SQL est envoyée :

INSERT INTO adherents (nom, prenom) VALUES ('Dupont', 'Marie');

MariaDB stocke ça dans /var/lib/mysql/asso_culturelle/adherents.ibd (format binaire, optimisé pour la performance). Le fichier database.sql ne change pas.

Pour exporter ses données vers un fichier SQL

mysqldump -u papinou -p asso_culturelle > backup_$(date +%Y%m%d).sql

Cela crée un nouveau fichier (comme backup_20260213.sql) contenant la structure des tables et toutes les données actuelles — mais ça ne modifie pas le fichier database.sql original.

Analogie

database.sql = une recette de cuisine écrite sur papier
la base de données = un réfrigérateur où l'on stocke les aliments

On lit la recette une fois, on prépare les plats, on les met au frigo. Ensuite on ajoute/retire des aliments du frigo librement. La recette sur papier ne change jamais. Si l'on veut une nouvelle recette basée sur ce qu'il y a dans le frigo, il faut l'écrire soi-même — c'est exactement ce que fait mysqldump.

Résumé

Élément	Type	Rôle	Modifié automatiquement ?
`database.sql`	Fichier texte	Installation initiale	❌ Non, jamais
Base de données	Fichiers binaires	Stockage des données	✅ Oui, à chaque modification
phpMyAdmin	Interface web	Modifier la base	— (c'est un outil)
Application	Interface web	Modifier la base	— (c'est un outil)

Les nouvelles données ne sont pas entrées dans .sql : elles sont inscrites directement dans la base (fichiers binaires .ibd dans /var/lib/mysql/). Le fichier .sql reste inchangé et n'est jamais relu après l'installation initiale.

Question 3 : Quand on sauvegarde `database.sql` sur son disque ou une clé USB, c'est donc la recette que l'on sauvegarde. Les fichiers binaires sont-ils sauvegardés également ?

Réponse : exactement ! Vous avez parfaitement compris.

Quand vous sauvegardez database.sql :

✅ vous sauvegardez la recette initiale (structure + données de démo)
❌ vous ne sauvegardez pas vos nouvelles données
❌ les fichiers binaires (.ibd) ne sont pas sauvegardés

Les différents types de sauvegarde

1. Copier database.sql seul → insuffisant

cp /var/www/asso/database.sql /media/cleusb/

Ce que ça sauvegarde : la structure des tables et les données de démonstration d'origine. Pas vos vraies données !

2. Sauvegarder les fichiers binaires → déconseillé

sudo cp -r /var/lib/mysql/asso_culturelle /media/cleusb/

Ça sauvegarde bien toutes les vraies données, mais :

❌ risque de corruption si MySQL est en cours d'exécution
❌ dépendant de la version de MySQL
❌ difficile à restaurer sur un autre système

⚠️ Ne faites pas ça sauf à arrêter MySQL au préalable !

3. Export SQL avec mysqldump → recommandé

mysqldump -u papinou -p asso_culturelle > backup_complet.sql
cp backup_complet.sql /media/cleusb/

Ce que ça sauvegarde : la structure des tables et toutes les vraies données actuelles, en format texte SQL lisible et portable. Ce fichier ressemble à database.sql, mais avec vos données !

Comparaison concrète

En imaginant 50 adhérents ajoutés depuis l'installation :

Fichier	Contient quoi ?	Sauvegarde les 50 adhérents ?
`database.sql` (original)	5 adhérents de démo	❌ Non
Fichiers binaires `/var/lib/mysql/`	50 adhérents réels	✅ Oui (mais risqué)
`mysqldump` → `backup.sql`	50 adhérents réels	✅ Oui (recommandé)

Stratégie de sauvegarde complète recommandée

A. Sauvegarde de la base de données

mysqldump -u papinou -p asso_culturelle > backup_$(date +%Y%m%d_%H%M%S).sql

B. Sauvegarde des fichiers de l'application

tar -czf asso_files_$(date +%Y%m%d).tar.gz /var/www/asso

C. Copie sur clé USB

cp backup_*.sql /media/cleusb/
cp asso_files_*.tar.gz /media/cleusb/

Script de sauvegarde automatique complet

#!/bin/bash

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

mkdir -p $BACKUP_DIR

# 1. Sauvegarde de la BASE DE DONNÉES (mysqldump)
echo "Sauvegarde base de données..."
mysqldump -u papinou -p'VOTRE_MDP' asso_culturelle > $BACKUP_DIR/db_$DATE.sql

# 2. Sauvegarde des FICHIERS de l'application
echo "Sauvegarde fichiers..."
tar -czf $BACKUP_DIR/files_$DATE.tar.gz /var/www/asso

# 3. Nettoyage (garder 30 jours)
find $BACKUP_DIR/db_*.sql -mtime +30 -delete
find $BACKUP_DIR/files_*.tar.gz -mtime +30 -delete

echo "✓ Sauvegarde terminée : $DATE"
ls -lh $BACKUP_DIR

Ce script sauvegarde tout : les vraies données (via mysqldump) et les fichiers de l'application.

Pour copier automatiquement sur clé USB, on peut ajouter à la fin du script :

# Copier sur clé USB si elle est montée
USB_PATH="/media/papinou/CLEUSB"  # à adapter selon le chemin réel
if [ -d "$USB_PATH" ]; then
    echo "Copie sur clé USB..."
    cp $BACKUP_DIR/db_$DATE.sql $USB_PATH/
    cp $BACKUP_DIR/files_$DATE.tar.gz $USB_PATH/
    echo "✓ Copié sur clé USB"
else
    echo "⚠ Clé USB non détectée"
fi

Restauration depuis une sauvegarde

Si l'on dispose d'un fichier SQL (via mysqldump) :

mysql -u papinou -p asso_culturelle < backup_20260213_213045.sql

Si l'on dispose de l'archive des fichiers :

sudo tar -xzf asso_files_20260213.tar.gz -C /

En résumé

Ce qu'il faut sauvegarder régulièrement :

l'export SQL (via mysqldump) → les vraies données ✅
les fichiers de l'application (optionnel, change peu souvent)

Ce qu'on peut ignorer :

❌ database.sql original (c'est juste la recette de démo)
❌ les fichiers binaires .ibd (risqués, préférer mysqldump)

Question 4 : phpMyAdmin semble donc utiliser `mysqldump` pour sauvegarder la recette et les données binaires lors de son export ?

Réponse : Ah non, petite confusion sur phpMyAdmin ! Clarifions.

phpMyAdmin n'est pas mysqldump, mais utilise le même principe. Quand on exporte depuis phpMyAdmin :

phpMyAdmin lit les données depuis la base (fichiers binaires)
phpMyAdmin génère un fichier SQL (comme le ferait mysqldump)
On télécharge ce fichier .sql

Ce fichier contient :

✅ la structure des tables (CREATE TABLE...)
✅ les données actuelles (INSERT INTO...)
❌ mais pas les fichiers binaires eux-mêmes

Processus détaillé

┌─────────────────────────────────┐
│ Fichiers binaires sur disque    │
│ /var/lib/mysql/asso_culturelle/ │
│  - adherents.ibd                │
│  - cotisations.ibd              │
└────────────┬────────────────────┘
             │ phpMyAdmin lit les données
             ↓
┌─────────────────────────────────┐
│ phpMyAdmin génère un fichier SQL│
│                                  │
│ CREATE TABLE adherents...       │
│ INSERT INTO adherents VALUES... │
└────────────┬────────────────────┘
             │ téléchargement
             ↓
┌─────────────────────────────────┐
│ Fichier .sql sur le PC          │
│ (format texte, pas binaire)     │
└─────────────────────────────────┘

phpMyAdmin fait donc une conversion binaire → SQL (texte). Les fichiers binaires ne sont jamais copiés directement — phpMyAdmin traduit les données binaires en instructions SQL textuelles.

Exemple concret

Dans les fichiers binaires (/var/lib/mysql/), le format est illisible directement. Dans le fichier SQL exporté (par phpMyAdmin ou mysqldump), on obtient un format texte lisible :

INSERT INTO `adherents` VALUES
(1, '2024-001', 'Mme', 'Dupont', 'Marie', '1985-05-12', ...),
(2, '2024-002', 'M', 'Martin', 'Pierre', '1990-08-23', ...);

Comparaison des méthodes de sauvegarde

Méthode	Outil	Format de sortie	Contient quoi ?
Export phpMyAdmin	Interface web	`.sql` (texte)	Structure + données actuelles ✅
`mysqldump`	Ligne de commande	`.sql` (texte)	Structure + données actuelles ✅
Copie fichiers binaires	`cp /var/lib/mysql/`	`.ibd` (binaire)	Données brutes (risqué ⚠️)

Ce que phpMyAdmin sauvegarde vraiment

Lors d'un "Exporter" dans phpMyAdmin :

✅ la structure complète des tables
✅ toutes les données actuelles (adhérents, cotisations, transactions...)
✅ format SQL texte (portable, lisible)

Et ce qui n'est pas sauvegardé :

❌ les fichiers binaires .ibd eux-mêmes
❌ les logs MySQL
❌ la configuration du serveur

Analogie finale

Les fichiers binaires sont comme un livre en chinois, illisible directement. phpMyAdmin (ou mysqldump) joue le rôle d'un traducteur : il lit le livre chinois, le traduit en français (SQL), et donne la version française — mais on ne récupère jamais le livre chinois original, seulement sa traduction.

Conclusion pour la question posée

✅ phpMyAdmin convertit les données binaires en SQL (comme mysqldump)
✅ Il sauvegarde les vraies données actuelles (pas juste la recette de démo)
❌ Il ne sauvegarde pas les fichiers binaires eux-mêmes
❌ Il n'utilise pas directement mysqldump en interne, mais produit un résultat équivalent

En pratique, export phpMyAdmin et mysqldump en ligne de commande donnent le même résultat : les deux méthodes sont fiables et recommandées.

Pour résumer en une phrase : phpMyAdmin transforme les fichiers binaires en un fichier SQL texte que l'on peut sauvegarder.

Conclusion

"Ce n'est plus du chinois pour moi désormais."

De "c'est du chinois" à "ce n'est plus du chinois" — c'est exactement l'objectif d'un bon échange avec une IA : ne pas se contenter d'une solution toute faite, mais comprendre, étape après étape, ce qui se passe réellement derrière les commandes qu'on utilise.

Comprendre la sauvegarde d'une base MariaDB : mon dialogue avec l'IA Claude

Question 1 : Si l'on modifie des données d'une base dans phpMyAdmin, faut-il mettre à jour le fichier .sql de l'application ?

Quand mettre à jour database.sql ?

En résumé

Question 2 : Si j'ai bien compris, phpMyAdmin ou l'utilisation de mysql depuis le terminal renseignent automatiquement le fichier database.sql ? Mais sous quelle forme les nouvelles données sont-elles inscrites dans la base ?

❌ Ce qui est faux

✅ Ce qui est vrai

Flux des données

Pour exporter ses données vers un fichier SQL

Analogie

Résumé

Question 3 : Quand on sauvegarde database.sql sur son disque ou une clé USB, c'est donc la recette que l'on sauvegarde. Les fichiers binaires sont-ils sauvegardés également ?

Les différents types de sauvegarde

Comparaison concrète

Stratégie de sauvegarde complète recommandée

Script de sauvegarde automatique complet

Restauration depuis une sauvegarde

En résumé

Question 4 : phpMyAdmin semble donc utiliser mysqldump pour sauvegarder la recette et les données binaires lors de son export ?

Processus détaillé

Exemple concret

Comparaison des méthodes de sauvegarde

Ce que phpMyAdmin sauvegarde vraiment

Analogie finale

Conclusion pour la question posée

Conclusion

Question 1 : Si l'on modifie des données d'une base dans phpMyAdmin, faut-il mettre à jour le fichier `.sql` de l'application ?

Quand mettre à jour `database.sql` ?

Question 2 : Si j'ai bien compris, phpMyAdmin ou l'utilisation de mysql depuis le terminal renseignent automatiquement le fichier `database.sql` ? Mais sous quelle forme les nouvelles données sont-elles inscrites dans la base ?

Question 3 : Quand on sauvegarde `database.sql` sur son disque ou une clé USB, c'est donc la recette que l'on sauvegarde. Les fichiers binaires sont-ils sauvegardés également ?

Question 4 : phpMyAdmin semble donc utiliser `mysqldump` pour sauvegarder la recette et les données binaires lors de son export ?