Pourquoi les sauvegardes cPanel natives ne suffisent pas en production
WHM embarque un système de sauvegarde basique qui copie chaque compte sous forme d'archive compressée. Il fonctionne pour une restauration d'urgence complète, mais il lui manque tout ce qu'un serveur de production exige au quotidien : restauration partielle (un seul fichier, une seule table, une seule boîte mail), stockage hors-serveur automatisé, visibilité client sans intervention de l'administrateur et rétention configurable par type de sauvegarde. Sur un serveur qui héberge des dizaines de comptes clients, ces lacunes sont des risques réels : restaurer l'archive complète d'un compte de 20 Go pour récupérer un seul fichier de configuration est à la fois lent et risqué. JetBackup a été conçu pour combler précisément ces écarts.
Ce que JetBackup ajoute au-dessus de cPanel/WHM
- Sauvegardes granulaires : chaque compte est sauvegardé indépendamment ; la restauration cible un fichier, un répertoire, une base de données ou une boîte mail sans toucher au reste.
- Restauration en libre-service : chaque utilisateur cPanel retrouve ses propres sauvegardes dans son interface, sans ouvrir de ticket — le support de premier niveau disparaît pour ce cas.
- Destinations multiples simultanées : local, SFTP/SSH, S3-compatible (AWS, Wasabi, Backblaze B2), FTP — chaque job peut envoyer vers plusieurs destinations en parallèle.
- Sauvegardes incrémentielles : seules les différences sont transférées entre deux passes, ce qui réduit la bande passante et le temps d'exécution de 60 à 90 % après la première passe complète.
- Planification avancée : quotidien, hebdomadaire, mensuel, avec des règles de rétention distinctes par destination et par type.
- Tableau de bord WHM centralisé : l'administrateur voit l'état de chaque job, les derniers résultats et les quotas consommés sans quitter WHM.
- Restauration test sans impact : JetBackup peut restaurer dans un répertoire temporaire pour valider l'intégrité sans écraser la production.
- Transfert de compte assisté : migration d'un compte d'un serveur vers un autre à partir d'une sauvegarde JetBackup, sans accès SSH direct au serveur source.
Prérequis avant l'installation
JetBackup requiert un accès root WHM sur un serveur cPanel sous AlmaLinux 8/9 ou CloudLinux 8/9 (les versions antérieures CentOS 7 ne reçoivent plus de mises à jour JetBackup 5). Un espace disque d'au moins deux fois la taille des données à sauvegarder est recommandé pour la destination locale — moins si vous ne conservez que les destinations distantes. La licence JetBackup est vendue par IP de serveur et activée via le portail JetApps ; elle est distincte de la licence cPanel/WHM.
Installer JetBackup via WHM
Vérifier la version de cPanel/WHM
Connectez-vous à WHM, rendez-vous dans Server Information et notez la version cPanel. JetBackup 5 exige cPanel 110 ou supérieur. Si la version est antérieure, lancez d'abord la mise à jour cPanel depuis Upgrade to Latest Version.
Lancer le script d'installation JetApps
En SSH root, exécutez le script officiel de JetApps : curl -fsSL https://repo.jetlicense.com/centOS/jetapps-installer.sh | bash. Ce script dépose le gestionnaire de paquets JetApps, qui sert à installer et mettre à jour tous les produits Jet.
Installer le paquet JetBackup
Une fois JetApps en place : jetapps --install jetbackup5-cpanel. L'installateur configure les dépendances, enregistre le plugin dans WHM et démarre le service jetbackupd. La durée varie entre 2 et 5 minutes selon la connexion.
Enregistrer la licence
Dans WHM, allez dans JetBackup 5 → Dashboard. Si la licence n'est pas automatiquement détectée, saisissez la clé fournie par JetApps ou renseignez l'IP du serveur dans votre espace client JetApps. La vérification est instantanée ; sans licence valide, les jobs restent inactifs.
Configurer la première destination de sauvegarde
Dans JetBackup 5 → Backup Destinations, cliquez sur Add Destination. Pour commencer, choisissez Local et pointez vers un répertoire dédié (par exemple /backup/jetbackup), distinct du répertoire WHM par défaut. Activez l'option Test Connection pour vérifier que le service peut écrire dans ce répertoire.
Créer le premier job de sauvegarde
Dans JetBackup 5 → Backup Jobs, cliquez sur Create New Job. Sélectionnez le type Accounts (pour sauvegarder des comptes cPanel complets), choisissez la destination configurée à l'étape précédente, réglez la planification (par exemple : quotidien à 02 h 00) et définissez la rétention (7 copies quotidiennes). Enregistrez. Le premier job partira à l'heure planifiée, ou vous pouvez le lancer manuellement avec Run Now pour vérifier le bon fonctionnement.
Configurer les destinations de sauvegarde
JetBackup prend en charge plusieurs types de destinations. Le choix dépend de votre tolérance aux pannes, de votre budget et de la bande passante disponible.
Comparatif des destinations JetBackup
| Destination | Avantages | Points d'attention |
|---|---|---|
| Local (même serveur) | Restauration rapide, aucun coût réseau | Données perdues si le disque ou le serveur tombe — ne jamais utiliser seul en production |
| SFTP/SSH | Chiffré par défaut, compatible tout serveur Linux, authentification par clé | Débit limité par la connexion SSH ; configurer une clé dédiée sans accès shell complet |
| S3-compatible (AWS, Wasabi, Backblaze B2) | Stockage objet hors-site, rétention fine, coût prévisible | Nécessite un bucket et des credentials IAM avec les droits `s3:PutObject`, `s3:GetObject`, `s3:ListBucket` |
| FTP | Simple à mettre en place sur des NAS ou des hébergements mutualisés anciens | Non chiffré par défaut (FTPS recommandé) ; éviter si le serveur FTP est sur le même réseau physique |
Planification et rétention
JetBackup distingue trois fréquences de job : Daily (quotidien), Weekly (hebdomadaire) et Monthly (mensuel). La bonne pratique est d'empiler les trois : un job quotidien vers la destination locale (rétention 7 jours), un job hebdomadaire vers S3 (rétention 4 semaines) et un job mensuel vers une destination d'archivage long terme (rétention 12 mois). Cette pile couvre à la fois les erreurs détectées rapidement (fichier supprimé hier) et les corruptions silencieuses découvertes des semaines plus tard. Les rétentions sont indépendantes par job et par destination — un job mensuel sur S3 peut conserver 12 copies alors que le job quotidien local n'en garde que 3, selon l'espace disponible. JetBackup applique les règles de rétention automatiquement à la fin de chaque job réussi : les copies au-delà de la limite sont supprimées, jamais dans le désordre (c'est toujours la plus ancienne qui part en premier).
Durcissez votre configuration dès le départ
Pour la destination SFTP, créez un utilisateur système dédié avec un répertoire restreint (chroot) et une clé SSH sans mot de passe — ne jamais réutiliser les identifiants root. Pour S3, créez une politique IAM minimale : s3:PutObject, s3:GetObject, s3:DeleteObject et s3:ListBucket sur le seul bucket de sauvegarde. Enfin, planifiez un test de restauration mensuel : choisissez un compte de test, restaurez une archive vieille d'une semaine dans un répertoire temporaire et vérifiez l'intégrité des fichiers. Une sauvegarde non testée est une promesse, pas une garantie.
Restauration : comptes, bases de données et e-mails séparément
C'est ici que JetBackup se distingue le plus clairement de la sauvegarde WHM native. Dans JetBackup 5 → Restore, vous choisissez le type d'objet à restaurer : Account (compte complet), Home Directory (fichiers uniquement), Database (une base MySQL isolée), Email (une boîte mail ou un seul message), Cron Jobs, DNS Zone ou SSL Certificate. Chaque restauration peut se faire vers l'emplacement d'origine (écrase l'existant) ou vers un répertoire temporaire pour inspection préalable. Du côté client, l'interface cPanel expose un sous-menu JetBackup avec exactement les mêmes options, restreintes aux données du compte : un utilisateur peut récupérer un fichier supprimé à 14 h sans appeler le support, ce qui transforme une interaction de ticket en autonomie client.
Dépannage : erreurs courantes
Voici les erreurs les plus fréquentes rencontrées lors de la mise en production de JetBackup, avec leur cause et leur remédiation.
Erreurs et solutions
- Espace disque insuffisant au démarrage du job : JetBackup vérifie l'espace libre avant de démarrer. Si la destination locale est pleine, le job est annulé avec le message
Not enough disk space. Augmentez l'espace ou réduisez la rétention (moins de copies). L'option Disk Usage Limit dans les paramètres de destination permet de bloquer JetBackup avant d'atteindre 100 % du disque. - Destination SFTP refusée (Permission denied) : vérifiez que la clé publique est bien dans
~/.ssh/authorized_keysde l'utilisateur SFTP côté serveur cible, que les permissions du répertoire de destination sont 700 et que le servicesshdaccepte l'authentification par clé (PubkeyAuthentication yesdanssshd_config). Utilisez le bouton Test Connection de JetBackup pour diagnostiquer sans lancer un job complet. - Destination S3 : erreur 403 Forbidden : la cause est presque toujours une politique IAM trop restrictive ou un nom de bucket incorrect. Vérifiez que la clé IAM a les droits
s3:PutObjectets3:ListBucketsurarn:aws:s3:::nom-du-bucket/*. Pour Backblaze B2 ou Wasabi, assurez-vous que l'endpointde la destination est bien configuré (les endpoints S3-compatibles varient par fournisseur et par région). - Restauration bloquée (job en état Pending indéfiniment) : le service
jetbackupdest peut-être arrêté ou surchargé. Vérifiez son état avecsystemctl status jetbackupdet, si nécessaire, redémarrez-le avecsystemctl restart jetbackupd. Un job précédent qui n'a pas été terminé proprement peut aussi bloquer la file — annulez-le manuellement dans le tableau de bord JetBackup. - Sauvegardes manquantes après migration de serveur : JetBackup stocke les métadonnées des sauvegardes dans une base locale (
/usr/local/jetapps/var/lib/jetbackup5/). Après une migration, ces métadonnées ne suivent pas automatiquement. Utilisez la fonction Import Backups pour réindexer les archives existantes depuis les destinations configurées.
JetBackup dans l'écosystème cPanel/WHM
JetBackup s'intègre naturellement avec les autres outils de l'écosystème cPanel. Sur un serveur CloudLinux, l'isolation LVE s'assure qu'un job de sauvegarde intensif ne pénalise pas les autres comptes. Imunify360 (même éditeur, CloudLinux) détecte les fichiers malveillants avant leur sauvegarde — utile pour ne pas archiver une infection. Les comptes WHM bénéficient des mêmes sauvegardes granulaires que les comptes cPanel : un revendeur peut restaurer ses propres configurations DNS, certificats SSL et jobs cron indépendamment de ses clients. Enfin, la fonctionnalité de transfert de compte assisté de JetBackup simplifie les migrations entre serveurs cPanel : au lieu de dépendre du Transfer Tool natif de WHM (qui copie en direct, sans passer par une archive préexistante), JetBackup restaure à partir d'une sauvegarde stockée hors-site — ce qui réduit le risque d'interruption et laisse l'ancien serveur intègre jusqu'à validation.
