Sauvegarder son site web et ses données : les solutions possibles

Une sauvegarde n’a de valeur que si elle se restaure

Lors d’un dépannage, la première question est souvent : existe-t-il une sauvegarde exploitable ? Trop souvent, la réponse est non. Elle est absente, incomplète, ou stockée sur le même serveur que le site.
Or un serveur piraté, un hébergement résilié ou une base corrompue emportent généralement les sauvegardes locales avec eux. Une bonne sauvegarde doit donc être automatisée, conservée en dehors de l’hébergement, et surtout testée.

Cet article passe en revue les principales solutions, des plus simples aux plus robustes, avec leurs avantages et leurs limites pour un site WordPress, WooCommerce, PrestaShop ou une instance Dolibarr.

Ce qu’il faut sauvegarder

Un site se restaure à partir de deux éléments indissociables : la base de données et les fichiers. L’un sans l’autre ne suffit pas.

• La base de données (MySQL ou MariaDB) : contenus, produits, commandes, clients, réglages. C’est la partie qui change le plus souvent, surtout sur une boutique.
  
• Les fichiers du site : images et médias, thèmes, modules ou extensions, fichiers de configuration (wp-config.php, app/config/parameters.php sous PrestaShop, conf/conf.php sous Dolibarr).
  
• Les documents Dolibarr : le répertoire des documents (factures PDF, pièces jointes, GED) n’est pas dans la base. Il doit être sauvegardé à part.
  
• Les e-mails : lorsque les boîtes mail sont hébergées avec le site, elles disparaissent avec lui en cas d’incident ou de résiliation. Elles se sauvegardent à part, soit en copiant les répertoires de messagerie du serveur (format Maildir sur la plupart des hébergements cPanel), soit par une copie IMAP vers un autre serveur avec un outil comme imapsync.

Une sauvegarde de la base seule permet de récupérer des données, pas de remettre un site en ligne. Une copie des fichiers sans la base donne un site vide.

Les principales solutions

Il existe cinq grandes familles de sauvegarde. Elles ne s’opposent pas : une stratégie solide en combine souvent deux.

Solution	Hors hébergement	Chiffrement	Historique	Niveau technique
Sauvegardes de l’hébergeur	Non (même fournisseur)	Selon l’hébergeur	Durée imposée	Aucun
Extensions et outils du CMS	Possible selon l’outil	Rarement	Limité	Faible
Scripts serveur (mysqldump, tar, cron)	À organiser	À ajouter	À gérer soi-même	Moyen
rclone	Oui	Oui (crypt)	Limité	Moyen
restic, BorgBackup, Kopia	Oui	Oui, natif	Oui, complet	Moyen à avancé

1. Les sauvegardes de l’hébergeur

La plupart des hébergeurs incluent des sauvegardes automatiques, restaurables depuis le panneau d’administration. C’est un premier filet utile, à condition d’en connaître la fréquence et la durée de conservation.

Leur limite : elles restent chez le même fournisseur. En cas de résiliation, de litige ou d’incident majeur chez l’hébergeur, elles peuvent devenir inaccessibles en même temps que le site.

2. Les extensions et outils intégrés aux CMS

Chaque CMS propose ses propres outils :

• WordPress / WooCommerce : extensions comme UpdraftPlus ou BackWPup, capables d’envoyer les archives vers un stockage distant selon la version utilisée.
  
• PrestaShop : sauvegarde de la base depuis les paramètres avancés, complétée en pratique par une copie des fichiers.
  
• Dolibarr : module Sauvegarde dans les outils d’administration, pour la base et le répertoire des documents.

Ces outils sont accessibles, mais ils s’exécutent dans PHP. Sur un gros site, ils se heurtent aux limites de temps d’exécution et de mémoire. Par défaut, les archives sont souvent stockées sur le serveur lui-même, et non chiffrées. Enfin, une extension compromise ou désactivée lors d’un piratage cesse silencieusement de sauvegarder.

3. Les scripts serveur

Un script lancé par une tâche planifiée (cron) exporte la base et archive les fichiers :

mysqldump --single-transaction --routines base_site > base.sql
tar -czf site.tar.gz public_html/

L’option --single-transaction produit un export cohérent des tables InnoDB sans bloquer le site. Cette méthode est simple et maîtrisée, mais elle ne gère ni le chiffrement, ni la déduplication, ni la rotation des anciennes archives : tout est à écrire soi-même.

4. rclone : synchroniser vers un stockage distant

rclone est un outil en ligne de commande qui copie ou synchronise des fichiers vers des dizaines de destinations : SFTP, stockage objet S3, Swift, Google Drive, etc. Un « remote » de type crypt chiffre les fichiers et leurs noms avant l’envoi.

