alwaysdata ou Infomaniak pour revenir à la base WordPress après une restauration

Rétablir un article et garder une voie de retour

Une association a perdu la version attendue d’une page WordPress après une intervention éditoriale. Elle dispose d’une sauvegarde de la base datant de la veille. Les fichiers, le thème et les extensions ont déjà été vérifiés et une copie privée du site est disponible. L’équipe veut savoir si cette sauvegarde permet de retrouver le contenu, puis démontrer qu’elle peut remettre la copie sur sa base de départ. La recette reste isolée et les données utilisées pour l’essai sont fictives ou préparées pour cet usage.

Le propriétaire du compte conserve les droits de restauration et de configuration. Une autre personne reçoit uniquement un identifiant SQL autorisé à lire les deux bases de la recette. Elle vérifie les témoins et signe le résultat. Cette séparation limite l’impact d’une erreur de vérification. Elle rend aussi visible un problème fréquent dans une recette, où une page s’affiche alors que le site pointe encore vers l’ancienne base.

Appelez A la base courante de la copie et B la base candidate issue de la sauvegarde. Préservez A pendant l’import et pendant la lecture de B. Le test commence sur A, passe à B, puis retourne sur A. À chaque étape, exigez une preuve de la cible et une preuve du contenu. Si une écriture est arrivée sur B pendant la fenêtre d’essai, suspendez le retour jusqu’à ce que son sort ait été décidé.

Attribuer les droits aux trois usages

Le titulaire de l’hébergement crée les bases et lance l’import. Il choisit une cible vide qui ne partage ni son nom ni ses identifiants d’écriture avec A. Le compte de lecture est distinct de celui de WordPress. Le vérificateur doit pouvoir lire la page attendue et l’identifiant de la base, sans ouvrir le panneau d’administration du compte, créer des objets SQL ou importer un fichier. Il n’a aucun droit sur la base du site public ni sur les autres sites du forfait.

WordPress utilise un compte d’application propre à la destination. Ses besoins sont différents de ceux de la vérification. Des opérations normales, notamment la gestion des options, des sessions ou des extensions, peuvent écrire dans la base. Sur la copie, maîtrisez les écritures en bloquant l’usage éditorial et en désactivant les tâches ou intégrations susceptibles d’en produire pendant le test. Une simple page ouverte dans le navigateur ne garantit pas que le site n’écrit rien.

Le droit de lecture donne accès aux données du périmètre accordé. Une base WordPress peut contenir des adresses, des formulaires ou des réglages confidentiels. Si l’auditeur n’a besoin que de quelques témoins, préparez une recette nettoyée ou faites relever ces témoins par le titulaire. Transmettez des résultats identifiés plutôt qu’un export complet. Après la séance, retirez le droit temporaire et vérifiez le résultat en ouvrant une nouvelle connexion autorisée pour ce contrôle.

alwaysdata Small, remettre un fichier de sauvegarde à un opérateur

Small annonce 50 Go SSD, 1 Go de mémoire et un CPU. Les bases et les sites sont annoncés sans limite de nombre. Le disque couvre les fichiers, les e-mails et les bases. Vérifiez la place pour A et B, ainsi que pour le fichier temporaire si l’opérateur le copie dans le compte. Les sauvegardes gérées par alwaysdata sont hors quota. Une copie que l’opérateur dépose dans le stockage courant doit être budgétée séparément.

La documentation MariaDB propose trois niveaux par base et par utilisateur, tous les droits, lecture seule et aucun droit. Elle avertit qu’une validation via l’interface ou l’API remet les permissions dans les états prévus par le panneau si elles ont été modifiées avec un autre outil. Pour une recette reproductible, enregistrez les droits depuis l’interface et vérifiez-les après la création de B. Donnez la lecture sur A et B et aucun droit sur le reste au compte de vérification. Le compte qui importe a les droits nécessaires sur B uniquement.

