Un site WordPress sans sauvegarde automatique, c’est un peu comme un PC sans onduleur : ça tient… jusqu’au jour où tout s’éteint. Sur un hébergement o2switch, beaucoup se reposent uniquement sur les backups inclus, sans vraiment savoir comment ils fonctionnent ni ce qu’ils couvrent. Le jour où un plugin casse tout, où un thème mal codé met le site web en rideau, ou où un piratage s’invite, la panique arrive vite. L’objectif ici consiste à poser une base solide : comprendre ce que propose o2switch, voir ses limites, puis mettre en place une stratégie de sauvegarde automatique WordPress qui tient la route, avec la tête froide et sans passer ses nuits dans cPanel.
Ce mode d’emploi détaille plusieurs approches complémentaires : l’usage intelligent des sauvegardes natives de l’hébergeur, un Tutoriel complet sur UpdraftPlus pour les petits et moyens sites, un script maison pour les gros projets, et une solution clé en main pour ceux qui préfèrent payer un abonnement plutôt que de bidouiller. Pour garder les choses concrètes, tout est illustré avec un fil rouge simple : le site vitrine et la boutique en ligne d’une petite marque fictive qui tourne sur o2switch. Objectif final : disposer d’un plan de Backup clair, testé, et documenté, où la Restauration ne prend pas plus de quelques minutes le jour où tout déraille.
En bref
- o2switch propose déjà des sauvegardes quotidiennes, mais limitées à 30 jours et parfois inadaptées aux gros sites WordPress.
- Une vraie stratégie de sauvegarde automatique repose sur au moins une copie distante (Google Drive, pCloud, autre serveur) et des tests réguliers de restauration.
- UpdraftPlus couvre très bien la majorité des sites jusqu’à plusieurs dizaines de Go, en particulier avec un stockage externe bien configuré.
- Les très gros sites ou les boutiques WooCommerce très actives gagnent à utiliser soit un script wp-cli + rsync, soit Jetpack Backup pour le temps réel.
- Tester la restauration sur une préproduction évite les mauvaises surprises le jour où il faut remonter le site en urgence.
Sauvegardes automatiques natives o2switch et limites pour WordPress
Sur l’offre mutualisée d’o2switch, chaque compte bénéficie d’une sauvegarde automatique quotidienne. Dans la pratique, les fichiers et les bases de données sont copiés chaque nuit sur un stockage séparé du serveur de production. La fenêtre technique se situe généralement entre 2 h et 6 h du matin, période où la majorité des sites reçoivent peu de trafic. Pour un utilisateur qui démarre, ça ressemble à un filet de Sécurité rassurant : aucune configuration à faire, pas d’extension à installer, et une console de Restauration disponible depuis l’espace client ou le cPanel via des outils type JetBackup.
Le problème surgit lorsque le site commence à grossir ou que les besoins se complexifient. La conservation se limite à environ 30 jours, avec une seule image par jour. Si un bug discret se glisse dans le code ou qu’une faille de Sécurité reste présente pendant plusieurs semaines, toutes les sauvegardes automatiques finissent par embarquer le problème. Un site vitrine simple peut s’en contenter, mais un WordPress avec beaucoup de contenu, des membres, voire une boutique WooCommerce, mérite un historique plus fin et plus long.
Autre point à surveiller : la taille du compte. Les sauvegardes natives restent très confortables pour des sites en dessous de quelques dizaines de Go. Au-delà, surtout quand on dépasse la barre des 50 Go de fichiers (médias, uploads, backups stockés sur le même hébergement), l’outil de Restauration peut devenir capricieux. Certains comptes très chargés ne s’affichent même plus correctement dans l’interface de JetBackup, ce qui pousse les utilisateurs à contacter le support pour une restauration manuelle. Ça fonctionne, mais ce n’est ni immédiat ni autonome.
Le cas de Lucas, gérant d’un site photo sur WordPress hébergé chez o2switch, illustre bien cette situation. Pendant deux ans, il a empilé des images en pleine résolution directement dans la médiathèque. Résultat : plus de 60 Go d’uploads, dont une bonne partie inutilisée. Quand un plugin de galerie a fait exploser le site, il a tenté une restauration depuis l’interface de l’hébergeur… sans succès, les archives étant trop volumineuses. Ce genre de scénario rappelle un principe simple : une stratégie de Backup doit aussi intégrer l’entretien du site, compression des médias et nettoyage des fichiers inclus.
D’ailleurs, ces sauvegardes natives ne fournissent aucune granularité horaire. Si quelqu’un supprime une page importante à 14 h et que l’on s’en rend compte à 17 h, impossible de revenir à l’état du site de 13 h. On devra restaurer l’archive de la nuit précédente, en perdant au passage toutes les modifications de la journée. C’est jouable sur un site vitrine assez statique, beaucoup moins sur une boutique ou un blog animé. Pour les workflows modernes où les contenus et commandes évoluent en continu, cette approche daily-only reste trop grossière.
Dernier point, trop souvent négligé : la dépendance à un seul fournisseur. S’appuyer uniquement sur les sauvegardes internes d’o2switch signifie que site web et backup habitent chez le même prestataire. Un incident majeur côté hébergeur reste rare, mais pas impossible. Dans une logique de résilience, garder au moins une copie complète hors de cet environnement (cloud externe, second hébergement, NAS distant) change complètement la donne. La vraie Sécurité ne vient pas d’un bouton Restauration magique, mais de la diversification des points de chute.
En résumé, les sauvegardes natives d’o2switch jouent un rôle utile, surtout en cas de fausse manipulation ponctuelle ou de petit crash. Mais dès que le WordPress commence à prendre de l’importance, les considérer comme unique bouée de secours relève plus du pari que de la stratégie. La suite du mode d’emploi montre comment compléter ces mécanismes internes par un système de Sauvegarde automatique spécifique à WordPress, calibré sur la taille et l’usage du site.
Sauvegarde automatique WordPress sur o2switch avec UpdraftPlus
Pour la plupart des sites WordPress hébergés chez o2switch, UpdraftPlus reste la solution la plus simple à mettre en place. L’extension existe depuis longtemps, supporte très bien les spécificités de l’hébergement, et sait dialoguer avec une grande variété de stockages distants. Sur un WordPress vitrine, un blog classique ou un site institutionnel, ce plugin couvre 95 % des besoins sans surcoût, surtout en version gratuite. L’idée consiste à sortir les archives de l’hébergement, tout en gardant un nombre limité de copies locales pour les restaurations rapides.
Imaginons encore Lucas, qui vient de refaire son site photo avec une meilleure gestion des images et un thème optimisé. Cette fois, il prend le réflexe d’installer UpdraftPlus dès la mise en ligne. Le Tutoriel officiel préconise une installation via le menu Extensions, mais le chemin reste toujours le même : Extensions, Ajouter, recherche du mot-clé, puis clic sur Installer et Activer. Une fois l’extension en place, tout se passe dans Réglages, Sauvegardes UpdraftPlus. L’interface, un peu dense au premier regard, permet pourtant un contrôle fin sans perdre l’utilisateur.
Le premier paramètre à soigner concerne la fréquence des sauvegardes. Sur un site vitrine modifié une ou deux fois par mois, une capture quotidienne de la base de données et hebdomadaire des fichiers peut suffire. Sur un blog mis à jour plusieurs fois par semaine, passer à une sauvegarde fichier tous les deux jours devient plus logique. Pour un petit WooCommerce hébergé chez o2switch, avec une dizaine de commandes journalières, beaucoup optent pour un rythme plus agressif : base toutes les heures et fichiers plusieurs fois par jour. Ce n’est pas obligatoire, mais ça limite les pertes en cas de crash brutal.
L’autre élément souvent négligé tient au stockage distant. UpdraftPlus propose une série d’options : Google Drive, Dropbox, Amazon S3, pCloud, SFTP, etc. Sur un hébergement o2switch, trois solutions reviennent constamment dans les retours d’expérience :
- Google Drive pour les petits sites, grâce aux 15 Go gratuits et à la bande passante généreuse.
- pCloud pour ceux qui préfèrent un paiement unique plutôt qu’un abonnement mensuel.
- Amazon S3 pour les architectures plus avancées, notamment en multi-sites ou multi-environnements.
Une configuration réaliste pourrait ressembler à ceci : sauvegarde de la base de données toutes les 4 heures, fichiers une fois par jour à 3 h, conservation de 7 versions sur l’hébergement et de 14 versions sur Google Drive. Ce réglage protège contre les erreurs récentes tout en gardant un historique sur deux semaines en externe. Tant que le site reste sous les 10 ou 15 Go, les quotas de Drive ne posent pas de souci particulier. Au-delà, pCloud ou S3 deviennent plus confortables.
Pour visualiser plus clairement les options de stockage usuelles avec UpdraftPlus et o2switch, le tableau suivant peut aider à comparer les choix courants.
| Destination | Coût approximatif | Points forts | Points faibles |
|---|---|---|---|
| Google Drive | Gratuit jusqu’à 15 Go | Facile à configurer, très répandu, bonne intégration avec UpdraftPlus | Espace vite saturé avec de gros sites, limite d’envoi quotidien |
| Dropbox | Environ 10 € / mois pour 2 To | Service stable, historique de fichiers robuste | Coût récurrent pour un simple Backup |
| pCloud | Paiement unique pour plusieurs To | Aucun abonnement, stockage basé en Europe, bon débit depuis la France | Solution moins connue, interface parfois déroutante |
| Amazon S3 | Quelques euros par mois en usage classique | Très performant pour gros volumes, configuration fine des règles de rétention | Interface plus technique, nécessite un minimum de culture DevOps |
Un point de vigilance mérite d’être rappelé : éviter de stocker les sauvegardes sur le même compte FTP o2switch. UpdraftPlus le permet, mais si le serveur se fait pirater ou subit une panne lourde, site web et archives disparaissent ensemble. Pour un test ponctuel ou un dépannage rapide, ce stockage local peut dépanner. Pour une vraie stratégie, il doit servir uniquement de tampon, pas de coffre-fort principal.
Enfin, la question de la Restauration ne doit pas rester théorique. Même avec UpdraftPlus configuré au petit oignon, la première chose à faire après la mise en place consiste à simuler une récupération, idéalement sur un sous-domaine de test ou un environnement de préproduction. Cette démarche permet de vérifier que les archives ne sont ni corrompues ni incomplètes, que les plugins se réinstallent correctement, et que la base se recolle sans erreur critique. Ce simple test transforme une configuration abstraite en outil concret, prêt à encaisser une vraie panne.
Pour compléter la vision, certains choisiront d’aller plus loin dans la compréhension de WordPress côté serveur, par exemple en consultant un guide d’installation sur Debian comme sur cette ressource détaillée : installer WordPress sur Debian. Plus on comprend ce qui se passe sous le capot, plus on maîtrise les conséquences des décisions de Backup.
Script wp-cli + rsync sur o2switch pour les gros sites WordPress
Dès que la taille du site commence à flirter avec plusieurs dizaines de Go, UpdraftPlus peut montrer ses limites. Les temps de compression s’allongent, les transferts vers le cloud déclenchent parfois des coupures de ressources côté hébergement, et la moindre sauvegarde manuelle devient un marathon. Sur un o2switch bien configuré, une solution plus musclée consiste à passer par un script Bash combinant wp-cli et rsync. Cette approche demande un peu plus de bagage technique, mais elle offre un contrôle très fin sur les volumes et les fréquences.
Reprenons un nouvel exemple, celui d’une agence qui gère un multi-site WordPress de 80 Go pour plusieurs marques, toutes hébergées sur la même offre Grow. Chaque nuit, l’agence doit extraire une copie de la base, sauvegarder les fichiers critiques (wp-content, quelques scripts custom) et envoyer le tout vers un second hébergement o2switch dans un autre datacenter. UpdraftPlus peut encore tenir, mais le moindre timeout pendant la compression casse tout le process. Un script maison sera bien plus robuste à condition de le documenter convenablement.
La logique générale se déroule en trois étapes. D’abord, utiliser wp-cli pour générer un dump propre de la base de données WordPress. Ensuite, compresser les dossiers importants (souvent wp-content et éventuellement wp-config.php) avec une commande tar. Enfin, transférer l’archive obtenue vers un serveur externe avec rsync via SSH. Une tâche cron planifiée dans cPanel permet de lancer ce script à heure fixe, par exemple à 4 h du matin, lorsque la charge serveur reste basse. On obtient ainsi une vraie Sauvegarde automatique hors WordPress, indépendante des extensions.
Un exemple simple de stratégie pourrait être le suivant. Tous les jours à 4 h, création d’un dump SQL et d’une archive des fichiers critiques, envoyés sur un VPS externe via rsync. Tous les dimanches, génération d’un Backup complet (fichiers + base) avec un nom incluant la date, conservé pendant huit semaines sur le serveur distant. Le script prend soin de supprimer les archives de plus de 60 jours, pour éviter de saturer le stockage. Ce genre de routine se met en place une fois, puis tourne en tâche de fond. Le rôle du développeur consiste ensuite à surveiller ponctuellement les logs et à vérifier que la taille des fichiers reste cohérente.
Sur o2switch, un point pratique consiste à profiter de l’accès SSH et de wp-cli déjà disponible dans de nombreux environnements. Ceux qui découvrent ces outils auront intérêt à répéter la procédure sur un petit site de test avant de la transposer sur un gros WordPress de production. Un script mal configuré peut facilement générer des archives incomplètes ou saturer le quota disque. Sans monitoring minimal, la stratégie de Backup risque de se transformer en bombe à retardement. Mieux vaut prendre une heure pour valider le process avant de s’en remettre à ce système les yeux fermés.
La Restauration, dans ce contexte, demande également plus d’attention. Il ne suffit plus de cliquer sur un bouton dans l’interface WordPress. Il faut déployer l’archive sur le serveur cible, importer la base de données via wp-cli ou phpMyAdmin, ajuster l’URL du site, puis réinstaller éventuellement un certificat SSL. Ce parcours paraît plus exigeant, mais il donne aussi une liberté totale en terme de migration. On peut restaurer sur un autre hébergeur, sur un environnement local, ou sur un serveur de préprod pour tester une refonte complète. Pour un projet sérieux, cette flexibilité vaut largement la montée en complexité initiale.
Une bonne pratique consiste à documenter ce fonctionnement dans un simple fichier texte versionné avec le projet ou stocké dans un drive partagé. Une sorte de mini « mode d’emploi » interne qui explique, pas à pas, comment lancer un Backup manuel, comment vérifier son intégrité, et comment remettre le site en route en cas de crash. Ce document, s’il est bien rédigé, peut sauver une équipe un soir de déploiement raté. On peut y intégrer des liens utiles, par exemple vers des articles sur la gestion d’erreurs comme ce guide sur l’erreur critique WordPress, qui aide à diagnostiquer rapidement les symptômes les plus fréquents.
Au fond, cette approche scriptée réconcilie deux exigences : maintenir une Sauvegarde automatique suffisamment fréquente pour ne pas perdre de données importantes, tout en gardant la main sur les outils utilisés. Elle se destine aux sites dont la perte de quelques heures de données devient inacceptable, que ce soit pour des raisons financières, légales ou d’image. Lorsqu’elle est correctement testée, elle devient un pilier aussi important que la surveillance des performances ou la protection anti-DDOS.
Jetpack Backup et solutions payantes pour la sauvegarde temps réel
Tout le monde n’a pas envie de mettre les mains dans les scripts Bash. Et pour certains types de sites WordPress sur o2switch, l’exigence dépasse le simple crash occasionnel. C’est le cas des boutiques WooCommerce à fort trafic, des plateformes de formation avec des inscriptions continues, ou des sites communautaires où des centaines d’utilisateurs interagissent chaque jour. Dans ces contextes, la question clé n’est plus « ai-je un Backup de la nuit dernière ? », mais « jusqu’où peux-je revenir en arrière sans perdre des informations critiques ? ».
C’est là qu’entrent en jeu des solutions comme Jetpack Backup. Anciennement connu sous le nom de VaultPress, ce service proposé par Automattic, l’éditeur de WordPress.com, fournit des sauvegardes en temps quasi réel des sites WordPress auto-hébergés. Concrètement, le plugin surveille les événements critiques (nouveaux articles, commandes, changements de fichiers, etc.) et déclenche des copies incrémentales à chaque modification. L’historique peut ainsi se compter en dizaines ou centaines de points de Restauration, plutôt qu’en 30 snapshots quotidiens.
Sur un hébergement o2switch, l’intégration se déroule sans tension particulière. L’hébergeur autorise les connexions sortantes vers les serveurs de Jetpack, ce qui permet une synchronisation fluide. Le coût, aux alentours d’une dizaine d’euros par mois pour un site, se justifie principalement par le niveau de granularité offert. Sur une boutique WooCommerce qui génère du chiffre d’affaires chaque heure, la perte de 24 heures de données représenterait un manque à gagner net, sans parler de l’impact client. Dans ce contexte, un Backup temps réel devient presque une assurance métier.
L’expérience de Sophie, responsable d’une petite boutique de cosmétiques en ligne, illustre bien ce changement de paradigme. Après un bug de mise à jour d’extension qui a bloqué les paiements pendant plusieurs heures, elle a décidé de revoir totalement son dispositif. Plutôt que de s’appuyer uniquement sur les sauvegardes o2switch et un plugin gratuit, elle a opté pour un combo : Jetpack Backup pour le temps réel et une Sauvegarde automatique hebdomadaire complète vers pCloud avec UpdraftPlus. La première lui sert en cas de pépin ponctuel en journée, la seconde en cas de gros crash ou d’incident majeur côté prestataire.
Ces services payants apportent aussi d’autres briques de Sécurité. Jetpack inclut par exemple un scan de fichiers à la recherche de malwares, avec alerte en cas de fichier suspect. Sur des sites hébergés chez o2switch où l’on multiplie parfois les plugins, ce garde-fou n’est pas inutile. Il ne remplace pas un audit de Sécurité complet, mais il détecte déjà pas mal de comportements douteux. En complément, il devient très simple de restaurer un état antérieur en un clic, directement depuis une interface web indépendante du WordPress cassé.
La question budgétaire reste évidente. Payer un abonnement mensuel va sembler surdimensionné pour un petit blog personnel. En revanche, dès que le site génère directement du revenu (e-commerce, formations en ligne, abonnement), considérer la sauvegarde comme un coût technique parmi d’autres change le regard. On ne se demande plus si on peut l’éviter, mais quelle combinaison d’outils couvre au mieux le risque sans exploser le budget. Pour certains, un mix UpdraftPlus + Google Drive suffit. Pour d’autres, Jetpack devient une brique incontournable, au même titre qu’un bon module de paiement ou un CDN.
Enfin, ces services externalisés facilitent aussi certains projets de refonte. Quand on prépare une grosse mise à jour de thème, une migration de builder ou un changement de structure de navigation, savoir qu’un snapshot complet temps réel existe réduit la pression. Si la nouvelle version devient un champ de mines, un clic de restauration permet de repartir sur quelque chose de propre. Pour ceux qui envisagent justement de revoir leur site, il peut être utile de coupler cette réflexion à un guide de refonte, comme on en trouve dans des ressources type refonte WordPress étape par étape, où les aspects backup sont intégrés dans la feuille de route.
Cette catégorie d’outils ne remplace pas totalement les solutions plus techniques basées sur wp-cli ou rsync. Elle s’adresse surtout à celles et ceux qui préfèrent externaliser une partie de l’angoisse autour des données. Tant que l’on garde à l’esprit la nécessité de tester au moins une fois la Restauration, ce genre de service payant peut devenir l’allié discret mais décisif des sites WordPress vraiment critiques sur o2switch.
Stratégie complète et erreurs à éviter pour une sauvegarde automatique fiable
Mettre un plugin de Backup et cocher quelques cases ne suffit pas. Une vraie stratégie de Sauvegarde automatique pour un WordPress hébergé chez o2switch ressemble davantage à une routine de sport qu’à un bouton magique : il faut la concevoir, la pratiquer et la réévaluer régulièrement. Sinon, les mauvaises surprises finissent par tomber. Les erreurs classiques reviennent d’ailleurs toujours sous les mêmes formes, quel que soit le niveau technique du propriétaire du site.
La première erreur consiste à ne jamais tester la Restauration. On configure UpdraftPlus ou un autre outil, on voit les archives s’empiler dans Google Drive, et on se rassure. Le jour où un plugin casse tout, on découvre que les fichiers sont incomplets, que la base a été exportée avec un bug, ou que le stockage distant n’a jamais reçu la moindre archive à cause d’une clé d’API mal renseignée. Une seule solution : prévoir un test tous les trois à six mois sur un sous-domaine ou une préprod, en suivant exactement le chemin qui serait utilisé en cas de vrai crash.
La deuxième erreur fréquente survient lorsque l’on ne sauvegarde que la base de données. Ce réflexe vient parfois d’anciens tutoriels qui insistaient sur le contenu dynamique en oubliant les fichiers. Or, un site WordPress repose autant sur sa base (pages, articles, options) que sur ses thèmes, ses plugins et surtout ses médias. Restaurer uniquement la base sur un WordPress fraîchement installé provoque souvent un mélange bancal : pages présentes mais mise en forme cassée, images manquantes, extensions payantes disparues. Une bonne sauvegarde couvre toujours base + fichiers, quitte à segmenter pour optimiser la taille.
Troisième piège : tout stocker au même endroit. La facilité pousse parfois à choisir comme destination de Backup un dossier FTP sur le même compte o2switch, faute de temps pour configurer un Drive ou un S3. Résultat, en cas de piratage massif ou de crash disque lourd, le site et ses sauvegardes partent ensemble. Un peu comme si l’on enfermait tous ses doubles de clés dans le coffre de la voiture. La bonne approche consiste à combiner au moins une copie locale pour les restaurations rapides et une copie distante réellement indépendante.
Le quatrième écueil touche aux fenêtres de sauvegarde. Lancer un transfert de 50 Go en pleine journée avec UpdraftPlus ou un script non optimisé représente une mauvaise idée. La sauvegarde consomme CPU, RAM et bande passante, ce qui peut déclencher des protections automatiques côté o2switch. Le processus se fait tuer, parfois à mi-chemin, laissant des archives incomplètes. Programmer les gros transferts entre 3 h et 5 h du matin, ou les répartir dans la nuit, diminue fortement ce risque. Sur un WordPress très actif en soirée (streams, événements sportifs, etc.), on ajustera évidemment ces horaires.
Pour s’y retrouver, une petite checklist peut rendre la démarche plus concrète. Voici une liste simple à parcourir lorsque l’on met en place ou que l’on révise sa stratégie de sauvegarde sur WordPress :
- Vérifier les sauvegardes natives o2switch et comprendre la durée de rétention.
- Installer un plugin de Backup ou mettre en place un script wp-cli adapté à la taille du site.
- Configurer au moins une destination de stockage distante et indépendante.
- Programmer les horaires en dehors des pics de trafic du site web.
- Planifier un test de Restauration complet sur un environnement de test tous les quelques mois.
En filigrane de tout ça, la Sécurité générale du site joue aussi son rôle. Un WordPress bien mis à jour, avec des plugins triés, un thème maintenu, et une gestion des comptes utilisateur propre, limitera naturellement les risques d’incident. Pour aller plus loin sur ces aspects, certains préfèrent d’ailleurs passer par des prestations régulières de maintenance, dont le tarif reste souvent inférieur au coût d’une seule journée de panne pour un e-commerce. Sur un hébergement o2switch, ce type d’accompagnement permet de mutualiser la veille technique avec d’autres tâches (performance, SEO, petits correctifs).
Une chose ressort clairement de tous les retours de terrain : la Sauvegarde automatique n’est jamais un gadget. Même un petit blog personnel hébergé chez o2switch gagne à disposer d’un minimum de protection, ne serait-ce que pour ne pas perdre des années de billets sur un clic malheureux. À l’autre extrémité, un gros site marchand ne peut plus se permettre d’improviser. Plus la structure grandit, plus cette dimension devient une brique de l’architecture au même titre que la base de données ou le cache.
Les sauvegardes automatiques d’o2switch suffisent-elles pour un site WordPress ?
Elles offrent un premier niveau de sécurité, avec des copies quotidiennes conservées environ 30 jours. Pour un petit site vitrine assez statique, cela peut dépanner. Pour un blog actif ou une boutique WooCommerce, ces backups restent trop limités, surtout en cas de piratage ou de bug présent depuis plusieurs semaines. L’idéal consiste à ajouter une sauvegarde automatique dédiée à WordPress (plugin ou script) avec stockage distant indépendant.
Quel plugin de sauvegarde utiliser sur WordPress avec un hébergement o2switch ?
UpdraftPlus couvre la majorité des besoins : il sait gérer base et fichiers, se connecter à Google Drive, Dropbox, pCloud ou Amazon S3, et permet une restauration assez simple. Sur des sites vraiment volumineux, il peut être judicieux de le compléter par un script wp-cli + rsync ou par une solution temps réel comme Jetpack Backup si le site génère des revenus en continu.
À quelle fréquence faut-il programmer la sauvegarde automatique de WordPress ?
Pour un site vitrine mis à jour rarement, une sauvegarde quotidienne de la base et hebdomadaire des fichiers suffit souvent. Pour un blog régulier, beaucoup visent une sauvegarde base toutes les 4 à 12 heures et fichiers tous les 1 à 2 jours. Sur une boutique WooCommerce, la base doit être sauvegardée plus souvent, parfois en quasi temps réel via un service dédié, afin de ne pas perdre commandes et comptes clients.
Comment tester correctement une restauration de sauvegarde WordPress ?
Le plus sûr consiste à créer un sous-domaine ou un environnement de préproduction sur o2switch, puis à y déployer une copie de la sauvegarde (base et fichiers). On vérifie ensuite que le site se charge bien, que l’administration fonctionne, que les médias s’affichent, et que les extensions critiques tournent sans erreur. Ce test doit suivre au plus près la procédure envisagée pour une restauration en situation réelle.
Faut-il prévoir une sauvegarde automatique lors d’une refonte WordPress ?
Oui, c’est même une des premières étapes. Avant toute refonte majeure (nouveau thème, changement de builder, gros nettoyage d’extensions), il est recommandé de prendre un snapshot complet du site et de l’envoyer sur un stockage externe. Cela permet de revenir en arrière si la nouvelle version pose plus de problèmes que prévu, sans perdre le travail accumulé sur l’ancienne base. Sur o2switch, ce réflexe limite très fortement le stress lors des grands chantiers.
