alwaysdata ou 34SP.com pour vérifier une sauvegarde planifiée après une migration WordPress

Le premier matin, vérifier ce que la tâche a réellement produit

Un magazine vient de déplacer son WordPress. Pendant deux nuits, l’ancienne instance reste accessible à l’équipe pour faciliter le diagnostic. La première tâche automatique de la nouvelle instance se termine. Dans le stockage indépendant, un fichier appelé dernier-export.zip est bien présent. Il s’ouvre, mais son contenu correspond au site d’avant la bascule. Il a pu être déposé plus tard par l’ancienne instance, écrasant le premier bon export de la nouvelle.

Pour décider si la relève est effective, l’équipe choisit deux fenêtres de sauvegarde consécutives. Chaque matin, elle vérifie dans le stockage indépendant une archive datée, sa provenance, son empreinte et un témoin de contenu écrit après la bascule. La première échéance démontre le changement d’origine. La deuxième démontre que le planificateur continue de fonctionner sans intervention. Si la première occurrence a été sautée, un rattrapage manuel aide à récupérer un point, tandis que la continuité automatique reste à démontrer.

Le comparatif oppose alwaysdata Cloud Public Plus Small à 34SP.com WordPress Hosting 1 Site Container. Le premier permet de recréer une tâche de panneau avec sa commande et son environnement. Le second documente une exécution serveur des événements WordPress toutes les cinq minutes. Dans les deux offres, les copies du fournisseur constituent un périmètre séparé. Le contrôle porte ici sur l’archive indépendante que l’équipe s’attend à recevoir après le changement d’hébergement.

Comparer les coûts et le périmètre des deux offres

alwaysdata affiche Plus Small à 5 € HT par mois avec paiement annuel, soit 60 € HT par an, et à 6 € HT avec paiement mensuel, soit 72 € HT sur douze mois au même prix. La grille annonce 50 Go partagés entre fichiers, bases et e-mails, 1 Go de RAM, un CPU et sept jours glissants de sauvegardes fournisseur. Le quota compte donc aussi l’espace consommé par un export temporaire placé sur le compte. Le prix et la TVA applicables figurent sur le récapitulatif du client.

Le guide de facturation d’alwaysdata précise que supprimer un compte avant son échéance ne donne pas lieu à remboursement. Le contrat mutualisé public daté de 2022 prévoit une reconduction de même durée. Vérifiez le document effectivement accepté et la date de résiliation dans l’espace client, en particulier si le site migre depuis un ancien plan. La grille actuelle prévoit sept jours de sauvegardes pour Small. La documentation décrit des copies en lecture seule des fichiers, des bases de données et des e-mails. Vérifiez les points accessibles dans votre compte.

34SP.com affiche 1 Site Container à 11,95 GBP TTC par mois ou 143,40 GBP TTC par an. Pour un site et 25 Go de stockage, le sélecteur d’achat affiche 2,27 Go de mémoire et la fiche technique 1,25 Go. Demandez au fournisseur quelle limite s’applique au conteneur avant de dimensionner l’export. Les conditions prévoient la reconduction automatique par défaut pour une période équivalente, avec désactivation possible avant échéance. Elles indiquent qu’un dépassement de stockage au renouvellement entraîne un changement de forfait vers le plus proche couvrant l’usage, au tarif de ce forfait. Si les archives se déposent d’abord sur le compte, relevez le pic occupé pendant leur préparation.

Les copies WordPress de 34SP.com sont quotidiennes et conservées 28 jours. Le fournisseur décrit des exports SQL, les répertoires /httpdocs et /wp-content, et une restauration sur demande au support. Le répertoire /wp est exclu. Cette cadence ne donne pas une heure fixe et ne prouve pas que la copie indépendante de l’équipe a été déposée. À chaque offre, associez le coût du stockage externe, la période de coexistence et le temps nécessaire à la vérification du premier point.

Distinguer la tâche, son déclencheur et la destination

Relevez ce qui lance l’export avant de copier WordPress. Une extension peut inscrire un événement WordPress dans la base. Une tâche du panneau peut appeler un script, une URL ou la file WP-Cron. Un service externe peut également agir à une heure prévue. Le transfert des fichiers et de la base peut garder le hook et ses paramètres tout en laissant le déclencheur externe sur l’ancien compte. Une ligne présente dans une liste d’événements ne suffit donc pas à garantir un départ.

Documentez la commande ou le hook, l’utilisateur d’exécution, l’interpréteur, le répertoire de travail, la destination, la rétention et les chemins temporaires. Relevez l’heure planifiée dans le fuseau utilisé par le déclencheur et l’heure UTC attendue. Pour une échéance métier en heure locale, vérifiez aussi les dates où le décalage change. Une récurrence de 86 400 secondes peut décaler l’heure locale lorsqu’elle traverse un changement d’heure.

