Faire restaurer un compte d'hébergement complet à partir d'une sauvegarde

Temps de lecture env. : 6 minutes

Parfois, il ne suffit pas de restaurer un seul fichier ou certaines données de messagerie. Si des parties plus importantes d'un compte d'hébergement sont concernées, une restauration complète peut s'avérer judicieuse.

Le compte d'hébergement est ainsi restauré à un état antérieur à l'aide d'une sauvegarde existante.

Une telle restauration doit être mûrement réfléchie. En effet, ce ne sont pas seulement les données erronées ou perdues qui sont remplacées par des données plus anciennes. Les modifications apportées après la sauvegarde choisie peuvent également être affectées.

En bref : Lors d'une restauration complète, les données sauvegardées de votre compte d'hébergement sont restaurées à partir d'une sauvegarde précédente. C'est pourquoi nous vérifions au préalable s'il est vraiment nécessaire de restaurer l'ensemble du compte ou si une restauration ciblée suffit.

Quand une restauration complète peut-elle s'avérer utile ? #

Une restauration complète du compte entre en ligne de compte principalement lorsque ce ne sont pas seulement des données individuelles qui sont concernées, mais des parties plus importantes du compte d'hébergement.

Cela peut par exemple être le cas si :

  • un site web ne fonctionne plus correctement après des modifications importantes,
  • plusieurs fichiers et bases de données sont concernés,
  • de plus grands volumes de données ont été accidentellement supprimés ou modifiés,
  • plusieurs zones du compte d'hébergement doivent être réinitialisées à un état antérieur ou
  • une restauration ciblée de données individuelles ne suffit pas.

Déterminer si une restauration complète est réellement la meilleure solution dépend toujours du problème concret.

Que signifie « compte d'hébergement complet » ? #

Un compte d'hébergement ne se compose pas seulement des fichiers de votre site web.

Cela comprend, selon l'utilisation, entre autres :

  • Fichiers du site Web,
  • Bases de données,
  • données de courrier électronique et
  • autres données sauvegardées du compte d'hébergement.

Lors d'une restauration complète, ce n'est donc pas seulement un seul fichier de site web qui est remplacé. C'est une partie beaucoup plus importante du compte d'hébergement sauvegardé qui est réinitialisée à l'état de la sauvegarde sélectionnée.

Pourquoi ne faut-il pas rétablir tout le compte à la hâte ? #

Une restauration complète ressemble d'abord à la solution la plus simple : on prend une ancienne sauvegarde et on remet tout à zéro.

Cela peut toutefois concerner un nombre inutilement élevé de données actuelles.

Un exemple simple :

Lundi
Création d'une sauvegarde
        ↓
Mardi
Modification erronée du site web
        ↓
Mercredi
Arrivée de nouveaux e-mails et soumissions de formulaires
        ↓
Jeudi
Découverte de l'erreur

Une réinitialisation complète de la sauvegarde de lundi pourrait certes éliminer la modification erronée du site web. En même temps, les données restaurées proviennent également de lundi.

Les données plus récentes doivent donc être prises en compte avant une restauration complète.

Important : Une restauration complète ne devrait pas être effectuée simplement « par précaution ». Si seule une petite partie des données est concernée, une récupération ciblée est souvent la meilleure solution.

Quelles données plus récentes peuvent être concernées ? #

Tout ce qui a été recréé ou modifié après la sauvegarde sélectionnée n'est pas encore inclus dans cette sauvegarde plus ancienne.

Cela peut concerner, par exemple :

  • contenu de site Web nouveau ou modifié,
  • Commandes WooCommerce,
  • nouveaux comptes clients,
  • Entrées de formulaire,
  • fichiers téléchargés,
  • Modifications des bases de données et
  • données d'e-mails plus récentes.

Plus un site web ou un compte de messagerie est utilisé, plus ce point est important.

Exemple : Une boutique WooCommerce #

Dans le cas d'une boutique en ligne, il apparaît clairement pourquoi une restauration complète doit être soigneusement vérifiée.

Supposons qu'une sauvegarde soit effectuée le lundi soir. Mardi, une modification provoque un problème sur le site Web. Mais le problème n'est remarqué que jeudi.

