Point-in-time recovery, pour les sites WordPress et WooCommerce, vous permet de reconstruire votre base de données telle qu'elle était à une minute précise, plutôt qu'uniquement au moment où la sauvegarde d'hier a été exécutée. Ce guide explique ce qu'il couvre et ce qu'il ne couvre pas, comment l'activer, comment demander une restauration, et exactement ce qu'une restauration touche.
À quoi cela sert
Une sauvegarde quotidienne vous donne un point de restauration par jour. C'est suffisant pour la plupart des sinistres, mais inutile pour ce cas précis où un mauvais import, une extension cassée ou une modification en masse erronée a eu lieu à 14h15 et que vous ne vous en êtes rendu compte qu'à 16h. Restaurer la sauvegarde d'hier jetterait tout le vrai travail de la matinée en même temps que l'erreur.
La récupération à un moment précis comble cet écart. Une fois activée, le journal des modifications de la base de données est envoyé en continu vers un stockage hors site, de sorte qu'une restauration peut être rejouée jusqu'à n'importe quelle minute à l'intérieur de la fenêtre de conservation.
La récupération à un moment précis couvre UNIQUEMENT la base de données. Elle ne couvre pas vos fichiers : aucun fichier téléversé, aucun code de thème ou d'extension, aucun fichier de configuration sur le disque. Si quelqu'un a supprimé un dossier d'images, PITR ne le ramènera pas. Pour les fichiers, vous avez besoin d'une sauvegarde de fichiers. Consultez Effectuer une sauvegarde et Restaurer à partir d'une sauvegarde.
Où le trouver dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Sites web dans la barre latérale gauche, puis cliquez sur le site.
- Dans le menu de gauche du site, ouvrez Sauvegardes, puis Récupération à un moment précis.
L'adresse directe est /websites/<site-id>/pitr.
Éligibilité
La récupération à un moment précis exige que deux conditions soient réunies.
Votre forfait doit l'inclure. Elle est disponible pour les familles de forfaits WordPress.
Le site doit être un site WordPress ou WooCommerce, car le mécanisme repose sur une base de données gérée.
Si l'une de ces conditions n'est pas remplie, la page l'indique clairement : la récupération à un moment précis n'est disponible que pour les sites WordPress et WooCommerce dotés de bases de données gérées. Il n'y a rien à configurer dans ce cas.
Activation
La carte Statut de PITR affiche l'état actuel avec une pastille de statut, le backend utilisé, la date du dernier envoi du journal des modifications, et la fenêtre de conservation en jours.
Cliquez sur Activer PITR pour l'activer. La conservation est de 30 jours.
L'activation ne change rien à vos données. Elle démarre un processus d'envoi continu qui fonctionne en parallèle de vos sauvegardes quotidiennes habituelles ; elle ne les remplace pas.
Il n'y a aucun point de restauration immédiatement après l'activation. L'envoi doit s'exécuter au moins une fois avant que quoi que ce soit puisse être rejoué, et le premier envoi a lieu dans environ cinq minutes. D'ici là, la page indique qu'il n'y a pas encore de point de restauration.
Lire la fenêtre de restauration
Une fois l'envoi en cours, la carte Fenêtre de restauration disponible indique les moments les plus anciens et les plus récents auxquels vous pouvez restaurer, ainsi que le nombre de fichiers de journal des modifications conservés pour couvrir cette période.
Consultez cette information avant d'en avoir besoin, pas pendant un incident. Si la fenêtre commence plus tard que prévu, c'est que l'envoi a été interrompu à un moment donné et que la couverture la plus ancienne a expiré.
Demander une restauration
- Ouvrez l'onglet Récupération à un moment précis.
- Confirmez que la fenêtre de restauration couvre le moment souhaité.
- Dans Restaurer au timestamp, choisissez la date et l'heure. Choisissez un moment juste AVANT le dommage, pas après.
- Cliquez sur Demander la restauration à la DB de staging.
La demande est validée immédiatement. Si le timestamp se situe en dehors de la fenêtre disponible, la fenêtre exacte vous est indiquée plutôt que de vous laisser deviner.
Ce que fait réellement une restauration
C'est le point sur lequel il faut être précis, car c'est l'inverse de ce que la plupart des gens attendent.
Une restauration à un moment précis ne touche pas votre base de données en production. Elle restaure dans une base de données de staging distincte, créée à cet effet et nommée d'après votre domaine et la date cible. Votre site en production continue de fonctionner sur sa propre base de données pendant tout ce temps, sans changement.
Rien n'est écrasé, rien n'est supprimé, et aucune donnée n'est perdue en demandant une restauration. C'est voulu : tout l'intérêt d'un outil de récupération de données est que son utilisation ne peut pas aggraver la situation.
Ce que vous obtenez, c'est une base de données que vous pouvez inspecter. Vous pouvez la comparer avec celle en production, en extraire les lignes endommagées, ou décider que l'ensemble de l'instantané est la version que vous souhaitez. Faire basculer une restauration de staging pour remplacer votre base de données en production est une étape séparée et délibérée que notre équipe effectue avec vous, et non quelque chose qu'un bouton fait en coulisses.
Le basculement vers une base de données restaurée élimine BEL ET BIEN tout ce qui a été écrit dans la base de données en production depuis le point de restauration. Les commandes passées, les commentaires laissés et le contenu modifié après ce timestamp n'existent que dans la base de données en production. Avant tout basculement, déterminez ce qui doit être reporté et indiquez-le. C'est pourquoi la restauration arrive d'abord en staging.
Suivi de la demande
Chaque demande apparaît dans le tableau Demandes de restauration :
| Colonne | Ce qu'elle indique |
|---|---|
| Requested | Quand vous l'avez demandée |
| Target | Le timestamp auquel vous avez demandé de restaurer |
| Status | Où en est la demande |
| DB de staging | Le nom de la base de données en cours de restauration |
Pendant qu'une restauration est en cours, le statut affiche l'étape actuelle et, une fois la relecture commencée, le nombre de fichiers de journal des modifications appliqués sur le total. Une demande échouée affiche l'erreur en dessous.
Une seule restauration peut être en cours à la fois par site. Demander une deuxième restauration pendant qu'une autre est en cours renvoie un conflit plutôt que de la mettre en file d'attente, de sorte qu'une deuxième tentative ne peut pas corrompre la première.
Notre équipe d'ingénierie effectue la restauration de staging et vous envoie un courriel lorsque la base de données de staging est prête. Vous recevez également un courriel de confirmation lorsque la demande est reçue, avec le timestamp cible et le nom de la base de données de staging.
Choisir le bon timestamp
Déterminez quand le dommage a commencé, pas quand vous l'avez remarqué. Il y a généralement plusieurs heures d'écart. Vérifiez votre journal d'activité, les horodatages de vos commandes, ou votre dernière modification de contenu connue comme correcte.
Visez une minute ou deux plus tôt. Un point de restauration juste avant l'incident vous coûte quelques minutes d'écritures légitimes. Un point juste après restaure le dommage en même temps que tout le reste.
Notez ce qui s'est passé après le point de restauration. Commandes, inscriptions, commentaires, soumissions de formulaires. Cette liste est ce que vous devrez reporter manuellement si vous effectuez le basculement.
Dépannage
La page indique que PITR n'est disponible que pour WordPress et WooCommerce. Soit le site n'est pas de ce type, soit votre forfait n'inclut pas cette fonctionnalité.
Pas encore de point de restauration. L'envoi doit s'exécuter au moins une fois après l'activation. Le premier envoi a lieu dans environ cinq minutes.
Ma cible est en dehors de la fenêtre disponible. La conservation est de 30 jours, et la fenêtre peut être plus courte si l'envoi a été interrompu. Le message d'erreur indique les limites exactes. Si le moment dont vous avez besoin a expiré, revenez à une sauvegarde quotidienne : consultez Restaurer à partir d'une sauvegarde.
Une restauration est déjà en cours. Attendez qu'elle se termine. Le tableau affiche son étape et sa progression.
Le statut affiche une bannière concernant le shipper. Votre demande est enregistrée et le message explique l'état actuel. Rien n'est perdu.
J'ai besoin de récupérer les fichiers, pas la base de données. PITR ne peut pas vous aider. Utilisez une sauvegarde de fichiers, et notez qu'une sauvegarde terminée peut être parcourue fichier par fichier plutôt que restaurée dans son intégralité.
Pages connexes
- Effectuer une sauvegarde pour les sauvegardes quotidiennes de fichiers et de bases de données qui fonctionnent en parallèle de celle-ci.
- Restaurer à partir d'une sauvegarde pour le chemin de restauration de l'ensemble du site.
- Environnements de staging pour tester les modifications avant qu'elles n'atteignent la production.
- Sécurité du site si la perte de données a été causée par une compromission plutôt que par une erreur.
Si vous êtes en plein incident et ne savez pas quel outil utiliser, contactez-nous depuis Assistance dans KPanel ou envoyez un courriel à support@kapsulehost.com avec le nom du site et l'heure à laquelle le problème a commencé.