Définissez ce qui constitue la preuve minimale. Dans cet exemple, la destination doit recevoir le SQL, un petit fichier repère et un manifeste liant le site, l’environnement, la fenêtre et le contenu. Le témoin vient de la base active au moment de l’export. Utilisez une valeur sans donnée personnelle, créée après la bascule. Conservez aussi un export initial lisible pour pouvoir couvrir la période avant la première nuit.

Recréer la bonne commande chez alwaysdata

Le panneau alwaysdata documente des tâches planifiées par commande ou par URL. Pour un export lancé par une commande, recréez l’entrée dans l’administration du compte cible. Contrôlez le chemin absolu, le répertoire courant, l’utilisateur et les versions des langages retenues par l’environnement. Pour une tâche qui déclenche WP-Cron, vérifiez que la commande vise le WordPress migré. Une commande qui répond sur une ancienne URL après redirection peut laisser une trace sans lire la bonne base.

La documentation annonce un intervalle minimum d’une minute et l’absence de durée maximale propre au planificateur. Sur le Cloud Public, elle demande de conserver une consommation raisonnable. Une occurrence est ignorée si la précédente de la même tâche est encore en cours. Cette règle importe si l’export dure plus longtemps que prévu ou qu’un dépôt externe ralentit. Un cron plus fréquent n’obtient pas une nouvelle archive à chaque passage. Dimensionnez l’intervalle à partir des durées observées et déclenchez une alerte quand un point prévu manque.

Comparez les heures de début et de fin dans les journaux de tâches d’alwaysdata avec l’artefact arrivé sur la destination. Si le journal indique une commande terminée et que le fichier est absent ou tronqué, tracez l’écriture locale et le dépôt séparément. Pour un site à faible trafic, observez une échéance sans visite et sans lancement manuel. La mesure qui compte est l’arrivée d’un point lisible dans la fenêtre prévue, même si le processus a rendu un code de succès.

Reprendre l’événement WordPress chez 34SP.com

34SP.com indique que son offre WordPress remplace le déclenchement intégré sur visite par un crontab serveur qui traite les événements toutes les cinq minutes. Une alerte d’extension signalant que WP-Cron est désactivé peut donc refléter la configuration attendue. Vérifiez que l’événement de votre extension est bien présent et qu’il a produit un point. Attendez un passage normal du planificateur et gardez une marge pour le temps de fabrication et de transfert.

Pour une commande indépendante, 34SP.com documente aussi le panneau Manage Crons pour ses offres WordPress. Recréez la tâche dans ce panneau si le compte cible le permet, puis vérifiez le chemin, l’interpréteur, les droits et la trace d’exécution. Vous pouvez aussi reconfigurer l’export dans une extension WordPress compatible et observer son résultat. 34SP.com documente des extensions d’export qu’il a testées, dont UpdraftPlus pour les sauvegardes planifiées et le stockage tiers. Vérifiez la version, la configuration et le périmètre réellement sauvegardé.

Évitez de remettre en service un second déclencheur sur la foi de l’alerte d’une extension. Deux instances peuvent avoir chacune la tâche et les identifiants de la même destination. La version ancienne peut produire le ZIP le plus récent en heure d’arrivée tout en lisant des données anciennes. Laissez-la accessible en lecture pour la recette et retirez son droit d’écrire dans le dépôt d’archives de production. Utilisez des droits distincts pour la préproduction.

Sceller un point avant de l’annoncer

Écrivez d’abord dans un emplacement temporaire ou dans un objet en préparation. Faites produire une liste des éléments attendus avec leur empreinte et un repère de capture. Depuis la destination, vérifiez le contenu du fichier reçu et l’empreinte de l’archive finale. Ouvrez le SQL dans une base isolée pour lire le témoin. Une archive est exploitable pour ce contrôle si le témoin provient de la bonne base et que les composants attendus sont accessibles. Une restauration complète vérifie ensuite les dépendances que le témoin ne couvre pas.

Donnez au point un nom stable lié à une fenêtre et une origine. Conservez les preuves de validation séparément, avec la date de lecture. En cas de deuxième tentative dans la même fenêtre, gardez le premier point validé et inscrivez le nouveau résultat dans le journal. Sur un stockage d’objets, vérifiez qu’une création conditionnelle ou un mécanisme équivalent empêche le remplacement. Si vous affichez un lien vers le dernier point, mettez-le à jour après validation et protégez aussi cette mise à jour des écritures de l’ancienne origine.

Le témoin doit avoir été introduit après la bascule et apparaître dans l’export correspondant. Vérifiez-le avec une référence conservée hors archive. Un manifeste qui annonce « nouveau » ne suffit pas si la commande exporte une base de recette ou une copie non actualisée. Ne déduisez pas non plus l’heure de capture de l’heure de modification du ZIP. Un fichier téléchargé de nouveau ou recopié peut avoir une date récente alors que le contenu est ancien.

Mesurer la capture et l’arrivée séparément

