Oxahost ou Nindohost pour restaurer un WordPress sur une copie à accès limité

Déléguer la reprise sans donner l’accès à la production

Une petite structure francophone veut vérifier sa dernière sauvegarde WordPress après une erreur de maintenance. Le responsable du compte garde les accès à l’hébergeur. La personne chargée de la recette reçoit les fichiers nécessaires et un export de base. Elle peut écrire dans une destination privée, à condition que cette destination soit distincte du WordPress public. Le résultat attendu est une page dont le texte et le média correspondent au même point, puis une modification témoin qui n’apparaît que dans la copie.

Trois droits doivent être distingués. Il faut pouvoir récupérer une copie chez l’hébergeur, pouvoir lire les fichiers et le SQL remis, puis pouvoir écrire sur la destination. La personne qui importe les données n’a pas besoin de piloter les sauvegardes de tout le compte, le DNS ou les boîtes de réception. Si le panneau ne permet pas de déléguer exactement les droits nécessaires, le titulaire exécute lui-même l’extraction. Il transmet ensuite les deux éléments par le circuit prévu par l’équipe.

Commencez par un dossier privé et une base vide, avec des identifiants propres à la destination. Les tâches automatiques, les formulaires, les webhooks et les relais sortants doivent rester coupés durant l’essai. Vérifiez la protection avec une requête sans accès et une autre autorisée. Un site accessible en connaissant son URL reste public, même si l’indexation a été désactivée.

Définir ce qu’un point de sauvegarde doit fournir

WordPress s’appuie sur des fichiers et sur une base. Les médias, le thème et les extensions résident dans les fichiers. Les contenus, les options et les références vers les médias se trouvent en base. Pour une reprise après une mise à jour, vérifiez aussi les versions du code. Un SQL importé avec succès peut renvoyer vers des fichiers absents ou une version d’extension qui ne comprend pas ses données.

Pour chaque pièce, notez l’offre, l’instance, le périmètre, l’heure et le fuseau du point choisi. Si les fichiers et la base ont été capturés séparément, vérifiez leur cohérence à l’aide d’un média récent et de la page qui l’utilise. L’empreinte permet de vérifier la copie des octets reçus. Elle ne confirme pas à elle seule la cohérence d’un point ou l’exhaustivité d’une sauvegarde.

Demandez un format que le technicien peut relire et importer sans retourner dans le panneau de production. Vérifiez l’archive avant de la transmettre. Écartez les identifiants de production, les archives inutiles et les données personnelles qui ne servent pas au test. Donnez un identifiant à la paire fichiers et base. Un fichier manquant ou une paire incohérente doit entraîner un arrêt avant l’écriture dans la recette.

Oxahost WP Basic et la copie annoncée dans l’offre

WP Basic annonce deux instances WordPress, 10 Go SSD et 1 Go de RAM, avec un gestionnaire de fichiers, WP Clone et des snapshots. Ces caractéristiques rendent plausible un essai sur le même compte si une place reste libre. Mesurez l’espace des fichiers, de la base et du point temporaire avant de lancer la copie. L’annonce de deux instances ne prouve pas que le technicien puisse avoir un accès limité à une seule, ni que la copie soit privée au moment de sa création.

La FAQ WordPress annonce, pour tous les forfaits de cette gamme, des snapshots quotidiens conservés hors site pendant 30 jours et une restauration en un clic. Elle ne détaille pas le téléchargement séparé du média et du SQL, la destination d’un snapshot, le nombre de points disponibles sur WP Basic ou les droits requis pour les extraire. L’offre mutualisée cPanel Oxahost documente JetBackup, mais ses menus ne sont pas une preuve pour le produit WordPress étudié. Le titulaire doit obtenir les deux pièces exportables ou convenir de leur extraction avec le support avant de déléguer la recette. Les conditions générales décrivent une fréquence généralement hebdomadaire ou mensuelle et une rétention indicative de 30 à 90 jours selon l’offre, sans garantie de restauration. Demandez quels points sont effectivement accessibles pour WP Basic et vérifiez les droits d’export.

Le site WordPress annonce un hébergement à Tunis, avec une exception si une option externe est choisie. Le lieu des copies doit être vérifié séparément. L’aide et le contact sont disponibles en français. Le centre d’aide annonce le chat en continu et des canaux techniques. Confirmez le canal et la langue d’une intervention particulière. Les conditions recommandent au client de garder ses propres sauvegardes et d’en tester la reprise. Une sauvegarde du fournisseur ne dispense donc pas de vérifier les fichiers remis.

Nindohost Go Site et les outils documentés dans cPanel

