Build
Formation · le faire tourner sans toi

Les sauvegardes qu'on ne regrette pas.

Tout le monde a une sauvegarde. Presque personne n'a une restauration. La différence se découvre le pire jour et elle tient à un essai de trois minutes que tu peux faire aujourd'hui. Voilà les quatre moments où il faut sauvegarder, la façon d'écrire qui ne perd rien et l'essai.

Les quatre moments, l'écriture qui ne casse pas un fichier à mi-chemin, la rotation, l'essai de restauration fait le 03/09 sur 240 fiches clients et ce qu'une sauvegarde ne protège pas.
La leçon d'avantLe tri du matin de ta boîte mail→

Avant tout : la seule question qui compte

Ce n'est pas « est-ce que je sauvegarde ? ». C'est « quand ai-je restauré pour la dernière fois ? ». Une sauvegarde jamais restaurée est un fichier dont tu ne sais rien : il peut être vide, tronqué, ou dans un format que plus rien ne relit.

Les donnéesqui comptentUne copiedatéeAilleursque sur le disqueRestauréeune fois
Les trois premiers points, tout le monde les a. Le quatrième fait la différence.

Sauvegarde ce qui ne se recrée pas : le programme est dans git, il revient, mais tes clients, tes commandes et tes photos ne reviennent pas.

01

Les quatre moments où il faut sauvegarder

Tout le monde pense au premier. Ce sont les trois autres qui sauvent vraiment :

Le momentPourquoiQui le déclenche
Tous les jours, la nuitLe socle. Une journée perdue au pireUne tâche planifiée
Avant chaque mise en ligneC'est le moment où on casseLe script de déploiement
Avant tout changement de structure (la forme de la base : ses colonnes, ses tableaux, pas son contenu)Une colonne ajoutée de travers et c'est finiLe programme lui-même
Avant toute opération à la mainSurtout à 23 hToi et c'est le plus dur

Sur le serveur de Build, le troisième est automatique et ne dépend de personne. La fonction qui met la base à jour commence par se sauvegarder elle-même, avant de toucher quoi que ce soit. Le déploiement l'appelle à chaque envoi. Exemple Build, rien à coller : c'est le code du serveur de Build, montré pour l'idée.

Ce que tu obtiens
def initialiser():
    sauvegarde()          # d'abord la copie datée
    co = connexion()      # ensuite seulement le changement
    co.executescript(SCHEMA)

Pas besoin de lire le Python : SCHEMA est le schéma, la description de la structure de la base. La première ligne copie, la dernière change.

C'est la meilleure ligne de ce module. Une sauvegarde qui dépend de ta discipline finit par ne pas se faire. Une sauvegarde posée dans le chemin obligatoire du changement se fait toujours, y compris le jour où tu es pressé.

À écrire dans Claude Code
Avant toute opération qui change la structure de la base, fais une
copie datée. Mets l'appel dans la fonction qui applique les
changements, pas dans le script de déploiement, pour qu'on ne puisse
pas l'oublier.
Premium

La suite est dans la formation.

Tu viens de lire la première partie. Il en reste 4, avec les commandes exactes et les pièges à chaque étape :

  1. Écrire sans jamais casser le fichier en cours de route
  2. La rotation, pour ne pas remplir le disque
  3. L'essai de restauration, en trois minutes
  4. Ce qu'une sauvegarde ne protège pas

29 € une seule fois, accès à vie. 29 € pour les 50 premiers membres, il en reste 35. Ensuite 49 €.

Prendre l'accès à vie