Consignez l’heure planifiée, l’heure de lecture de la base et l’heure où le fichier complet devient accessible au dépôt. Relevez la dernière directement sur la destination ou dans sa trace d’écriture. La date déclarée par le producteur décrit la capture. Elle ne prouve pas qu’un ZIP est arrivé avant la limite. Un fichier capturé à 03 h 14 UTC et reçu à 04 h 10 UTC rate une échéance fixée à 04 h, même si son SQL est récent.

Par exemple, si vous voulez disposer d’un point à 04 h UTC, une tâche lancée à 03 h 10 laisse cinquante minutes. Supposez que le passage du planificateur prenne jusqu’à cinq minutes dans la configuration observée, que l’export dure vingt minutes et le transfert dix. Il reste quinze minutes pour vérifier l’archive et signaler un incident. Le lendemain, mesurez ces durées de nouveau. Une moyenne seule masque une exécution lente. Fixez le seuil d’alerte assez tôt pour laisser le temps de lancer un rattrapage.

Lorsqu’un point manque, cherchez d’abord l’endroit où la trace s’arrête. Aucun départ indique un problème de déclenchement, d’environnement ou une occurrence ignorée. Un départ sans dépôt demande de contrôler le code de sortie, la place temporaire et les droits de la destination. Un dépôt tardif reste une copie possible pour la reprise si son contenu a été vérifié. Consignez-le à part pour garder visible l’échec de la fenêtre automatique.

Mettre en échec les faux succès

Le ZIP de recette contient trois fenêtres fictives. À la première, la maquette simule l’occurrence ignorée parce que la tâche précédente est encore active. Un lancement manuel produit ensuite un ZIP, mais il n’est pas admis comme preuve automatique. Les deux fenêtres suivantes produisent chacune un point au nom de la nouvelle instance. La commande de fabrication est lancée comme sous-processus. Le dépôt et les horaires sont locaux et les déclenchements sont simulés.

Pendant la première nuit conforme, la maquette présente aussi une archive valide de l’ancien site, une archive du nouveau site qui contient un témoin périmé, un export capturé hors fenêtre et une capture à l’heure dont le dépôt est tardif. Le contrôle détecte ces quatre anomalies séparément. Une autre commande termine avec le code zéro et produit volontairement un ZIP tronqué. Le fichier est rejeté à l’ouverture. Les erreurs apparaissent dans le rapport même si le producteur a indiqué qu’il avait réussi.

Le script rouvre le SQL des points admis et relit les témoins attendus. Un deuxième dépôt dans une fenêtre déjà validée ne remplace pas le point publié. Le rapport contient la taille et l’empreinte des deux archives. Comparez-le au journal d’exécution pour distinguer les tentatives des points effectifs. L’exercice valide ce parcours avec des données fictives. L’ordonnancement et la restauration complète de WordPress relèvent de la recette sur votre installation.

• Extrayez le ZIP de recette dans un dossier vide, puis lancez python recette.py avec Python 3.10 ou supérieur.
• Dans le rapport, repérez les tentatives écartées, les deux fenêtres validées et les empreintes de leurs archives.
• Reprenez ces contrôles sur une copie de votre installation avec une destination distincte avant de valider les sauvegardes réelles.

Choisir en fonction de la tâche à maintenir

alwaysdata Plus Small convient si l’équipe doit garder la main sur une commande, son interpréteur et ses horaires. Le panneau et les journaux facilitent la reconstruction d’une tâche indépendante de WordPress. Gardez une place suffisante pour la préparation locale et observez ce qui se passe si un export dépasse l’intervalle. Si la tâche ne part pas au rendez-vous suivant, établissez une nouvelle fenêtre d’observation après le rattrapage.

34SP.com 1 Site Container convient si le flux d’export repose sur une extension WordPress qui fonctionne dans cet environnement et si le passage toutes les cinq minutes laisse le temps de finir avant l’échéance. Confirmez la prise en charge des tâches shell qui subsistent. La durée de rétention des copies fournisseur est plus longue sur l’offre comparée. Pour l’export indépendant, fixez la durée souhaitée sur le stockage de l’équipe et comparez-la aux besoins de reprise.

Avant de désactiver définitivement l’ancien compte, consignez les deux points automatiques vérifiés et l’heure où ses droits d’écriture ont été retirés. Gardez le premier export de migration pendant la période de transition. Si une échéance manque, corrigez le déclencheur ou le dépôt, produisez si nécessaire un point manuel et recommencez l’observation. Pour un site qui sauvegarde chaque nuit, deux points consécutifs rendent visibles une mauvaise origine, une interruption et une tâche qui n’a tourné qu’à la demande.

• Fixer deux fenêtres et un témoin indépendant pour chacune.
• Retirer le droit de dépôt à l’ancienne instance.
• Ouvrir les points reçus et relire le témoin dans un environnement isolé.
• Valider la continuité après deux échéances sans intervention.

Pour aller plus loin

• Lire la fiche alwaysdata
• Lire la fiche 34SP.com
• Comparer les outils d’inventaire des tâches WordPress
• Télécharger la recette des sauvegardes planifiées (ZIP)