Go Site annonce cPanel, WordPress Toolkit Deluxe, un site, 25 Go SSD, cinq adresses électroniques et une sauvegarde quotidienne. Le guide de restauration Nindohost décrit JetBackup dans cPanel. Pour des fichiers, il montre la sélection d’un point et d’éléments à restaurer, puis la mise en file. Pour une base, il décrit le téléchargement d’une copie depuis la liste. Vérifiez que ces écrans sont présents pour le compte Go Site. Le guide ne fixe pas une durée de rétention applicable à cette offre WordPress.

Le statut Completed indique que la tâche s’est achevée. Il ne démontre pas que la destination était une copie. Avant toute action Restore sur des fichiers, identifiez le chemin et vérifiez si elle écrase les fichiers actifs. Le guide de base permet de télécharger la pièce puis de préparer un import via phpMyAdmin. L’aide décrit la création d’une nouvelle base et l’import MySQL. Si le compte ne propose pas la destination voulue, demandez les éléments au titulaire ou au support et restaurez ailleurs. Les conditions demandent de faire générer la sauvegarde par le support si un compte mutualisé dépasse 15 Go. Si cette clause s’applique au compte Go Site, prévoyez le délai d’intervention. Gardez les archives sur un stockage séparé.

Le forfait annonce un seul site. L’accès à Toolkit Deluxe ne suffit pas à établir qu’un clone complet et indépendant est autorisé dans ce quota. Une destination séparée permet de poursuivre si le compte ne le permet pas. Nindohost publie une aide en français et une page d’offre en anglais. Le téléphone et les tickets sont annoncés, avec le ticket accessible en continu selon les conditions. La FAQ WordPress indique des serveurs au Maroc, sans établir le centre du compte ni l’emplacement de toutes ses copies.

Comparer les périodes et le coût de la destination de test

Pour Oxahost, le repère retenu est le cycle public de trente-six mois affiché à 455,94 TND HT pour WP Basic, soit 12,665 TND HT par mois en équivalent. La carte affiche aussi trois mois offerts. Confirmez leur place dans la date de fin et le prochain cycle. Selon la page de facturation, à 19 % de TVA, le total indicatif est de 542,569 TND après arrondi au millime. Si le timbre de 1 TND s’applique, l’exemple atteint 543,569 TND. Vérifiez la devise et les frais du compte avant de retenir un montant.

Les conditions Oxahost décrivent une reconduction de durée équivalente selon le tarif applicable et la facturation annonce une facture de renouvellement quatorze jours avant l’échéance. Le montant récurrent précis ne découle pas de l’équivalent promotionnel affiché. Vérifiez la date et le total de reconduction, le domaine inclus la première année et son éventuel prix à l’échéance. Une recette sur un autre compte ou un autre hébergement augmente le budget si le quota du plan est atteint.

Nindohost affiche 79 MAD par mois pour Go Site. Les conditions générales présentent les prix publics hors taxes. La carte ne précise pas le cycle réellement proposé ni le total avec taxes. Douze fois le prix affiché donnent un repère de 948 MAD avant taxes selon cette lecture, sous réserve du prix et du cycle proposés. Ce calcul ne constitue pas un devis annuel. L’aide décrit une facture générée quinze jours avant la fin si l’option de renouvellement est activée, puis un renouvellement sous condition de paiement. Vérifiez le montant au récapitulatif. Cette option génère la facture. L’aide précise que la seule présence d’une carte enregistrée ne déclenche pas le paiement.

Remettre au technicien des pièces qu’il peut contrôler

Le titulaire prépare la récupération des fichiers et du SQL. Il note le nom de la base et vérifie l’application associée avant export. Le technicien reçoit les pièces et un relevé qui décrit l’identifiant de point, les fichiers attendus, les empreintes et le format du SQL. Ne placez pas dans le paquet les identifiants de production, les jetons d’envoi ou un export de tout le compte s’ils ne sont pas nécessaires. Vérifiez les personnes autorisées à le lire et la durée pendant laquelle il doit rester disponible.

Le compte de recette doit permettre l’écriture dans un répertoire et une base attribués. Validez la destination par son nom, son chemin et un marqueur. Vérifiez le format de la base, son moteur et ses limites d’import. Si un fichier est trop lourd pour l’interface, faites préparer une méthode autorisée ou demandez au titulaire de traiter cette étape. Un droit sur les fichiers seul ne permet pas d’importer le SQL. Un droit sur la base seul ne fournit pas les médias et le code.

Ne transmettez pas le mot de passe principal du compte pour éviter une demande de support. Si une action exige les droits du titulaire, consignez l’action et le résultat attendu. Faites vérifier une empreinte et une copie lisible après le transfert. Un refus parce qu’une pièce manque doit rester visible dans le procès-verbal. Il vaut mieux reporter la recette que compléter la paire avec un fichier pris à une autre date sans contrôle.