Point de vigilance : rclone sync reproduit l’état de la source, y compris les suppressions. Si les fichiers sont chiffrés par un rançongiciel ou effacés, la synchronisation propage le dommage. On préfère alors rclone copy, ou l’option --backup-dir qui conserve les versions remplacées.

5. Les sauvegardes dé dupliquées et chiffrées : restic, BorgBackup, Kopia

Ces outils sont conçus pour la sauvegarde, et non pour la simple copie. Leurs points communs :

• Chiffrement côté client : les données sont chiffrées avant de quitter le serveur. restic utilise AES-256 avec authentification Poly1305 ; le stockage ne voit jamais rien en clair.
  
• Déduplication : seuls les blocs modifiés sont envoyés. Une sauvegarde quotidienne d’un site de plusieurs gigaoctets ne transfère souvent que quelques mégaoctets.
  
• Instantanés (snapshots) : chaque passage crée un point de restauration complet, consultable et restaurable individuellement.
  
• Rétention : une politique définit ce que l’on garde.

Restic écrit directement vers SFTP, S3 ou un serveur REST, et peut s’appuyer sur rclone pour atteindre d’autres destinations. BorgBackup est très efficace mais fonctionne au mieux avec Borg installé côté destination. Kopia suit une logique proche de restic, avec une interface graphique en option.

Cette famille offre le meilleur compromis entre sécurité, espace de stockage et facilité de restauration. C’est celle que nous privilégions pour les sauvegardes externalisées.

Où stocker les sauvegardes

La destination compte autant que l’outil : elle doit être indépendante de l’hébergement du site.

• Un espace SFTP distinct : simple et universel, compatible avec rclone, restic et la plupart des outils.
• Un stockage objet compatible S3 : économique pour de gros volumes. Certains fournisseurs proposent le verrouillage d’objets (Object Lock), qui interdit toute modification ou suppression pendant une durée définie : une protection forte contre les rançongiciels.
• Un NAS ou un serveur local : il récupère lui-même les sauvegardes, ce qui ajoute une copie physiquement séparée.

Push ou pull ?

En mode push, le serveur du site envoie ses sauvegardes vers le stockage. C’est le plus simple, mais le serveur détient alors des accès en écriture à ce stockage. Un attaquant qui le compromet peut, en théorie, effacer aussi les sauvegardes.

En mode pull, c’est une machine de sauvegarde qui vient chercher les données. Le serveur du site n’a aucun accès au stockage. On peut aussi limiter le risque en mode push avec un dépôt en ajout seul (append-only, proposé par le serveur REST de restic ou par BorgBackup) ou un stockage verrouillé.

Les bonnes pratiques

Quel que soit l’outil, quelques règles font la différence entre une sauvegarde rassurante et une sauvegarde réellement utile.

1. Appliquer la règle 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site.
   
2. Chiffrer avant l’envoi : les sauvegardes contiennent des données clients, des commandes, parfois des identifiants. Elles ne doivent jamais être lisibles sur le stockage.
   
3. Définir une rétention : garder plusieurs points de restauration (quotidiens, hebdomadaires, mensuels). Une infection ou une erreur est parfois découverte plusieurs jours après coup.
   
4. Surveiller : une alerte par e-mail en cas d’échec. Une sauvegarde qui s’arrête sans prévenir est le scénario le plus courant.
   
5. Vérifier l’intégrité : contrôler régulièrement que les données stockées ne sont pas corrompues (par exemple restic check).
   
6. Tester la restauration : restaurer périodiquement sur un environnement de test. C’est la seule preuve qu’une sauvegarde fonctionne.
   
7. Protéger les clés : la clé ou le mot de passe de chiffrement doit être conservé en dehors du serveur. Sans elle, une sauvegarde chiffrée est irrécupérable.

Côté réglementaire, le RGPD (article 32) demande de pouvoir rétablir la disponibilité des données personnelles et l’accès à celles-ci dans des délais appropriés en cas d’incident. Pour une boutique en ligne ou un CRM, une sauvegarde externalisée, chiffrée et testée répond directement à cette exigence.

Des sauvegardes adaptées à votre hébergement

Il n’existe pas de solution universelle : le bon choix dépend de l’hébergement, du volume de données et de la criticité du site. Un site vitrine et une boutique qui enregistre des commandes toute la journée n’ont pas les mêmes besoins.

PBA Solutions met en place des sauvegardes externalisées sur mesure : chiffrées à la source, historisées, contrôlées et accompagnées d’alertes en cas d’échec. Pour WordPress, WooCommerce, PrestaShop et Dolibarr, y compris sur hébergement mutualisé lorsque l’hébergeur le permet. La mise en place se fait sur devis, après analyse de votre hébergement.

Pascal 31/10/2026

Découvrir nos sauvegardes externalisées · Faire vérifier mes sauvegardes