Sauvegarder et restaurer l'instance

Ce que fait la sauvegarde de la plateforme

La base de données de l'instance contient les clés des dépôts de sauvegarde. Sans cette base et sans copie de cette base, personne ne lit les sauvegardes de vos clients. Voir Séquestre des clés.

L'instance se sauvegarde elle-même. Une fois par jour, elle écrit une archive chiffrée dans un bucket S3 que vous réglez. Chaque archive contient :

Contenu	Détail
La base de données	Une copie complète, avec les tables du produit et le schéma Microsoft 365 et son index de recherche.
Les réglages et les secrets	Le fichier `.env`, et les secrets qu'une remise en service ne peut pas recréer : la clé de la vérification en deux étapes, la clé des liens des emails, la clé des mots de passe des partages réseau, l'URL SMTP, le certificat de l'autorité racine, la clé du relais Microsoft 365, la clé des notifications push, la clé des mots de passe SQL Server et la clé de l'identité de l'instance.
Le séquestre des clés	Les clés de tous les dépôts, scellées avec la phrase secrète de la sauvegarde.
Un manifeste	Les versions, les tailles et l'empreinte SHA-256 de chaque fichier.

Chaque archive porte toutes les données de la plateforme. Une seule archive suffit pour remettre l'instance en service.

Cette sauvegarde ne contient pas les données de sauvegarde de vos clients. Ces données restent dans votre stockage S3.

La sauvegarde est active dès l'installation. Tant que vous n'avez pas réglé le bucket de sauvegarde, le portail avertit les administrateurs de la plateforme.

Prérequis

Un accès root sur l'hôte, ou un compte membre du groupe docker, dans le dossier de déploiement de l'instance.
Un second bucket S3, sur un autre compte ou un autre fournisseur que le stockage de vos clients.
Une clé d'accès S3 en écriture seule pour ce bucket.
La phrase secrète de la sauvegarde, dans le fichier secrets/backup-passphrase. L'installation l'a créée. Voir Installer l'instance.
Le rôle Administrateur plateforme pour lire l'état dans le portail. Voir Rôles et droits.

Règles du bucket de sauvegarde

Suivez ces quatre règles. À chaque sauvegarde, l'instance contrôle le bucket et le portail signale les écarts. Un contrôle que la clé d'accès en écriture seule ne peut pas faire ne donne aucun message.

Utilisez un autre compte S3 que celui du stockage de vos clients, et si possible un autre fournisseur. Le portail avertit quand le bucket de sauvegarde est sur le même point d'accès S3 que le stockage de vos clients. Ce contrôle compare les noms d'hôte seulement : il ne voit pas un même compte derrière un autre point d'accès.
Donnez à la clé d'accès le droit d'écrire seulement. Elle a besoin de PutObject, PutObjectRetention, AbortMultipartUpload et ListMultipartUploadParts sur les objets, et de GetBucketObjectLockConfiguration et GetLifecycleConfiguration sur le bucket. Ne donnez ni la lecture, ni la liste, ni la suppression. Le portail avertit quand la clé peut lister le bucket.
Créez le bucket avec Object Lock quand votre fournisseur le propose. L'instance donne alors à chaque archive une date de rétention de BACKUP_RETENTION_DAYS jours, en mode GOVERNANCE. Personne ne supprime ni ne remplace une archive avant cette date avec la clé de sauvegarde.
Ajoutez une règle de cycle de vie qui supprime les archives après BACKUP_RETENTION_DAYS jours. L'instance ne supprime jamais une archive. Le portail avertit quand le bucket n'a ni Object Lock ni règle de cycle de vie.

Les archives prennent ce nom : <BACKUP_S3_PREFIX><identifiant de l'instance>/<AAAA-MM-JJ>/baastide-backup-<heure>-<identifiant de la sauvegarde>.bbk.

1. Régler le bucket de sauvegarde