Rejouer les arrêts avant toute écriture

La maquette fournit une archive de fichiers et une archive SQL de même point, puis deux variantes de base incompatibles. Le script lit les manifestes, vérifie l’empreinte de chaque pièce et exécute réellement le SQL dans SQLite en mémoire. Il compare ensuite la référence enregistrée en base et le fichier média. Le nom de destination est vérifié avant tout travail. Une production ou une recette existante est refusée pour préserver les témoins de l’essai. Dans le dossier extrait du ZIP, lancez « python -X utf8 exercice.py » et comparez le rapport à « attendu.json ».

Six arrêts sont vérifiés. La maquette refuse la production, l’absence du SQL, une empreinte altérée, deux points différents, une référence de média incohérente et un fichier hors du périmètre de l’archive. Dans le cas du média incohérent, les manifestes annoncent pourtant le même point. Les contrôles sur le contenu de la base complètent donc ceux sur les manifestes. Aucun des refus ne laisse une recette partielle. L’échec peut être communiqué au titulaire en indiquant la pièce à récupérer de nouveau.

Lorsque la paire est correcte, le script crée le média et une vraie base SQLite de recette, puis modifie l’adresse fictive et vérifie l’intégrité. Il écrit un titre témoin sur la copie. Un retour repart de la même paire dans un deuxième dossier. Le premier essai et le fichier témoin de production restent lisibles et inchangés pendant cette reconstruction. Le test s’exécute entièrement hors ligne et n’interprète que le SQL fictif fourni. Ses contrôles ne valident pas les permissions d’un vrai panneau.

Vérifier la copie WordPress avant de la déclarer utilisable

Sur la destination réelle, relevez la bonne URL, la racine et le nom de la base. Vérifiez que WordPress et ses extensions utilisent ces valeurs. Un remplacement d’adresse dans des réglages sérialisés demande un outil compatible et une sauvegarde. Évitez de transposer automatiquement le fichier de configuration avec ses secrets. Préparez des identifiants distincts et vérifiez que le technicien ne peut pas atteindre la production à partir de son accès de recette.

Contrôlez la page témoin, l’image avec son URL effective et l’accès à l’administration. Vérifiez les données à une date connue, le statut des extensions et la possibilité d’écrire un changement inoffensif dans la copie. Dans le même temps, relisez le témoin public depuis son accès normal. Si un ancien cache donne un résultat trompeur, identifiez la couche puis confirmez les valeurs sur une réponse non réutilisée. Testez que le formulaire de recette n’envoie pas de données à un destinataire réel.

Consignez les preuves dans un relevé minimal. Indiquez le point choisi, les pièces contrôlées, l’URL de recette, les droits utilisés et le résultat du témoin. Notez séparément ce que le titulaire a dû faire. Une restauration automatique qui finit dans le panneau ne suffit pas à elle seule. La recette est validée quand la page, le média et l’écriture correspondent tous à la destination attendue et que l’état public est toujours lisible.

Décider de poursuivre ou de reconstruire la recette

Si une pièce ou un droit manque, arrêtez et demandez précisément l’export attendu. Si le média et le SQL ne correspondent pas, demandez un point cohérent. Une incohérence peut aussi provenir d’un chemin qui change selon l’environnement. Vérifiez alors les références, le nom du fichier et le stockage utilisé avant de modifier la paire. Si vous découvrez une écriture sur la production, interrompez l’essai et conservez le journal et les données concernées avant d’envisager une correction.

Pour revenir en arrière sur la recette, conservez l’essai qui a échoué tant que vous avez besoin de son journal. Réimportez un point vérifié dans une nouvelle destination autorisée, puis refaites les mêmes contrôles. Toute restauration d’un site public suit un autre accord et doit tenir compte des contenus arrivés après le point choisi. Le dossier n’utilise aucun réglage DNS et ne suppose aucune mise en ligne.

WP Basic est un candidat si la copie annoncée et les exports nécessaires sont disponibles avec les droits du titulaire. Go Site est un candidat si l’équipe préfère un parcours cPanel documenté et dispose d’une destination indépendante quand le quota l’exige. Le critère décisif est la capacité de remettre deux pièces réutilisables et de prouver que la restauration reste confinée à la recette. Le coût d’un compte de test ou le délai d’un ticket fait partie de ce choix.

Pour aller plus loin

• Consulter la fiche Oxahost
• Consulter la fiche Nindohost
• Comparer les outils de sauvegarde WordPress
• Télécharger la maquette de restauration à accès limité (ZIP)