@mostajs/backup

Auteur : Dr Hamid MADANI [email protected] · Licence : AGPL-3.0-or-later · Niveau : N1

Sauvegarder, vérifier, restaurer. Pour de vrai.

Une copie n'est pas une sauvegarde

@mostajs/orm-copy-data transfère (A → B) : pas d'artefact, pas de temps, pas de vérification. Copier vers une seconde base ne donne pas une sauvegarde mais une réplique : le jour où quelqu'un supprime 300 tickets par erreur, la suppression se propage fidèlement. On a recopié le désastre.

Une sauvegarde est un artefact figé, daté, vérifiable et restaurable. Ce qui la définit, ce n'est pas la copie — c'est le temps, l'intégrité et la restaurabilité.

Ce module n'invente rien — il compose

| Besoin | Module | |---|---| | données | @mostajs/orm-copy-data | | artefact (zip, manifeste, empreintes, signature) | @mostajs/archive-box | | chiffrement (flux AEAD, enveloppe X25519) | @mostajs/crypto-box | | dépôt (disque, S3, MinIO…) | @mostajs/blob-store |

Il n'ajoute que ce qu'aucun d'eux n'a : le périmètre, la rétention, le test de restauration et la restauration vérifiée.

Le périmètre : au-delà des entités

orm-copy-data ne voit que les entités de l'ORM. Une restauration qui rend les tickets mais pas la configuration ni la licence ne remet pas le cabinet en marche lundi matin. createBackup embarque donc entités + config + fichiers.

Le modèle qui rend le service vendable

const b = await createBackup({
  source: { dialect: 'sqljs', uri: './data.sqlite', schemas },
  extras: { config, files: [{ path: 'licence.json', content }] },
  siteId: 'yalidine-01',
  signingKey: notre.privateKey, signingPublicKey: notre.publicKey,  // QUI l'a produite
  recipients: [client.publicKey, secours.publicKey],                // POUR QUI elle est lisible
});
await storeBackup(driver, 'sauvegardes', b);

Scellée pour le client, le prestataire ne peut pas l'ouvrir. On vend la conservation et la restauration sans jamais détenir les secrets. Une compromission de la console n'expose rien. Une clé de secours hors ligne, ajoutée comme second destinataire, atténue le « clé perdue = tout perdu ».

Un backup jamais restauré n'est pas un backup

C'est la panne la plus banale du métier : on sauvegarde deux ans, et le jour J l'archive est inutilisable.

const r = await testRestore(b.buffer, { schemas });   // base JETABLE + RECOMPTAGE
r.verifie  // true si les entités relues correspondent aux compteurs du manifeste

restoreBackup est en simulation par défaut — une restauration est destructrice, elle ne part jamais sans un choix explicite — et se termine par un recomptage : une restauration qu'on ne recompte pas n'est pas vérifiée, on a seulement déclaré « restauré ».

Et un recomptage juste ne prouve pas un contenu juste (0.5.0). Chaque entité porte au manifeste une empreinte de son contenu — SHA-256 des lignes sous forme canonique, triées par identifiant. La restauration la recalcule sur ce qu'elle relit ; un écart passe verifie à false et nomme la ligne et le champ (ligne p1 : createdAt "2020-…" → "2026-…"). La forme canonique suit le type déclaré au schéma : une date, un booléen ou un nombre relus différemment par un autre moteur restent le même contenu — une sauvegarde sqlite se teste dans sql.js sans fausse alerte. Une archive antérieure, sans empreinte, se restaure encore, avec contenu: 'non-disponible' et un avertissement.

Le garde-fou qui a été gagné à la dure

Un schéma sans collection fait écrire toutes les entités dans la même table, en silence (l'ORM en dérive le nom de table). Rencontré ici même : Ticket(12) + Counter(2) relisaient 14 lignes chacun, contenus mélangés. Corrigé en amont (@mostajs/orm 2.11.1 le rejette désormais, orm-copy-data 0.4.0 l'appelle), et refusé ici aussi — défense en profondeur.

Tests

npm test   # 13 tests, sur une VRAIE base sqljs

Une vraie base est peuplée, sauvegardée, signée, scellée, vérifiée, restaurée dans une base jetable — et les entités sont recomptées. Un module de sauvegarde qui ne restaure jamais rien n'est pas testé.