Sauvegardes testées

Ce que votre agent écrit

Votre agent l’écrit dans while.yaml, à la racine de votre appli :

databases:
  - name: main
    backup: { schedule: "0 3 * * *", test_restore: true }

Quand vous en servir

Elles sont toujours là pour une base, sans rien déclarer : revenez à une sauvegarde ou à un instant précis, sur 14 jours.

Comment ça marche

Chaque base est sauvegardée en continu et chaque jour, hors du cluster, et la sauvegarde du jour d’une base de production est testée par une vraie restauration. Votre agent remet une base à une sauvegarde ou à un instant précis des 14 derniers jours.

Ce qu’il faut savoir

Chaque base archive son journal (WAL) en continu et fait une sauvegarde complète par jour, chiffrée, hors du cluster. schedule fixe l’heure de cette sauvegarde, en UTC. Les sauvegardes sont gardées 14 jours, pour toutes les bases : retention_days est lu, mais pas suivi.

La sauvegarde du jour d’une base de production, et toute sauvegarde lancée par l’outil backup_database, est suivie d’un test : une base jetable naît d’elle, et ses tables sont relues. Le résultat est affiché, jamais supposé.

restore_backup, validé par une personne, remet une base à une sauvegarde, ou à un instant précis de ces 14 jours, à partir de la dernière sauvegarde terminée avant cet instant. La base restaurée naît neuve, et prend la place de l’ancienne après une sauvegarde de sûreté. Les sauvegardes ont une seule copie, dans une seule région.

Prix

Ces prix sont les mêmes dans toutes les offres, hors taxes :

Les outils MCP de votre agent

Votre agent s’en occupe avec les outils get_environment, backup_database et restore_backup.

Guides

• Remettre votre base PostgreSQL à un instant précis, ou depuis un pg_dump, depuis votre agent IA