18. Sauvegarde et restauration : BACKUP, miraj-backup, miraj-dump

MIRAJ propose deux façons de sauvegarder une base, complémentaires :

Règle pratique : sauvegardez chaque jour avec BACKUP DATABASE (rapide, restauration immédiate) et gardez de temps en temps un export miraj-dump --users (portable, lisible, indépendant de la version).

18.1 Sauvegarde physique à chaud#

18.1.1 Activer : --backup-dir#

Les deux instructions sont refusées (erreur 1290) tant que le serveur n'a pas de dossier de sauvegardes :

miraj-server --root D:\miraj\data --backup-dir E:\sauvegardes --log

ou dans miraj_config.xml :

<backup_dir>E:\sauvegardes</backup_dir>

Le dossier est créé s'il n'existe pas. Il ne doit ni contenir ni se trouver dans le dossier de données ou celui des clés du coffre. Toutes les sauvegardes et restaurations SQL s'y font : un chemin relatif s'y rapporte, un chemin absolu doit s'y trouver, .. est refusé. Placez-le de préférence sur un autre disque que les données.

18.1.2 BACKUP DATABASE#

BACKUP DATABASE nom TO 'dossier'
BACKUP DATABASE nom1, nom2 TO 'dossier'
BACKUP ALL DATABASES TO 'dossier'

• Le dossier de destination est créé ; s'il existe, il doit être vide.
• Avec plusieurs bases (liste ou ALL DATABASES), chaque base a son sous-dossier dossier\nom. ALL DATABASES exclut la base système.
• Le résultat compte une ligne par base : Database, Directory, Files, Bytes, End_lsn (position du journal atteinte par la copie).
• Droit requis : BACKUP_ADMIN.

BACKUP DATABASE gestion TO 'gestion-2026-09-24';

Ce qui se passe pendant la copie. La sauvegarde attend la fin des écritures de fichier en cours, puis tient brièvement toutes les tables de la base en lecture. Pendant ce court instant, de l'ordre de quelques millisecondes, les écritures attendent et les lectures continuent. La sauvegarde pose alors un second lien vers chaque fichier dans un dossier de travail et relève la position du journal. Tout est ensuite rendu. La copie proprement dite se fait sans rien bloquer, pendant que les clients continuent d'écrire.

Le résultat est une coupure nette : toutes les transactions validées avant la phase figée sont dans la sauvegarde, aucune de celles validées après. Une transaction n'y est jamais à moitié. Avec plusieurs bases, chacune est coupée à son propre instant : la sauvegarde de plusieurs bases n'est pas un instantané commun.

Cas particuliers :

• Une transaction ouverte par la session qui lance BACKUP est validée d'abord, comme avant un DDL.
• BACKUP est refusé sous LOCK TABLES de la session et dans une routine (1314). Une table tenue par le LOCK TABLES ... WRITE d'une autre session fait échouer la sauvegarde (table occupée).
• En politique save_policy = manual (aucun journal), les tables sont d'abord écrites sur le disque, toute autre instruction étant suspendue le temps de cette écriture. Une transaction ouverte sur une table empêche alors la sauvegarde.
• Un dossier de destination incomplet (serveur arrêté pendant la copie) n'a pas de manifest.json : il n'est pas restaurable et peut être supprimé. Le dossier de travail éventuel (<root>\.backup-…) est supprimé au redémarrage suivant.

18.1.3 Contenu d'une sauvegarde#

gestion-2026-09-24\
  manifest.json      description de la sauvegarde, écrite en dernier
  clients.mrj        une table par fichier .mrj
  clients.bmrj       BLOB longs de la table
  routines.mrp       procédures et fonctions
  views.mrv          vues
  triggers.mrt       déclencheurs
  events.mre         événements
  journal.mrl        journal : transactions à rejouer sur les tables à la restauration

manifest.json indique :

• la base d'origine, la date et la version du moteur ;
• les positions du journal ;
• pour chaque fichier, sa taille et sa somme de contrôle (CRC32).

La sauvegarde n'est pas compressée : compressez le dossier avec l'outil de votre choix si nécessaire.

18.1.4 RESTORE DATABASE#

RESTORE DATABASE nom FROM 'dossier' [REPLACE]

1. Le manifeste est lu. Chaque fichier est recopié dans un dossier de travail de la racine, et sa taille et sa somme de contrôle sont vérifiées au passage. Une sauvegarde altérée est refusée sans rien toucher.
2. La base est ensuite installée sous le nom nom, puis chargée. Le journal de la copie est rejoué, comme à un redémarrage.