alwaysdata expose les sauvegardes quotidiennes en lecture seule dans le compte, sous forme de fichiers SQL compressés en Zstandard pour MariaDB. Le titulaire peut récupérer l’archive datée et l’importer dans une base B créée séparément. Il note la date du dossier, le fichier sélectionné et la destination avant l’import. Le simple compte SQL de vérification ne reçoit pas un accès SSH au répertoire des sauvegardes. Si personne dans l’équipe ne peut préparer l’archive ou gérer un import, cette voie documentaire ne suffit pas à organiser l’intervention.

Le panel propose aussi Avancé puis Restauration de sauvegardes. Le titulaire choisit une date et coche la base à restaurer. La documentation avertit que cette opération écrase les données en place. Pour garder A disponible pendant la comparaison, utilisez l’archive SQL datée et dirigez l’import manuel vers B. Relevez les dates des fichiers et du SQL si la recette dépend de médias ajoutés depuis la sauvegarde.

La grille Small et la documentation technique annoncent sept jours glissants. Les conditions du mutualisé, à l’article 4.6, mentionnent trente jours. Pour planifier un exercice sur Small, retenez la fenêtre visible de sept jours et confirmez par écrit la rétention applicable au contrat. La fiche de contact indique le support depuis l’interface d’administration et le téléphone pour les demandes commerciales aux heures ouvrées. L’aide existe en français et en anglais. Le ticket urgent réservé aux serveurs Dédié et Gold ne fait pas partie de Small.

Infomaniak Hébergement Web, créer la cible depuis le Manager

L’Hébergement Web mutualisé affiche 250 Go SSD et vingt sites PHP inclus dans sa configuration de départ, avec des bases MySQL ou MariaDB annoncées sans limite de nombre. Le Manager sépare la gestion des bases et celle des utilisateurs. Son aide décrit la lecture avec SELECT, l’écriture avec un groupe distinct de privilèges et l’administration avec les opérations de structure. Certains droits sur les routines, les déclencheurs ou les événements sont réservés au Serveur Cloud. Un compte auquel aucune permission n’est accordée sur une base ne la voit pas dans phpMyAdmin selon le guide.

Le guide d’import documente une source choisie parmi les sauvegardes automatiques ou parmi les fichiers. Le titulaire peut cibler une nouvelle base ou remplacer une base existante. Sélectionnez la création pour B. Pour un fichier envoyé depuis le poste, la limite documentée est de 300 Mo. Au-delà, le guide prévoit un fichier déposé sur l’hébergement hors des répertoires publics ou une méthode SSH. Pour l’import SSH, préparez B et les droits d’import avant d’établir la connexion. Il avertit que des vues ou déclencheurs peuvent demander un traitement. S’ils sont utilisés par une extension, vérifiez les objets nécessaires et les droits disponibles avant de choisir le mutualisé.

Le guide de restauration avancée décrit la date souhaitée, la date de sauvegarde la plus proche affichée et un courriel de fin d’opération. Le courriel atteste la fin de la tâche, puis le titulaire contrôle le nom de la cible, l’intégrité et les témoins. L’offre présente une remontée jusqu’à sept jours et une sauvegarde dans un autre centre suisse. La durée d’import dépend de la taille et du mode choisi. Aucune durée d’exécution n’a été mesurée pour cette comparaison.

La page d’assistance annonce le téléphone du lundi au vendredi de 9 h à 18 h, le chat du lundi au vendredi de 6 h à 19 h et l’e-mail sept jours sur sept de 6 h à 21 h au relevé. Le centre d’aide est disponible en français et l’assistance est présentée comme multilingue. Les conditions de l’Hébergement Web excluent les demandes relevant du développement du site. Le Manager automatise l’exécution de l’import choisi par le titulaire. L’équipe WordPress garde la validation des données, de la cible et du retour.

Comparer la facture dans sa devise et son cycle

alwaysdata Small coûte 6 EUR HT au paiement mensuel ou 5 EUR HT par mois en paiement annuel, soit 60 EUR HT pour douze mois. Au taux normal français de 20 % s’il s’applique à la facture, les exemples sont 7,20 EUR TTC pour un mois et 72 EUR TTC pour l’année. Les trente jours offerts figurent sur la page d’offre. Faites préciser leur effet sur le premier paiement et la date du prochain cycle. Les montants cités excluent le coût éventuel d’un second compte de recette.

