Sauvegardes

Une sauvegarde est ce qu’il faut pour refaire un serveur Pupitre ailleurs, ou le remettre dans l’état d’hier. L’agent la fabrique, la chiffre, et l’envoie vers un bucket qui est le vôtre. Pupitre n’en garde que l’adresse et un résumé.

Ce qu’une sauvegarde contient

• La configuration et les secrets des modules — le catalogue, ses réglages, et les tokens et mots de passe que garde chaque module.
• Les bases — un dump par base, les rôles PostgreSQL, et le snapshot Redis.
• Les projets tels qu’ils sont — le dossier entier, .git compris, avec le travail non commité.
• Le compte dev — ses clés SSH et ses sessions d’agents de code.
• Des dossiers supplémentaires que vous nommez sous /home/dev.

Ce qu’elle ne contient pas

Les binaires, les runtimes et les dépendances des projets — réinstallés, jamais restaurés, comme ceux que Claude télécharge sous ~/.claude/remote. Les volumes Docker. Les clés d’hôte et authorized_keys : un serveur restauré est une machine différente, avec sa propre identité.

Le coût

Une sauvegarde est stockée dans votre propre bucket ; Pupitre n’en garde qu’une référence, jamais son contenu. Sur Cloudflare R2, l’offre gratuite actuellement publiée couvre 10 Go-mois de stockage et ne facture pas l’egress — ce que vous payez dépend de la taille de votre bucket et des tarifs publiés par votre fournisseur.

Configurer Cloudflare R2

1. Créez un bucket dans le tableau de bord Cloudflare.
2. Allez dans R2 › Manage API tokens et créez un token limité à Object Read & Write, restreint à ce bucket.
3. Notez l’Access Key ID, la Secret Access Key, et l’identifiant de votre compte, affiché sur la page d’accueil de R2 et dans l’endpoint S3 https://<compte>.r2.cloudflarestorage.com.
4. Dans l’app, ouvrez la page Sauvegardes du serveur : la mise en place demande d’abord le bucket — choisissez Cloudflare R2, puis donnez l’identifiant du compte, le nom du bucket et la clé — et le teste par une écriture d’essai avant de continuer. Cet ordinateur garde le bucket pour ses autres serveurs ; l’onglet Destination de la même page le change, et applique aussitôt le changement au serveur, clé secrète comprise.

Utiliser AWS S3 à la place

Créez un bucket et un utilisateur IAM avec une politique limitée à ce bucket :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::votre-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::votre-bucket/*"
    }
  ]
}

L’endpoint est https://s3.<région>.amazonaws.com. Tout autre fournisseur compatible S3 fonctionne de la même façon : un bucket, une clé restreinte à ce bucket, et son endpoint.

La passphrase

Vous choisissez une passphrase une fois, la tapez une fois, et elle est dérivée en clé de chiffrement sur votre laptop — jamais gardée, ni par l’app, ni par le serveur, ni par Pupitre. Les sauvegardes sont chiffrées sur le serveur pour la moitié publique de cette clé ; le serveur lui-même ne peut pas les lire.

La passphrase n’est redemandée que pour restaurer, et vous pouvez la taper depuis n’importe quel ordinateur. Perdue, les sauvegardes qu’elle protège deviennent illisibles, et personne — ni Pupitre, ni le support — ne peut la récupérer. Un second ordinateur de la même organisation reprend la clé existante et ne redemande pas la passphrase, sauf pour restaurer depuis lui.

Réglages

La première fois, la page Sauvegardes du serveur passe par quatre étapes : le bucket, la passphrase, la fréquence, le contenu ; Activer les sauvegardes les applique, et lance une première sauvegarde sauf si vous la décochez. Ensuite, la même page tient les réglages : la fréquence — toutes les heures, toutes les 6 ou 12 heures, chaque jour, chaque semaine, à la demande seulement, ou un autre intervalle —, l’heure où part une sauvegarde quotidienne ou hebdomadaire, le nombre de sauvegardes planifiées à garder, traduit en historique — les manuelles restent jusqu’à ce que vous les supprimiez —, et ce qu’il faut inclure. Sauvegarder maintenant en lance une tout de suite, et propose de lui donner un nom — « Avant la migration », par exemple — affiché à côté de sa date ; laissé vide, la date suffit. Ce nom est la seule chose que vous écrivez que la plateforme garde avec la référence.

Ce qu’il faut inclure se choisit élément par élément : chaque projet et chaque base du serveur sont listés avec une case, toutes cochées par défaut. Décochez une base que vous gardez déjà ailleurs, ou un projet dont vous n’aurez pas besoin ; un projet ou une base créés plus tard sont sauvegardés tant que vous ne les décochez pas. Un interrupteur coupe toute une catégorie.

Ce qu’une restauration fait d’un élément laissé dehors : sur un serveur neuf, un projet qui a un dépôt est cloné — son code revient, pas son travail en cours — et un projet sans dépôt est laissé de côté ; une base laissée dehors n’est pas créée. Sur un serveur qu’on remet à une sauvegarde, ce qui était laissé dehors reste tel quel.

Restaurer

Un serveur neuf ou réinstallé, pendant l’onboarding. Quand votre organisation a déjà des sauvegardes, l’app demande « Repartir d’une sauvegarde ? » avant même le catalogue.

Un serveur existant qu’on remet à une sauvegarde. L’app propose d’abord une sauvegarde de l’état actuel, pour qu’un retour en arrière puisse lui-même être annulé. Les modules que la sauvegarde choisie ne connaît pas peuvent être désinstallés ; les projets qu’elle ne connaît pas quittent la liste, mais leurs dossiers restent sur le disque.

Dans les deux cas, les projets que la sauvegarde décrit redémarrent une fois la restauration terminée.

Recommandation

Qui détient la clé S3 peut effacer ce qu’il y a dans le bucket. Activez le versioning ou l’Object Lock sur ce bucket, pour qu’une sauvegarde effacée ou écrasée reste là à récupérer.

Qui peut lire le bucket peut aussi lire le manifeste de chaque sauvegarde, qui n’est pas chiffré : le nom du serveur, les noms de ses projets, de ses bases et de ses dossiers, l’adresse et la branche de chaque dépôt. Rien de ce qu’ils contiennent — aucun fichier, aucune donnée, aucun secret — ne se lit sans votre passphrase. Gardez le bucket privé, ce que sont par défaut les buckets R2 et S3.

L’app n’accepte qu’un endpoint en https:// : en HTTP simple, la signature de chaque requête passerait en clair sur le réseau.

Ouvrir une sauvegarde sans Pupitre

pupitred backup open lit une sauvegarde seule, avec le fichier et la passphrase — pour le jour où vous voulez regarder dedans sans l’app.