Ouvrez une session sur l'hôte, dans le dossier de déploiement de l'instance.

Ouvrez .env et réglez ces valeurs :

Valeur	Ce qu'elle contient
`BACKUP_S3_ENDPOINT`	L'adresse du point d'accès S3 du bucket de sauvegarde.
`BACKUP_S3_REGION`	La région de ce bucket.
`BACKUP_S3_BUCKET`	Le nom de ce bucket.
`BACKUP_S3_ACCESS_KEY_ID`	L'identifiant de la clé d'accès en écriture seule.

Le fichier .env.example donne les autres valeurs BACKUP_*, toutes optionnelles : BACKUP_S3_PREFIX, BACKUP_INTERVAL_HOURS (défaut 24, de 1 à 24), BACKUP_MAX_AGE_HOURS (défaut 36), BACKUP_RETENTION_DAYS (défaut 30) et BACKUP_ENABLED (défaut true).

Saisissez la clé secrète de la clé d'accès, puis redémarrez les services concernés :

chmod u+w secrets/backup-s3-secret-key
read -rsp 'Cle secrete S3 de sauvegarde : ' BACKUP_S3_SECRET_KEY && printf '%s' "$BACKUP_S3_SECRET_KEY" > secrets/backup-s3-secret-key && unset BACKUP_S3_SECRET_KEY && echo
chmod 0444 secrets/backup-s3-secret-key
docker compose up -d --wait worker api

Vérifiez les droits de .env. L'instance lit ce fichier pour le mettre dans l'archive. Quand .env n'est lisible que par root, la sauvegarde échoue avec le message EACCES ... /backup/env. Corrigez les droits :
```
chown root:1000 .env && chmod 0640 .env
```

La première sauvegarde démarre quelques minutes après le redémarrage, puis une sauvegarde part toutes les BACKUP_INTERVAL_HOURS heures. Quand un nouveau dépôt est créé, parce que vous avez ajouté un endpoint, une sauvegarde qui porte sa clé part dans les 15 minutes. L'instance laisse au moins 10 minutes entre la fin d'une sauvegarde et le début de la suivante. Après un échec, elle réessaie une heure plus tard, ou 10 minutes plus tard quand la clé d'un dépôt n'est encore dans aucune sauvegarde.

2. Lancer une sauvegarde maintenant

Cette commande ne tient pas compte de l'intervalle. Elle attend la fin de la sauvegarde et donne son résultat.

Ouvrez une session sur l'hôte, dans le dossier de déploiement de l'instance.

Lancez la commande :

docker compose exec -T worker baastide-admin backup-run

Lancez-la après le réglage du bucket, pour contrôler le bucket et la clé d'accès sans attendre.

3. Lire l'état de la sauvegarde

Ouvrez le portail avec un compte Administrateur plateforme.
Dans le menu Plateforme, cliquez Vue d'ensemble.
Lisez la carte Sauvegarde de la plateforme. Elle porte l'état À jour ou En danger, et la date de la dernière sauvegarde réussie.
Lisez le bloc Contrôles du bucket de sauvegarde. Il écrit « Le bucket de sauvegarde suit la configuration recommandée », ou la liste des écarts.

Le portail affiche un bandeau aux administrateurs de la plateforme dans ces cas :

Cas	Ce qu'il faut faire
Aucun bucket de sauvegarde n'est réglé.	Suivez la procédure 1.
La plateforme n'a encore jamais été sauvegardée.	Attendez quelques minutes, ou lancez la procédure 2.
La dernière sauvegarde a échoué.	Lisez les journaux du service `worker`, corrigez la cause, puis lancez la procédure 2.
La dernière sauvegarde réussie a plus de `BACKUP_MAX_AGE_HOURS` heures.	Vérifiez que le service `worker` tourne et que le bucket accepte les écritures.

Les écarts du bucket portent ces phrases :

