Revenir à hier : restaurer son site depuis l'espace client
Ou : le bouton « Restaurer » est une machine à remonter le temps qui emmène tout le monde, y compris les commandes du jour.
La réponse courte : depuis l’espace client, on choisit une date, puis ce que l’on restaure, tout l’hébergement, un site, une base de données ou quelques fichiers. Le piège est le même dans tous les panneaux : une restauration complète écrase tout ce qui a changé depuis la date choisie. OVHcloud l’écrit noir sur blanc dans son guide de restauration de l’espace FTP : l’opération « va en effet écraser l’ensemble des données actuelles ». Avant de cliquer, il faut donc savoir ce que l’on perdra, une préparation qui fait partie de la sécurité d’un site chez son hébergeur au même titre que les sauvegardes elles-mêmes.
La méthode tient en trois questions. Quand l’erreur est-elle apparue ? Qu’est-ce qui a changé depuis : commandes, commentaires, inscriptions, fichiers déposés ? Peut-on restaurer seulement la partie abîmée ? Sur une boutique ou un site à formulaires, la réponse à la deuxième question pousse presque toujours vers la restauration partielle.
Pour qui : un indépendant ou une petite entreprise qui veut pouvoir remettre son site dans l’état d’hier en quelques clics, sans passer par le support.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026), restauration automatique sur sept jours comprise.
Pour démarrer : commander l’hébergement web Infomaniak, puis repérer le menu de restauration avant d’en avoir besoin.
Restaurer la sauvegarde d’un site chez son hébergeur : options et pièges
| Panneau | Restauration complète | Restauration partielle | À savoir avant de cliquer |
|---|---|---|---|
| Infomaniak | « simple » : tous les sites et bases de l’hébergement | « avancée » : sites et bases choisis ; fichiers isolés depuis le dossier /backups | sites mis en maintenance pendant l’opération ; fichiers et bases ne sont pas sauvegardés au même moment |
| OVHcloud, mutualisé | tout l’espace FTP, à l’une des cinq dates proposées | fichiers par FTP, avec l’identifiant suivi de -snap0 à -snap4 ; bases depuis leur propre menu | la moitié de l’espace de stockage doit être libre ; de quelques minutes à quelques heures |
| Hetzner, Webhosting | tout le dossier public_html | fichiers ou dossiers choisis ; une base vers une nouvelle base | trois destinations : nouveau dossier, écrasement, ou suppression puis restauration |
| SiteGround | fichiers et bases | fichiers seuls, base seule, mails seuls | jusqu’à 30 copies quotidiennes |
| cPanel, archive complète téléchargée | impossible depuis cPanel, seul l’hébergeur peut la restaurer | dossier personnel, bases, redirections de mails | les sauvegardes partielles se restaurent soi-même |
Relevé le 12 novembre 2026 dans la documentation de chaque hébergeur et dans celle de cPanel.
Infomaniak résume bien la logique de son panneau dans sa FAQ sur la restauration automatique : la restauration simple prend tout, l’avancée laisse choisir les sites et les bases. La même page signale un détail que l’on découvre d’habitude trop tard : les sauvegardes des fichiers et des bases de données ne sont pas faites en même temps. Un WordPress restauré peut donc retrouver des fichiers et une base décalés de quelques heures, d’où le conseil de tester le site juste après.
La technique la plus sûre consiste à restaurer à côté plutôt que par-dessus. Hetzner permet de restaurer des fichiers dans un nouveau dossier et une base de données sous un nouveau nom, comme le décrit sa documentation konsoleH ; chez OVHcloud, les identifiants FTP suffixés donnent accès aux anciennes versions, d’où l’on télécharge seulement le fichier voulu ; chez Infomaniak, le dossier /backups joue le même rôle. On compare ensuite l’ancienne version et l’actuelle, puis on remplace uniquement ce qui est abîmé. C’est plus lent qu’un clic, mais aucune commande du jour ne disparaît.
Restaurer une seule base suffit souvent pour un CMS dont le contenu vit dans la base : un article effacé, un réglage cassé, une extension qui a mal migré ses tables. À l’inverse, une extension corrompue ou un thème modifié se répare par les fichiers seuls. La restauration complète reste la solution des cas où l’on ne sait pas ce qui a changé, et c’est précisément le cas où elle est la plus risquée.
Reste le cas de l’archive complète téléchargée depuis cPanel. La documentation de cPanel est formelle : ce fichier ne se restaure pas automatiquement depuis cPanel, seulement depuis WHM, l’outil de l’hébergeur. Il faut donc ouvrir un ticket, ou extraire l’archive et remettre les fichiers à la main. Les sauvegardes partielles (dossier personnel, bases, redirections de mails), elles, se restaurent sans aide.
Savoir jusqu’où l’on peut remonter
Une restauration n’est possible qu’à l’intérieur de la fenêtre de conservation : cinq dates sur deux semaines pour l’espace FTP d’OVHcloud, sept jours chez Infomaniak, quarante-cinq jours chez PlanetHoster. Avant le jour où il faut s’en servir, mieux vaut connaître sa propre limite, relevée hébergeur par hébergeur dans le tableau des durées de conservation.
Quand la sauvegarde de l’hébergeur ne suffit plus
Si l’erreur est plus ancienne que la plus vieille copie, ou si le compte lui-même a été supprimé, le panneau ne peut plus rien. Il reste la copie que vous aurez gardée ailleurs, à condition de l’avoir testée au moins une fois ; la méthode et le calendrier de test sont dans le guide de la copie hors hébergeur.
Restaurer après un piratage
Après une intrusion, restaurer la veille ne suffit pas : la faille qui a servi est toujours là, et le site sera réinfecté dans les jours qui suivent. Il faut choisir une date antérieure à l’intrusion, changer les mots de passe et corriger la faille avant de rouvrir, dans l’ordre décrit par la marche à suivre après un piratage.