Les conditions d’hébergement mutualisé alwaysdata décrivent une durée minimale d’un mois ou d’un an après la phase d’initialisation selon le forfait, puis une reconduction de durée égale. L’article 7 prévoit une dénonciation par lettre recommandée avec avis de réception au moins un mois avant la date anniversaire. Vérifiez la date et les modalités applicables dans le contrat affiché dans Abonnements. L’aide de facturation distingue la suppression du compte avant échéance, sans remboursement, et l’accès aux contrats. Le prix futur est à confirmer.

Pour Infomaniak Hébergement Web, la grille consultée affiche un tarif de départ de 10,91 CHF HT par mois et une facturation annuelle par défaut. Une facture mensuelle ou trimestrielle peut être accessible selon le montant de la configuration. Douze mois au prix affiché correspondent à 130,92 CHF HT. Avec le taux normal suisse de 8,1 % s’il s’applique à l’organisation, cela représente environ 141,52 CHF TTC sur cette base. Le montant du panier, la fiscalité et la devise dépendent de l’organisation. Les conditions générales distinguent le prix facturé selon l’adresse et le statut. Les montants en CHF correspondent au repère suisse.

Infomaniak annonce trente jours gratuits avec une carte valide pour démarrer l’essai. Les conditions générales prévoient une première tentative de débit quatorze jours avant la fin de l’essai si le service est conservé. Vérifiez cette date dès l’inscription. Elles prévoient aussi l’activation du renouvellement automatique par défaut si le moyen de paiement le permet. Pour un moyen de paiement valide associé, la première tentative a lieu quatorze jours avant l’échéance lorsque le renouvellement automatique s’applique. Le tarif facturé est celui en vigueur au moment de la facturation. Vérifiez le montant de la facture de renouvellement et le mode de paiement dans le Manager.

Préparer les deux preuves avant de changer la connexion

Sur A, relevez un article dont l’identifiant reste stable et un contenu ajouté après la sauvegarde. Notez un marqueur que l’on ne retrouve pas sur B, par exemple un identifiant de recette conservé dans un journal d’essai ou un objet synthétique créé pour la séance. Le titre d’un article commun aux deux bases est un mauvais témoin de cible. Il peut s’afficher sur les deux copies. Conservez la preuve du nom de la base effectivement sélectionnée par la connexion, vérifiée par l’opérateur via un outil privé.

Sur B, contrôlez la présence de la page à récupérer et la version exacte du passage attendu. Vérifiez que le jeu de caractères, le préfixe des tables et les paramètres de site correspondent à la copie. Si le site contient des données sérialisées ou plusieurs langues, le titulaire prépare une adaptation sûre des URL et vérifie que la copie ne redirige pas vers le site réel. Les médias et le code ont été vérifiés au départ. Si ce prérequis manque, un import SQL seul ne couvre pas la reprise du site.

Documentez une fenêtre d’essai et ses seuils. Par exemple, accordez dix minutes pour la remise sur A à partir de la décision de retour, dont deux lectures réussies après le changement. Notez le fuseau, les dates de sauvegarde et les instants de vérification. Mesurez à part le temps nécessaire à l’import de B. Ce relevé distingue le temps de préparation du temps d’interruption acceptable, avec des objectifs adaptés au site.

Basculer la recette, puis vérifier qu’elle revient réellement sur A

Le titulaire garde une copie protégée du profil de connexion initial. Sur une installation WordPress classique, les paramètres de base se trouvent dans wp-config.php ou sont injectés par l’environnement. Relevez le nom de la base, l’hôte, l’utilisateur d’application et le préfixe des tables. Conservez les secrets dans le mécanisme prévu pour cet usage. Le compte de lecture ne reçoit que son propre identifiant. Vérifiez que les deux profils pointent vers la recette et qu’aucune route publique ne reçoit ce changement.