Plusieurs nouvelles commandes sont arrivées entre lundi et jeudi.

Lundi soir
Sauvegarde
        ↓
Mardi
L'erreur se produit
        ↓
Mardi à jeudi
Nouvelles commandes
        ↓
Jeudi
L'erreur est découverte

Si le compte d'hébergement complet est simplement restauré à lundi soir, la sauvegarde plus ancienne ne contiendra pas encore les commandes reçues ultérieurement.

C'est pourquoi il faut vérifier avant une restauration complète quelles données actuelles ont été générées depuis la sauvegarde souhaitée.

Sélectionner la bonne sauvegarde #

Même lors d'une restauration complète, la sauvegarde la plus récente n'est pas automatiquement la bonne.

Ce qui est déterminant, c'est de savoir quand le compte d'hébergement était pour la dernière fois dans un état utilisable.

Si un problème persiste par exemple depuis déjà cinq jours, les sauvegardes des quatre derniers jours peuvent également contenir cette erreur.

Réfléchissez-y donc le plus précisément possible :

Quand est-ce que tout fonctionnait encore ?

Quand la modification problématique a-t-elle été effectuée ?

Quand le problème a-t-il été remarqué pour la première fois ?

Dans JetBackup 5, vous pouvez voir vous-même de quels jours des sauvegardes sont disponibles pour votre compte d'hébergement.

Nous vous montrons comment trouver ces fusibles dans l'article Quelles sont les sauvegardes disponibles ? Afficher les sauvegardes dans JetBackup 5.

Faut-il vraiment tout réinitialiser ? #

Pas toujours.

Si le problème ne concerne par exemple qu'un seul fichier, une restauration ciblée de ce fichier peut suffire.

Les données de messagerie peuvent également être restaurées de manière ciblée selon la situation, sans pour autant réinitialiser l'ensemble du compte d'hébergement.

C'est pourquoi tu dois nous décrire le plus précisément possible dans le ticket de support ce qui s'est passé. Nous pourrons alors examiner quelle est l'étendue de la restauration judicieuse.

Nous expliquons le déroulement général dans l'article Restaurer une sauvegarde sur CURIAWEB : voici comment fonctionne la restauration.

Comment demander une restauration complète #

Si vous souhaitez restaurer l'intégralité de votre compte d'hébergement à partir d'une sauvegarde, veuillez ouvrir un ticket de support dans le centre client CURIAWEB.

Créer un ticket de support pour une récupération

Dites-nous le plus précisément possible :

  • quel compte d'hébergement ou quel domaine est concerné,
  • ce qui s'est passé,
  • la date à laquelle le compte fonctionnait encore correctement,
  • quelle sauvegarde utiliser, si vous le savez déjà, et
  • si de nouvelles données importantes sont apparues depuis lors.

Une requête pourrait par exemple ressembler à ceci :

Domaine :
meine-domain.ch

Problème :
Après des modifications importantes, le site web et la base de données ne fonctionnent plus correctement.

Dernier état correct connu :
Mardi soir

Sauvegarde souhaitée :
Mardi

Important :
De nouveaux e-mails ont été reçus depuis mardi.

Le dernier indice en particulier est important. Ainsi, nous savons que de nouvelles données ont été créées après la sauvegarde souhaitée et qu'elles doivent être prises en compte avant la restauration.

Que vérifie CURIAWEB avant la restauration ? #

Avant de restaurer l'intégralité du compte d'hébergement, nous vérifions les informations de ta demande et les sauvegardes disponibles.

Il s'agit principalement des questions suivantes :

  • Existe-t-il une sauvegarde adéquate ?
  • Le moment de la sauvegarde correspond-il au problème décrit ?
  • Est-il vraiment nécessaire d'effectuer une restauration complète ?
  • Des données plus récentes peuvent-elles être affectées par la restauration ?

Si des informations importantes manquent ou si les conséquences d'une restauration complète ne sont pas claires, nous clarifions cela avec vous avant la restauration.

Que se passe-t-il pendant la restauration ? #

