Sauvegarde continue et restauration à l'instant près
Kuploy protège en continu les bases de données qui sous-tendent votre déploiement — la messagerie, les données de la plateforme et les services annexes — en diffusant chaque modification, au fil de l'eau, vers un stockage objet chiffré et délocalisé. C'est de la sauvegarde continue, avec restauration à l'instant près (PITR) : au lieu de quelques copies nocturnes, vous disposez d'une chronologie de récupération que vous pouvez rembobiner jusqu'à n'importe quel moment de votre fenêtre de conservation.
Cette page traite de la protection continue des bases de données de la plateforme. L'outil distinct de Sauvegarde et restauration crée, lui, des archives ponctuelles de l'application kuploy elle-même. Les deux se complètent ; c'est celui-ci qui protège, minute après minute, les données vivantes comme les boîtes aux lettres.
Comment cela fonctionne
- En continu : le journal des écritures de la base est archivé hors site en quelques minutes à chaque modification. Votre exposition à la perte de données se mesure en minutes, et non en « depuis la sauvegarde de cette nuit ».
- Par catégorie : les sauvegardes sont organisées selon ce qu'elles protègent — Email (boîtes aux lettres, webmail), Platform (organisations, utilisateurs, projets) et Infrastructure (les services annexes). Chaque catégorie a son propre flux de sauvegarde, sa conservation et sa chronologie de récupération.
- Hors site : les sauvegardes résident dans un stockage objet extérieur à votre cluster — un autre prestataire et un autre domaine de panne que les machines qu'elles protègent. Perdre le cluster ne fait pas perdre les sauvegardes.
- Sous surveillance : la santé et la fraîcheur des sauvegardes font partie des alertes de panne de votre instance. Si l'archivage s'arrête, ou si la dernière sauvegarde vieillit trop, les responsables en sont avertis — vous ne découvrez jamais un trou dans vos sauvegardes au moment d'une restauration.
La page de licence de votre instance, sur kuploy.app, affiche un bandeau d'état par catégorie : la santé, l'activation des sauvegardes, la conservation, l'âge de la dernière sauvegarde et sa destination.
Ce que la restauration à l'instant près vous apporte
Le scénario qui compte : quelqu'un supprime une boîte aux lettres à 14 h 07. Avec la PITR, vous restaurez la seule catégorie Email à 14 h 02 — cinq minutes avant la bévue — tandis que vos organisations, vos projets et votre facturation continuent de tourner, intacts.
Comme chaque catégorie a sa propre chronologie, la récupération est chirurgicale : le rayon d'action d'une restauration, c'est une catégorie, jamais toute votre plateforme.
Pourquoi ne pas se contenter d'instantanés de machines virtuelles ?
Beaucoup d'équipes supposent que les instantanés de VM ou d'hyperviseur rendent les sauvegardes de bases de données inutiles. Il n'en est rien : les deux résolvent des problèmes différents, et sur des données vivantes, les instantanés se révèlent insuffisants d'une manière qui n'apparaît que le pire des jours :
- Tout rembobine ensemble. Restaurer un instantané de VM ramène la machine entière — chaque base, chaque application, chaque locataire qui s'y trouve — au moment où l'instantané a été pris. La PITR restaure une catégorie à un instant choisi.
- Vous ne pouvez revenir qu'aux instants où un instantané existe. Si le plus récent date de la semaine dernière, la semaine dernière est votre seule option. Une chronologie continue vous laisse choisir la minute.
- Les instantanés sont cohérents au plantage, pas cohérents pour une base. Un instantané d'une base chargée la saisit en pleine écriture ; la récupération fonctionnera peut-être, peut-être pas. La récupération par journal des écritures est la manière dont les bases sont conçues pour être restaurées.
- Le même domaine de panne. Les instantanés résident le plus souvent sur le même stockage que les machines qu'ils protègent. Un stockage objet hors site survit à la perte du site entier.
- Les chaînes d'instantanés dégradent l'hôte. Les longues chaînes d'instantanés d'hyperviseur sont une cause bien documentée de problèmes de performance des VM. Les éditeurs d'hyperviseurs disent eux-mêmes qu'un instantané n'est pas une sauvegarde.
- Répétée, et non espérée. Chaque forme de récupération de kuploy est testée en restauration, dans le cadre des exercices de la plateforme elle-même. Demandez-vous à quand remonte la dernière répétition de bout en bout de votre restauration d'instantané de VM.
Les instantanés de VM gardent leur utilité, pour ce à quoi ils servent : un point de retour rapide avant une opération de maintenance sur l'hôte. Pour vos données, utilisez une véritable chronologie de récupération.
Restaurer
Les plans de restauration sont produits depuis la page de licence de votre instance sur kuploy.app (Restore…, sur le panneau de santé de l'instance, offre Enterprise) : choisissez une catégorie et un instant cible, et kuploy élabore un plan de récupération détaillé et éprouvé, que votre exploitant applique. Produire un plan ne touche jamais à votre plateforme en service — l'appliquer est toujours un acte délibéré de l'exploitant.
Si vous n'êtes pas sur l'offre Enterprise, vos sauvegardes sont tout de même prises et surveillées ; la récupération est alors une opération manuelle, pour l'exploitant de votre plateforme.
La conservation
Chaque catégorie conserve sa chronologie de récupération pendant une fenêtre configurée — 7 jours, le plus souvent ; les données de sauvegarde plus anciennes sont élaguées automatiquement. Au sein de la fenêtre, tout instant est récupérable. Parlez-en à l'exploitant de votre plateforme si vos obligations de conformité appellent une fenêtre plus longue.