Sur la copie, appliquez le profil B et contrôlez une connexion fraîche. Relevez la cible avec l’outil de contrôle privé, puis la page restaurée via le site. Un cache de page ou d’objets peut masquer la bascule. Contournez ou réinitialisez le cache de la copie pour la vérification et contrôlez l’absence de redirection vers l’adresse publique. Confirmez séparément, par le compte SQL de lecture, que B contient la révision attendue. Une requête de lecture dans phpMyAdmin ne suffit pas à prouver quelle base WordPress utilise.

Avant le retour, vérifiez si B a reçu des écritures utiles depuis l’ouverture de l’essai. Cela inclut les inscriptions, formulaires et tâches automatiques, selon le site. Si la réponse est incertaine, gardez les deux bases et suspendez le changement le temps d’établir ce qui doit être conservé. Si la fenêtre est restée sans écritures à préserver, réappliquez le profil A. Rouvrez une connexion et contrôlez que le marqueur A et le contenu récent réapparaissent. Puis vérifiez que B reste disponible pour l’analyse et révoquez l’accès d’audit à la fin.

Rejouer les contrôles dans une maquette hors ligne

L’exercice livré crée deux bases SQLite à partir de jeux locaux, avec une base hors périmètre. Il ouvre les bases A et B en lecture seule pour l’auditeur. Une écriture de contrôle échoue réellement dans SQLite sur la base de recette. Un garde de la maquette refuse la troisième base avant l’ouverture. Les privilèges réels de MariaDB, du Manager et du panneau alwaysdata doivent être vérifiés séparément sur une recette autorisée.

Une lecture fonctionnelle simule le profil actif. Le titre commun est visible sur A et sur B, ce qui permet de vérifier qu’un contrôle portant seulement sur le titre accepterait une mauvaise cible. Le contrôle complet associe le marqueur et la révision. Le test fait ensuite A, puis B, puis A. Il vérifie le retour du contenu récent et l’empreinte des deux fichiers. Dans un deuxième parcours, une écriture fictive est ajoutée à B après le changement. Le retour est bloqué et les deux bases sont conservées.

Dans le dossier extrait du ZIP, lancez « python -X utf8 exercice.py » puis comparez le rapport à « attendu.json ». Relisez le résultat du ZIP après exécution et notez les contrôles que l’équipe reproduira sur l’hébergement. Le programme ne lance ni WordPress ni service réseau. Le refus simulé de revenir après une écriture est un choix de procédure pour l’exercice. Sur une vraie copie, mettez en place un mécanisme qui recense les écritures utiles et une décision explicite sur leur conservation.

Choisir qui prépare B et qui signe le retour

Retenez alwaysdata Small si un opérateur maîtrise les archives SQL et veut sélectionner, conserver et importer lui-même un fichier daté. Les deux bases de recette doivent tenir dans le quota commun, avec la marge nécessaire à l’import. Faites préciser la rétention de Small si le point recherché dépasse la fenêtre de sept jours affichée. L’auditeur peut rester en lecture seule et remettre un résultat sur A et B au titulaire.

Retenez Infomaniak Hébergement Web si le titulaire préfère choisir la sauvegarde et créer la base candidate depuis le Manager. La documentation décrit ce chemin et les trois familles de permissions SQL. Vérifiez le format, la taille et les objets de la base, puis choisissez le canal d’import. Ce forfait convient au scénario tant que l’audit se limite à SQL et que les actions dans le Manager restent au titulaire.

Dans les deux cas, demandez à la personne qui signe de fournir les trois états observés et le relevé des écritures. Si l’équipe doit déléguer aussi la restauration au même compte SQL, le scénario de lecture seule ne couvre plus le besoin. Il faut alors désigner un opérateur distinct ou encadrer un droit temporaire sur B, puis vérifier son retrait. Le retour est prouvé lorsque la copie sert de nouveau les données propres à A et que B reste disponible pour expliquer l’écart.

Pour aller plus loin

• Lire la fiche alwaysdata
• Lire la fiche Infomaniak
• Diagnostiquer une erreur de connexion SQL WordPress
• Télécharger la maquette du retour de base WordPress (ZIP)