Backups et restauration

L'unité de backup de Tale est le snapshot de volume : un tar checksummé, pris à containers en pause, des volumes de données principaux de l'instance, écrit dans un volume backups dédié qui vit à côté des données qu'il protège. La CLI en prend un automatiquement avant toute étape de déploiement qui peut migrer des données, et tale backup en prend un à la demande. La récupération, c'est tale restore <snapshot-id> plus un redéploiement de la version correspondante — cette paire est la réponse à une montée de version échouée, et la raison pour laquelle tale rollback peut se permettre de refuser tout ce qui dépasse un pas de patch.

Le contexte d'architecture vit dans Architecture des conteneurs ; cette page couvre ce qu'un snapshot contient, quand il est pris, comment la copie quitte l'hôte et le walk de restauration.

Ce qu'un snapshot contient

Chaque snapshot est un répertoire nommé comme 20260611-142530-deploy dans le volume backups du projet : un .tar.gz par volume, un sidecar .sha256 chacun et un manifest.json écrit en dernier. Un répertoire sans manifest est un snapshot incomplet — il n'apparaît jamais dans les listings, ne peut jamais être restauré, et la rotation le supprime au prochain tale deploy ou tale backup dès qu'un snapshot complet plus récent existe. Deux choses vivent entièrement hors des volumes et demandent leur propre place dans ton job hors-hôte : le workspace du projet (le répertoire qui contient tale.json) et .env.

Les blobs suivent le magasin d'objets. Avec le service object-store fourni — le défaut — le snapshot capture object-store-data comme n'importe quel autre volume, et son archive pèse autant que tout ce qui a jamais été téléversé : le store est en pause pendant le tar, donc les téléversements et les téléchargements restent bloqués aussi longtemps. Deux cas placent des blobs hors du snapshot, et le backup les annonce tous les deux au lieu de les passer sous silence. Un défaut du déploiement repointé vers un S3 externe (default/object-storage/connection.json ne nomme plus le store fourni) ne laisse dans le volume local rien que l'app lise : le backup saute le volume et tale backup imprime une notice d'une ligne avec l'endpoint et le bucket — la sauvegarde de ce bucket relève de ton propre outillage S3. Une organisation qui apporte son propre bucket sous Paramètres > Résidence des données n'écrit jamais non plus dans le volume local ; la notice nomme l'organisation, et aucun snapshot ne peut contenir ces blobs.

Quand les snapshots sont pris

tale deploy snapshotte avant sa première étape mutante dès que le déploiement peut changer des données : la version cible diffère de celle qui tourne, ou un push de config hôte (--override / --override-all) est demandé. Pendant que chaque volume est mis en tar, les conteneurs qui l'utilisent sont mis en pause pour toute la durée — quelques secondes pour les volumes de base et de config, aussi longtemps que le store est gros pour le volume de blobs — pour que l'archive soit cohérente après crash : une copie à chaud d'un répertoire Postgres en marche n'est pas restaurable.

Un snapshot échoué interrompt le déploiement. --skip-backup outrepasse cela sur tale deploy — tes propres backups externes deviennent alors le seul chemin de récupération, et c'est exactement pour ça que le flag logge un avertissement bien visible.

# Prendre un snapshot tout de suite
tale backup

Rétention

La rotation garde les cinq snapshots les plus récents et tout ce qui date des 14 derniers jours — selon ce qui est le plus généreux. Un snapshot n'est supprimé que s'il est à la fois au-delà de la fenêtre de compte et plus vieux que la fenêtre d'âge ; une instance calme garde donc ses derniers snapshots indéfiniment. Ajuste les fenêtres avec BACKUP_KEEP_COUNT et BACKUP_KEEP_DAYS dans .env.

Copie hors-hôte

Les snapshots vivent sur le même hôte que les données qu'ils protègent — un disque mort emporte les deux. Pointe ton outillage de backup existant (Restic, Borg, Velero, snapshots de cloud provider) sur le volume backups, et capture le workspace du projet et .env dans le même job. Tale n'embarque pas d'étape d'upload — garder la copie hors-hôte sous ton contrat de backup existant est délibéré.

# crontab sur l'hôte — copie Restic horaire du volume backups vers S3
0 * * * * restic -r s3:s3.amazonaws.com/bucket/tale backup \
  /var/lib/docker/volumes/<project-id>_backups/_data

Trouve le chemin hôte du volume avec docker volume inspect <project-id>_backups ; l'id du projet vit dans tale.json.

Restaurer un snapshot

tale restore sans argument liste ce qui est disponible ; avec un id, il vérifie les checksums, vide les volumes de données et extrait le snapshot. Il refuse tant qu'un conteneur du projet tourne — passe --stop pour les arrêter — et demande confirmation avant de toucher à quoi que ce soit.

# Voir ce qui est disponible
tale restore

# Arrêter le stack et restaurer
tale restore 20260611-142530-deploy --stop

# Remonter le stack sur la version qui correspond aux données
tale update --version 0.9.6
tale deploy --stop

Le redéploiement de la version correspondante fait partie de la restauration, ce n'est pas un extra optionnel : le snapshot a capturé les données exactement comme cette version de la plateforme les a laissées, et un binaire plus récent relancerait immédiatement ses migrations dessus. La sortie de la restauration imprime la version exacte enregistrée dans le manifest du snapshot.

Un snapshot pris avant que les blobs soient capturés, ou sur un déploiement dont les blobs vivent dans un S3 externe, n'a pas d'archive object-store-data. tale restore liste ces snapshots comme without blobs, le redit avant de demander confirmation et laisse le volume de blobs intact pendant qu'il restaure tout le reste — les blobs restent exactement tels qu'ils sont sur l'hôte.

Drill de restauration

Fais tourner le drill trimestriellement sur un hôte non-production. Le drill n'est pas « un snapshot existe-t-il » — c'est « un hôte frais peut-il être reconstruit depuis la copie hors-hôte du volume backups, le workspace du projet et .env en moins d'une heure ». Les modes d'échec que le drill attrape : un job hors-hôte qui n'a jamais capturé le workspace, et un .env périmé qui ne correspond plus aux exigences du binaire courant.

Où cela s'inscrit

Les snapshots sont la partie bon marché ; le drill de restauration est ce qui prouve qu'ils marchent, et la règle redéployer-la-version-correspondante est la seule chose à retenir — la récupération n'est jamais « faire reculer le binaire », c'est « restaurer les données et déployer la version à laquelle elles appartiennent ». Le flow de montée de version que ces snapshots protègent vit dans Montées de version ; la checklist de durcissement qui nomme les backups comme une ligne est dans Durcissement.