Sauvegarder WordPress sur le Storage Server : le guide avec WPvivid

Une sauvegarde qui se trouve sur le même serveur que le site n'est pas une sauvegarde. Si le disque est effacé, l'accès détourné ou l'installation chiffrée, elle disparaît avec le reste. Seule une copie sur un stockage séparé constitue une véritable assurance.

Ce guide montre le chemin le plus rapide pour y arriver : un plugin gratuit qui sauvegarde WordPress en SFTP sur un Storage Server, avec planification et règle de conservation. La mise en place prend un quart d'heure.

Pourquoi WPvivid

Le choix est étonnamment réduit sur un point précis. Ce qui compte, c'est une transmission chiffrée dans la version gratuite :

Le FTP simple transmet identifiants et contenus en clair. Pour une sauvegarde qui contient toute la base de données, table des utilisateurs incluse, ce n'est pas une bonne idée. WPvivid est donc le choix évident, il compte plus de 900 000 installations actives et a été mis à jour pour la dernière fois en septembre 2026.

Étape 1 : créer un sous-compte sur le stockage

Dans l'espace client, sous votre Storage Server, créez un sous-compte dédié aux sauvegardes, avec /backup/wordpress comme répertoire de départ. C'est plus important que cela n'en a l'air : les identifiants vont atterrir dans la base de données de WordPress, et celui qui les y trouve ne doit pouvoir atteindre rien d'autre que ce seul répertoire.

Dans la même étape, vérifiez deux options sous « Paramètres d'accès » :

• SSH / SFTP / SCP / rsync doit être autorisé.
• L'accessibilité externe doit être activée, sinon votre serveur web n'atteint pas le stockage par Internet.

Sur les serveurs fraîchement commandés, les deux sont actifs. Notez le nom d'hôte et le nom d'utilisateur, les exemples utilisent ici :

Étape 2 : vérifier la joignabilité avant de configurer quoi que ce soit

Cela épargne beaucoup de recherches plus tard. Si vous avez un accès shell sur le serveur web :

timeout 5 bash -c '</dev/tcp/u123456.storage.kernelhost.net/23' && echo "Port 23 joignable"

Sans accès shell, vous déposez un fichier pruefen.php dans le répertoire web, vous l'appelez une fois et vous le supprimez ensuite :

<?php
$f = @fsockopen('u123456.storage.kernelhost.net', 23, $e, $t, 5);
echo $f ? 'Port 23 joignable' : 'pas de connexion : ' . $t;

Si aucune connexion ne s'établit, votre hébergeur bloque les connexions sortantes sur ce port. Ce n'est pas rare en hébergement mutualisé. Il reste alors soit une demande à l'hébergeur, soit la voie du WebDAV, qui passe par le port 443.

Étape 3 : installer le plugin et enregistrer la destination

Dans l'administration de WordPress, sous Plugins, Ajouter, cherchez WPvivid Backup & Migration, installez-le et activez-le. L'entrée de menu WPvivid Backup apparaît ensuite à gauche.

Là, allez sur l'onglet Remote Storage et choisissez SFTP. Vous remplissez les champs ainsi :

Avec Test and Add, le plugin vérifie la connexion avant de l'enregistrer. Si cela échoue, dans neuf cas sur dix c'est soit le port qui est faux, soit l'accessibilité externe qui est désactivée.

Étape 4 : la première sauvegarde à la main

Sur l'onglet Backup & Restore, vous choisissez Database + Files (WordPress Files) et, comme destination, Send backup to remote storage avec l'entrée que vous venez de créer. Puis Backup Now.

La première exécution prend quelques minutes selon la taille. Laissez la fenêtre du navigateur ouverte pendant ce temps, le plugin pilote la progression par appels répétés.

Étape 5 : planification et conservation

Sur l'onglet Schedule, vous activez la planification. Ce qui a fait ses preuves :