Phrase	Ce qu'il faut faire
« Le bucket de sauvegarde n'a pas d'Object Lock. »	Créez un bucket avec Object Lock quand votre fournisseur le propose.
« Le bucket de sauvegarde n'a pas de règle de cycle de vie. »	Ajoutez une règle de cycle de vie, ou créez un bucket avec Object Lock. Voir la règle 4 plus haut.
« Les identifiants de sauvegarde peuvent lister le bucket. »	Donnez une clé d'accès en écriture seule.
« Le bucket de sauvegarde est sur le même endpoint S3 que les données des clients. »	Utilisez un autre compte ou un autre fournisseur.

La sauvegarde de la plateforme compte aussi comme une copie des clés des dépôts. La carte Séquestre des clés de la même page montre cette copie. Voir Séquestre des clés.

4. Sauvegarder à la main

Faites cette sauvegarde avant chaque mise à jour de l'instance, et quand vous ne pouvez pas utiliser de bucket de sauvegarde.

Ouvrez une session sur l'hôte, dans le dossier de déploiement de l'instance.

Copiez la base de données, les réglages et les deux clés des volumes :

umask 077
docker compose exec -T postgres pg_dump -U baastide -d baastide --format=custom > "baastide-db-$(date +%F).dump"
docker compose exec -T api cat /run/secrets/mssql/key > mssql-key
docker compose exec -T api cat /run/secrets/license/key > license-key
tar -czf "baastide-config-$(date +%F).tar.gz" .env secrets instance-id mssql-key license-key
rm mssql-key license-key

Ajoutez le dernier export hors ligne des clés des dépôts. Voir Séquestre des clés.
Copiez les deux fichiers hors de l'hôte, et chiffrez-les.

Ces fichiers portent des secrets. La copie de la base contient les clés des dépôts.

Sans la clé des mots de passe des partages réseau, vous saisissez à nouveau le mot de passe de chaque partage. Sans la clé des mots de passe SQL Server, vous saisissez à nouveau le mot de passe de chaque instance SQL Server. Sans la clé de la vérification en deux étapes, personne ne se connecte plus avec la vérification en deux étapes. Sans la clé de l'identité de l'instance, l'instance n'importe plus de licence tant que BaaStide ne la lie pas à une nouvelle clé.

5. Remettre l'instance sur un nouvel hôte

Suivez cette procédure quand l'hôte est perdu. Préparez le nouvel hôte comme le premier. Voir Avant d'installer une instance.

Récupérez l'archive dans le bucket, avec une clé d'accès qui peut lire, et la phrase secrète de la sauvegarde.

Déchiffrez l'archive, puis vérifiez son contenu. La commande n'écrit le fichier tar que si l'archive est complète et n'a pas changé.

umask 077
printf '%s\n' "$BACKUP_PASSPHRASE" |
  docker run --rm -i --network none -u "$(id -u):$(id -g)" -v "$PWD:/work" -w /work --entrypoint baastide-admin \
    "$BAASTIDE_REGISTRY/baastide-backend:$BAASTIDE_VERSION" backup-decrypt baastide-backup.bbk --out baastide-backup.tar
mkdir restore && tar -xf baastide-backup.tar -C restore && (cd restore && sha256sum -c SHA256SUMS)

Installez le bundle de la même version que l'archive. Suivez Installer l'instance jusqu'au certificat, mais prenez restore/secrets/env comme .env et les fichiers de restore/secrets/secrets/ comme contenu de secrets/.

Recréez les secrets qui ne sont pas dans l'archive :