CURIAWEB lance la restauration du compte d'hébergement à partir de la sauvegarde sélectionnée.

Au cours de cette opération, les données incluses dans la sauvegarde et destinées à la restauration sont remises en état sur le système d'hébergement.

La durée de cette opération dépend, entre autres, de la taille du compte et du volume de données à transférer.

Un petit compte d'hébergement contenant peu de données est traité plus rapidement qu'un grand compte comprenant des sites web volumineux, des bases de données et des données de messagerie. Il est donc impossible de donner une durée fixe de manière fiable pour chaque restauration.

Que devez-vous contrôler après la restauration ? #

Après une restauration complète, vous devez vérifier les principales zones de votre compte d'hébergement.

Cela comprend, selon l'utilisation, par exemple :

  • Consulter le site web et vérifier les pages importantes,
  • Tester les formulaires,
  • vérifier la zone d'administration de WordPress,
  • vérifier les fonctionnalités importantes d'une boutique en ligne,
  • Vérifier les comptes de messagerie et les messages nécessaires et
  • vérifier si le problème initial est résolu.

Si, par la suite, quelque chose ne va toujours pas, indique-nous dans le ticket de support existant le plus précisément possible ce qui ne fonctionne pas encore.

Une restauration ne résout pas automatiquement la cause #

Une restauration complète ramène votre compte d'hébergement à un état sauvegardé antérieur. Cela ne permet cependant pas de déterminer automatiquement pourquoi le problème initial est survenu.

Si, par exemple, un changement spécifique, un plugin défectueux ou une autre cause a provoqué le problème, cette cause devrait également être examinée.

Sinon, le même problème risque de se reproduire plus tard.

Exemple : Si un plugin WordPress a provoqué une erreur et que la même modification problématique est effectuée à nouveau après la restauration, la même erreur peut également se reproduire.

Et si le problème est déjà présent dans la sauvegarde ? #

Une sauvegarde est toujours la copie de l'état à un moment précis.

Si le problème d'origine était déjà présent à ce moment-là, il peut également être inclus dans la sauvegarde.

C'est pourquoi la question « À partir de quand tout fonctionnait-il encore ? » est particulièrement importante lors d'une restauration complète.

Une erreur survient
        ↓
Une sauvegarde est créée
        ↓
Restauration de cette sauvegarde
        ↓
L'erreur peut toujours être présente

Si possible, il convient donc de choisir une sauvegarde datant d'avant l'apparition du problème.

Et si la sauvegarde nécessaire n'existe plus ? #

CURIAWEB conserve les sauvegardes quotidiennes pendant 30 jours.

Si le problème remonte à plus longtemps, il est donc possible qu'il n'y ait plus de sauvegarde disponible pour la période requise.

C'est pourquoi vous devriez nous contacter le plus tôt possible en cas de perte de données importante.

Important : Une sauvegarde existante ne signifie pas automatiquement qu'elle contient l'état souhaité. Ce qui est décisif, c'est de savoir s'il existe une sauvegarde datant d'un moment où les données nécessaires étaient encore correctes.

Résumé #

Une restauration complète peut s'avérer utile si de grandes parties d'un compte d'hébergement ont été endommagées, supprimées ou modifiées de manière erronée.

Les données sauvegardées du compte d'hébergement sont ainsi restaurées à partir d'une sauvegarde précédente.

Comme une sauvegarde plus ancienne ne contient pas encore les modifications et données plus récentes, une restauration complète doit être examinée avec soin. Si seuls des fichiers individuels ou d'autres données clairement limitées sont concernés, une restauration ciblée peut s'avérer être la meilleure solution.

Vous pouvez consulter vous-même les sauvegardes disponibles dans JetBackup 5. La restauration du compte d'hébergement sera effectuée par CURIAWEB pour vous.

Dans votre demande, veuillez nous indiquer aussi précisément que possible ce qui s'est passé, quand le compte a fonctionné correctement pour la dernière fois et quelles sont les nouvelles données générées depuis lors.

Dernière mise à jour 30 août 2026
Cet article a-t-il été utile ?
Consentement à l'utilisation de Cookies avec Real Cookie Banner