Placez l'heure dans les heures nocturnes de vos visiteurs principaux. La conservation se règle sous Settings, où se trouve aussi l'interrupteur qui décide si les anciennes sauvegardes doivent également être supprimées sur le stockage distant. Activez-le, sinon le stockage se remplit avec le temps.

À noter : les instantanés du Storage Server sont un niveau supplémentaire et travaillent indépendamment de tout cela. Selon l'offre, 10, 20, 30 ou 40 instantanés manuels sont disponibles, plus autant d'instantanés automatiques.

Étape 6 : vérifier que la sauvegarde vaut quelque chose

C'est l'étape la plus souvent sautée, et la plus importante. Regardez ce qui se trouve réellement sur le stockage :

sftp -P 23 u123456-sub3@u123456.storage.kernelhost.net
sftp> ls -l
sftp> bye

Faites attention à deux choses : la taille du fichier doit être plausible, et il doit y avoir à la fois une archive de base de données et une archive de fichiers. Une archive de quelques kilooctets est un échec, pas un succès.

Et ensuite le véritable test : restaurez la sauvegarde une fois sur une installation de test. Une sauvegarde jamais vérifiée est une supposition.

Restaurer, et le hic

Dans la version gratuite, une sauvegarde qui se trouve sur le stockage distant ne peut pas être remise en place directement, la restauration des sauvegardes distantes relève de la version payante. La voie gratuite fonctionne malgré tout et ne prend que quelques minutes de plus :

1. Télécharger l'archive depuis le stockage en SFTP.
2. Dans le plugin, sous Backup & Restore, ouvrir la zone Upload et téléverser l'archive.
3. La sauvegarde téléversée apparaît dans la liste et se restaure depuis là.

Comptez ce détour dans votre plan d'urgence. Qui s'aperçoit pour la première fois en situation réelle qu'un téléchargement s'intercale encore perd du temps inutilement.

Où cette méthode s'arrête

Tout plugin de sauvegarde travaille à l'intérieur de PHP et se heurte donc aux limites de temps et de mémoire. À partir de quelques gigaoctets au total, cela devient laborieux, et avec de très grandes médiathèques l'exécution finit par s'interrompre.

La meilleure voie est alors rsync ou BorgBackup, les deux directement depuis une tâche planifiée sur le serveur et les deux disponibles nativement sur le stockage :

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub3@u123456.storage.kernelhost.net:/dateien/

Cela ne transfère que les modifications et ne connaît aucune limite PHP. Cela suppose toutefois un serveur à soi avec un accès shell. Plus de détails sur cette voie dans Utiliser un Storage Server pour son propre site.

Quelles autres parties de WordPress peuvent être déplacées sur le stockage, donc la médiathèque et les téléchargements, et où se situent les limites, c'est expliqué dans Utiliser un Storage Server avec WordPress.

Les quatre erreurs les plus fréquentes

• Port 22 au lieu de 23. Le plugin propose 22, notre stockage écoute sur 23.
• Accessibilité externe désactivée. Le test depuis l'espace client fonctionne alors, mais pas depuis le serveur web.
• Compte principal au lieu d'un sous-compte. Les identifiants se trouvent ensuite dans la base de données du site. Avec le compte principal, tout en dépend.
• Les anciennes sauvegardes ne sont jamais supprimées. Sans règle de conservation activée pour le stockage distant, l'espace se remplit, et à un moment la sauvegarde échoue en silence.

Quelle offre convient

Pour les sauvegardes d'un seul site WordPress, Storage-1 avec 1 TB pour 9,99 euros suffit très longtemps. Pour situer : un site moyen de 5 GB au total occupe environ 50 GB avec dix sauvegardes conservées, soit cinq pour cent de l'offre.

Tous les Storage Server se trouvent en Allemagne, autorisent jusqu'à 100 sous-comptes, parlent en plus du SFTP aussi SMB, WebDAV, rsync et BorgBackup, et arrivent sans frais de mise en service. La facturation se fait en PrePaid sans durée minimale, vous pouvez donc commencer petit et grandir quand d'autres sites s'ajoutent.