Le nom peut différer de celui de la base sauvegardée : c'est ainsi qu'on restaure à côté de la base en service pour comparer ou récupérer des lignes. Un avertissement (SHOW WARNINGS) le rappelle. Les références qualifiées par l'ancien nom dans les vues, les routines ou les clés étrangères vers une autre base gardent l'ancien nom.

• Nom déjà pris : erreur 1007, sauf avec REPLACE, qui supprime d'abord la base existante, comme DROP DATABASE. Des lignes tenues par une transaction ouverte empêchent le remplacement.
• Nom invalide ou base système : erreur 1102.
• Droits requis : BACKUP_ADMIN et CREATE, plus DROP avec REPLACE.
• Cluster : refusé sur un nœud secondaire et dans un cluster à plusieurs nœuds. Une base restaurée n'est pas transmise aux secondaires : restaurez sur un nœud seul.
• Arrêt pendant la restauration : au redémarrage, la base est soit absente, soit entière, jamais à moitié installée. Le dossier de travail (<root>\.restore-…) est supprimé.

RESTORE DATABASE gestion_hier FROM 'gestion-2026-09-23';
SELECT * FROM gestion_hier.clients WHERE id = 42;

18.2 L'outil miraj-backup#

miraj-backup pilote les mêmes opérations depuis la ligne de commande, par exemple dans une tâche planifiée.

miraj-backup backup  --db <base>[,<base>…] | --all  --to <dossier>  [connexion | --root <dossier de données>]
miraj-backup restore --from <dossier> --db <nom> [--replace]      [connexion | --root <dossier de données>]
miraj-backup verify  --from <dossier> [--deep]
miraj-backup list    --from <dossier>

Connexion :

Hors ligne : --root <dossier de données> et, si la clé du coffre n'est pas à son emplacement par défaut, --key-dir. Si un serveur tient le dossier, l'outil le signale et conseille le mode réseau.

verify et list lisent un dossier de sauvegarde local, sans serveur :

• verify contrôle la présence, la taille et la somme de contrôle de chaque fichier, ainsi que le journal ;
• verify --deep relit en plus chaque table ;
• list affiche le manifeste.

Code de sortie : 0 si tout a réussi, 1 sinon.

Exemple de tâche planifiée quotidienne :

miraj-backup backup --all --to quotidien-%DATE:~6,4%%DATE:~3,2%%DATE:~0,2% --password %MIRAJ_PWD%

18.3 L'outil miraj-dump : sauvegarde en SQL#

miraj-dump [export] --db <base>[,<base>…] | --all  [-r <fichier.sql>] [options] [connexion | --root <dossier>]
miraj-dump restore <fichier.sql> [-d <base>] [--force] [connexion | --root <dossier>]

18.3.1 Export#

Le script est écrit sur la sortie standard, ou dans le fichier -r. Le fichier est d'abord écrit sous un nom temporaire, puis renommé à la fin : un export interrompu ne laisse pas de script tronqué.

Ordre du script :

1. En-tête (SET NAMES utf8mb4, contrôles des clés étrangères coupés).
2. Comptes.
3. Pour chaque base :
   1. tables (parentes avant enfants) avec leurs lignes ;
   2. vues (dans l'ordre de leurs dépendances) ;
   3. routines ;
   4. déclencheurs (après les lignes : ils ne se déclenchent pas au chargement) ;
   5. événements.
4. Droits des comptes.

Les valeurs sont écrites comme suit :

• BLOB et colonnes binaires en hexadécimal (X'…') ;
• chaînes échappées ;
• dates et heures avec leurs fractions de seconde ;
• nombres tels que le serveur les rend.

Cohérence : par défaut, toute la lecture se fait dans une seule transaction. Le script reflète donc un instant unique, sans bloquer les autres sessions. Un DDL exécuté pendant l'export sur une table pas encore lue fait échouer l'export (1213) : relancez-le.

18.3.2 Restauration#

miraj-dump restore lit le script au fil de l'eau, même pour plusieurs gigaoctets, et exécute ses instructions une à une. Les corps de routines, de déclencheurs et d'événements sont entourés de DELIMITER ;; dans le script, et l'outil comprend cette commande.

• -d <base> choisit la base courante au départ.
• --force continue après une erreur. Sinon, la restauration s'arrête à la première erreur, en indiquant la ligne du script.

miraj-cli n'interprète pas DELIMITER : pour un script produit par miraj-dump, utilisez miraj-dump restore.

18.4 Quelle méthode choisir ?#

Dans tous les cas, testez vos restaurations régulièrement : miraj-backup verify --deep contrôle une sauvegarde physique. Une restauration sous un autre nom suivie de quelques comparaisons contrôle l'ensemble de la chaîne.