Fichier	Ce qu'il faut faire
`backup-passphrase`	Remettez la phrase secrète de votre gestionnaire de mots de passe.
`postgres-owner-password`	Créez-en un nouveau. Les services créent une nouvelle base de données : l'ancien mot de passe ne sert plus.
`s3-secret-key`	Saisissez à nouveau la clé secrète du stockage de vos clients.
`tls.pem`	Remettez votre certificat et sa clé privée, ou émettez un nouveau certificat de la même autorité racine que `control-ca.pem`.
`backup-s3-secret-key`	Saisissez à nouveau la clé secrète du bucket de sauvegarde, ou laissez le fichier vide.
`pool-root-s3`	Saisissez à nouveau la clé de la racine des buckets, ou laissez le fichier vide.
`m365-s3-secret-key`	Saisissez à nouveau la clé secrète du bucket Microsoft 365, ou laissez le fichier vide.

[ -e secrets/postgres-owner-password ] || openssl rand -hex 32 | tr -d '\n' > secrets/postgres-owner-password
for f in backup-s3-secret-key pool-root-s3 m365-s3-secret-key; do [ -e "secrets/$f" ] || : > "secrets/$f"; done

Remettez la clé des mots de passe SQL Server et la clé de l'identité de l'instance avant le premier démarrage. Le premier démarrage crée de nouvelles clés quand les volumes sont vides. Démarrez les services, arrêtez les rôles, remettez la base de données, puis démarrez de nouveau.

chmod 0444 secrets/*
docker compose run --rm -T --entrypoint /bin/sh mssql-key-init -c 'umask 077 && cat > /mssql/key' < restore/secrets/mssql/key
docker compose run --rm -T --entrypoint /bin/sh license-key-init -c 'umask 077 && cat > /license/key' < restore/secrets/license/key
docker compose up -d --wait
docker compose stop api gateway worker scheduler
docker compose exec -T postgres pg_restore -U baastide -d baastide --clean --if-exists < restore/db/baastide.dump
docker compose up -d --wait

Connectez-vous au portail et vérifiez le parc. Voir Parc et arborescence.

Avec une sauvegarde à la main, les étapes sont les mêmes. Installez le bundle avec le .env et le dossier secrets/ de votre archive baastide-config-*.tar.gz, remettez mssql-key et license-key dans leurs volumes, puis remettez la copie baastide-db-*.dump avec pg_restore.

L'archive porte aussi le séquestre des clés, dans restore/keys/baastide-keys.bkx. Ce fichier s'ouvre sans la base de données, avec la phrase secrète de la sauvegarde. Voir Séquestre des clés.

Limites et précautions

Sans la phrase secrète de secrets/backup-passphrase, personne n'ouvre les archives ni le séquestre des clés qu'elles portent. La phrase secrète n'est jamais dans une archive. Gardez-la dans un gestionnaire de mots de passe, hors de l'hôte.
L'archive ne porte pas ces secrets : la phrase secrète de la sauvegarde, le mot de passe du compte propriétaire de la base de données, la clé secrète du stockage de vos clients, le certificat de l'instance et sa clé privée, la clé secrète du bucket de sauvegarde, la clé de la racine des buckets et la clé secrète du bucket Microsoft 365. Préparez-les avant une remise en service.
Remettez l'instance avec le bundle de la même version que l'archive. Mettez l'instance à jour après, pas pendant. Voir Mettre à jour l'instance.
L'instance ne supprime jamais une archive. Sans règle de cycle de vie, les archives s'accumulent.
BACKUP_ENABLED=false arrête la sauvegarde automatique. Ce réglage n'est pas recommandé.
Une licence d'essai a besoin de la clé de la racine des buckets. Cette clé n'est pas dans l'archive : saisissez-la à nouveau après une remise en service. Voir Importer une licence.
La sauvegarde de la plateforme ne remplace pas vos tests de restauration. Voir Tester ses restaurations.

Ce que fait la sauvegarde de la plateforme​

Prérequis​

Règles du bucket de sauvegarde​

1. Régler le bucket de sauvegarde​

2. Lancer une sauvegarde maintenant​

3. Lire l'état de la sauvegarde​

4. Sauvegarder à la main​

5. Remettre l'instance sur un nouvel hôte​

Limites et précautions​