Sites web
Récupération à un instant T
Point-in-time recovery lets you rebuild your database as it was at a chosen minute, rather than only at the moment yesterday's backup ran. This guide covers what it does and does not cover, how to…
Récupération à un moment précis
La récupération à un moment précis vous permet de reconstruire votre base de données telle qu'elle était à une minute choisie, plutôt que seulement au moment où la sauvegarde d'hier a été exécutée. Ce guide couvre ce qu'elle fait et ne fait pas, comment l'activer, comment demander une restauration, et exactement ce qu'une restauration affecte.
À quoi elle sert
Une sauvegarde quotidienne vous offre un point de restauration par jour. C'est suffisant pour la plupart des sinistres et inutile pour celui spécifique où une mauvaise importation, un plugin cassé, ou une modification en masse erronée s'est exécutée à 14h15 et vous l'avez remarqué à 16h. La restauration de la sauvegarde d'hier éliminerait tout le travail réel du matin avec l'erreur.
La récupération à un moment précis comble cette lacune. 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 dans la fenêtre de rétention.
La récupération à un moment précis couvre la BASE DE DONNÉES uniquement. Elle ne couvre pas vos fichiers : pas de uploads, pas de code de thème ou de plugin, pas de fichiers de configuration sur le disque. Si quelqu'un a supprimé un dossier d'images, PITR ne le ramenera pas. Pour les fichiers, vous avez besoin d'une sauvegarde de fichiers. Voir Effectuer une sauvegarde et Restaurer à partir d'une sauvegarde.
Où c'est situé dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Websites dans la barre latérale de gauche, puis cliquez sur le site.
- Dans la bande d'onglets du site, ouvrez Backups, puis Point-in-time recovery.
L'adresse directe est /websites/<site-id>/pitr.
Éligibilité
La récupération à un moment précis nécessite deux conditions.
Votre plan doit l'inclure. Elle est disponible sur les familles de plans 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 des deux n'est pas remplie, la page l'indique clairement : la récupération à un moment précis est disponible uniquement pour les sites WordPress et WooCommerce avec des bases de données gérées. Il n'y a rien à configurer dans ce cas.
L'activer
La carte PITR status affiche l'état actuel avec un badge de statut, le backend utilisé, quand le dernier journal des modifications a été envoyé, et la fenêtre de rétention en jours.
Cliquez sur Enable PITR pour l'activer. La rétention est de 30 jours.
L'activation ne change rien à vos données. Elle lance un processus d'envoi continu qui s'exécute parallèlement à vos sauvegardes quotidiennes normales ; elle ne les remplace pas.
Il n'y a pas de points 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 se produit dans environ cinq minutes. Jusque-là, la page vous indique qu'il n'y a pas encore de points de restauration.
Lire la fenêtre de restauration
Une fois que l'envoi est en cours, la carte Available restore window indique les moments les plus anciens et les plus récents auxquels vous pouvez restaurer, et combien de fichiers journaux des modifications sont conservés pour la couvrir.
Lisez ceci avant d'en avoir besoin, pas pendant un incident. Si la fenêtre commence plus tard que prévu, l'envoi a été interrompu à un moment donné et la couverture plus ancienne a expiré.
Demander une restauration
- Ouvrez l'onglet Point-in-time recovery.
- Confirmez que la fenêtre de restauration couvre le moment souhaité.
- Dans Restore to timestamp, choisissez la date et l'heure. Choisissez un moment juste AVANT les dégâts, pas après.
- Cliquez sur Request restore to staging DB.
La demande est validée immédiatement. Si l'horodatage se situe en dehors de la fenêtre disponible, on vous indique la fenêtre exacte plutôt que de vous laisser deviner.
Ce qu'une restauration fait réellement
C'est la partie où être précis, car c'est le contraire de ce que la plupart des gens s'attendent.
Une restauration à un moment précis ne touche pas votre base de données en direct. Elle restaure dans une base de données de staging séparée, qui est créée à cet effet et nommée d'après votre domaine et la date cible. Votre site en direct continue de s'exécuter sur sa propre base de données tout au long, sans modification.
Rien n'est écrasé, rien n'est supprimé, et aucune donnée n'est perdue en demandant une restauration. C'est délibéré : tout l'intérêt d'un outil de récupération de données est que l'utiliser ne peut pas aggraver la situation.
Ce que vous obtenez est une base de données que vous pouvez inspecter. Vous pouvez la comparer avec la base en direct, extraire les lignes endommagées, ou décider que l'ensemble du snapshot est la version que vous voulez. Promouvoir une restauration de staging sur votre base de données en direct est une étape séparée et délibérée que notre équipe fait avec vous, pas quelque chose qu'un bouton fait en arrière-plan.
Basculer vers une base de données restaurée SUPPRIME tout ce qui a été écrit dans la base de données en direct depuis le point de restauration. Les commandes placées, les commentaires laissés, et le contenu modifié après cet horodatage n'existent que dans la base de données en direct. Avant tout basculement, décidez ce qui doit être reporté et indiquez-le. C'est pourquoi la restauration arrive d'abord en staging.
Suivre la demande
Chaque demande apparaît dans le tableau Restore requests :
| Colonne | Ce qu'elle affiche |
|---|---|
| Requested | Quand vous l'avez demandé |
| Target | L'horodatage que vous avez demandé de restaurer |
| Status | Où en est la demande |
| Staging DB | Le nom de la base de données en cours de restauration |
Pendant qu'une restauration s'exécute, le statut affiche l'étape actuelle et, une fois que la relecture commence, combien de fichiers journaux des modifications ont été appliqués sur le total. Une demande échouée affiche l'erreur en dessous.
Une seule restauration peut être en cours par site à la fois. Demander une deuxième pendant qu'une s'exécute retourne un conflit plutôt que de l'ajouter à la file d'attente, donc une deuxième tentative ne peut pas corrompre la première.
Notre équipe d'ingénierie complète la restauration de staging et vous envoie un e-mail quand la base de données de staging est prête. Vous recevez également un e-mail de confirmation quand la demande est reçue, avec l'horodatage cible et le nom de la base de données de staging.
Choisir le bon horodatage
Déterminez quand les dégâts ont commencé, non quand vous les avez remarqués. Ce sont généralement des heures d'écart. Vérifiez votre journal d'activité, vos horodatages de commandes, ou votre dernière modification de contenu connue comme étant bonne.
Visez une minute ou deux plus tôt. Un point de restauration juste avant l'événement mauvais vous coûte quelques minutes d'écritures légitimes. Un juste après restaure les dégâts avec 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 basculez.
Dépannage
La page indique que PITR est uniquement disponible pour WordPress et WooCommerce. Soit le site n'est pas de ces types, soit votre plan n'inclut pas la fonctionnalité.
Pas de points de restauration pour le moment. L'envoi doit s'exécuter au moins une fois après l'activation. Le premier envoi se produit dans environ cinq minutes.
Ma cible se situe en dehors de la fenêtre disponible. La rétention 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 dépassé la limite, retombez sur une sauvegarde quotidienne : voir 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 l'expéditeur. 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 aider. Utilisez une sauvegarde de fichiers, et notez qu'une sauvegarde complétée peut être parcourue fichier par fichier plutôt que restaurée en entier.
Pages associées
- Effectuer une sauvegarde pour les sauvegardes quotidiennes de fichiers et de base de données qui s'exécutent parallèlement à celle-ci.
- Restaurer à partir d'une sauvegarde pour le chemin de restauration du site entier.
- Environnements de staging pour tester les modifications avant qu'elles ne se répercutent en production.
- Sécurité du site si la perte de données a été causée par une compromise plutôt que par une erreur.
Si vous êtes au milieu d'un incident et ne savez pas quel outil vous avez besoin, contactez-nous depuis Support dans KPanel ou envoyez un e-mail à support@kapsulehost.com avec le nom du site et l'heure à laquelle le problème a commencé.