# Des sauvegardes depuis la CI

> Une archive nocturne vers votre bucket depuis un workflow, avec les secrets du runner et aucun fichier à versionner. Comment le construire avec s3nd, à quoi faire attention, et le guide complet.

Canonical: https://s3nd.sh/fr/use-cases/ci-backups · Markdown: https://s3nd.sh/fr/use-cases/ci-backups.md · English: https://s3nd.sh/use-cases/ci-backups

Une archive nocturne vers votre bucket depuis un workflow, avec les secrets du runner et aucun fichier à versionner.

```yaml
- run: tar cz ./data | npx @s3nd/cli put - --name backup.tar.gz --expires-in never
  env:
    S3ND_BUCKET: transfers
    S3ND_PREFIX: backups
    S3ND_ENDPOINT: https://${{ secrets.R2_ACCOUNT_ID }}.r2.cloudflarestorage.com
    S3ND_REGION: auto
    AWS_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}
```

## Ce qui se passe vraiment.
### Le problème
Un workflow produit quelque chose qui vaut la peine d’être gardé : un dump de base de données, un build, un rapport généré. Il doit atterrir dans votre bucket chaque nuit, sans fichier de configuration dans le dépôt et sans bibliothèque cliente dans le workflow.

### Ce que s3nd y fait
npx @s3nd/cli put, avec le bucket et les identifiants dans des variables d’environnement issues du coffre de secrets du runner. Deux flags transforment un transfert en sauvegarde : --expires-in never, et un préfixe à part pour que la règle de cycle de vie des transferts ne puisse pas l’atteindre.

## Les choses faciles à rater.
- **--json pour les logs** — Une sortie lisible par une machine, et s3nd doctor --json sort avec un code non nul quand une vérification échoue, donc il sert aussi de smoke test de déploiement.
- **Un préfixe par politique** — Les transferts expirent, les sauvegardes non. Les garder sous des préfixes différents est ce qui permet à un seul bucket de contenir les deux.

Packages: @s3nd/cli. [La référence de la CLI](https://doc.s3nd.sh/docs/cli)