Comme sur un hébergement OVH, il faut sauvegarder régulièrement les bases de données et les fichiers des sites hébergés. Avec un VPS équipé de « Plesk-resellers », il faut également sauvegarder les paramètres liés aux clients, abonnements, packs de service. Nous allons voir comment.
Sauvegarder tout ou partie des données Plesk
Cette partie n’est accessible qu’aux administrateurs du compte Plesk resellers.
Dans « outils et utilitaires » > « Gestionnaire de sauvegardes », on peut définir les paramètres de sauvagarde, faire des sauvegardes unitaires ou des sauvegardes planifiées.
Paramètres et configuration du compte client, sites, bases de données, boîtes mails, listes de diffusion
Certificats SSL
Informations sur les DNS
Configuration et contenu du revendeur
Toutes les options ci-dessus, plus :
Contenu des sites Web
Contenu des mails
Contenu des listes de diffusion
Contenu des bases de données
Logs et statistiques
Pages d’erreurs personnalisées
Définir les paramètres de sauvegarde
On peut définir un hébérgement OVH (pro ou perso) comme destination des sauvegardes.
Les paramètres sont définis comme suit (on obtient le nom d’hôte, le nom d’utilisateur FTP et son mot de passe dans le compte OVH de l’hébergement cible) :
Plesk : paramétrage du stockage FTP
Attention, la seule difficulté (que je n’ai résolue qu’après plusieurs échanges avec des techniciens OVH), est que Plesk doit pouvoir écrire sur la « racine » de la cible pour vérifier le bon fonctionnement avant de transférer la sauvegarde.
Donc le champ « répertoire » doit obligatoirement contenir quelque chose et le répertoire défini doit déjà exister dans le compte FTP cible.
Pour une sauvegarde unitaire :
Dans « stocker sous »,
le stockage FTP proposé est celui qui a été défini dans les paramètres de sauvegarde.
Je ne me souviens pas si j’ai défini le lieu de stockage du serveur.
Plesk : sauvegarder pour le « revendeur »
Planifier des sauvegardes
Voici les réglages que j’ai fait.
Plesk : planifier des sauvegardes
Sauvegarder le compte et les sites web (client)
Le client a accès à un menu « compte » dans lequel on trouve les boutons « Sauvegarder le compte et les sites Web » et « Sauvegarder les sites Web ».
Cette option « copier du site web » est accessible aux clients, selon les réglages de leur abonnement. Attention, cette option ne copie pas la base de données.
Lorsque le client clique sur « copie du site web », il peut choisir ses options :
Plesk : copie de site web
On peut utiliser cette fonction pour copier un site vers un autre (le cloner), mais cet autre est OBLIGATOIREMENT un élément du même domaine. Par exemple si je copie « knowledge.parcours-performance.com , je ne peux le copier que vers parcours-performance.com ou un de ses sous-domaines.
Et maintenant ?
Il reste à vérifier que je parviens à restaurer les données sauvagardées si nécessaire.
A la création d’un site, il est indispensable de vérifier la sécurité et l’indexabilité du site WordPress. C’est également indispensable après le transfert d’un site vers un nouvel hébergement. Cette check_list contient des éléments applicables à tout site WordPress et des actions spécifiques au transfert vers un hébergement d’un VPS Plesk. Cet article fait partie de la série Démarrer avec un hébergement VPS Plesk d’OVH.
Vérification de la sécurité
(1) sécuriser tout ce qui peut l’être avec WordPress Toolkit.
Sécuriser un site avec le WordPress Toolkit de Plesk
Après avoir cliqué sur « analyser la sécurité », je donne l’autorisation de sécuriser tout ce qui ne l’est pas.
Nota : selon cet article sur Devblog.Plesk, les changements ne sont pas faits en modifiant .htaccess (et n’en lit même pas le contenu pour définir le statut de sécurité). C’est la configuration du serveur web qui est modifiée. Toute modification du .htaccess va remplacer la configuration serveur correspondante.
Exécuter tous les « hardening » proposés sauf « website firewall protection » (pas dans la version gratuite de sucuri) et « error logs » qui « can not be determined ». Attention, je n’ai jamais essayé de voir si Sucuri peut changer correctement le préfixe de base de données. J’ai procédé comme indiqué dans l’article Changer le préfixe de base de données WordPress.
Dans Settings / Général (ou par une console d’erreur comme Query Monitor), j’ai eu une erreur indiquant que Sucuri n’a plus l’autorisation de stocker les données de Sucuri dans /home/parcoursz/www/wp-content/uploads/sucuri. Au final pour corriger le problème, il suffit de désactiver Sucuri, supprimer les fichiers stockés dans wp-content/uploads/sucuri puis réactiver Sucuri.
(3) Modifier wp-config.php
Vérifier que Sucuri a ajouté define( ‘DISALLOW_FILE_EDIT’, true ); pour interdire la modification de fichiers à partir du tableau de bord WordPress ;
En profiter pour ajouter une instruction pour limiter le nombre de versions stockées pour un article ou une page : define( ‘WP_POST_REVISIONS’, 5 );
(4) Ajuster .hataccess
Normalement c’est inutile pour un site monosite. Pour un site multisite, il faudra l’ajuster, mais ce sera l’objet d’un autre article.
Vérification pour le SEO
Après la création d’un site ou son transfert, il faut vérifier quelques points essentiels pour que le site reste correctement indexé par les moteurs de recherche :
(5) Google analytics
Vérifier que l’identifiant google analytics du site est toujours correctement défini. Pour moi c’est dans le menu « Insight » puisque j’utilise l’extension « Google Analytics par MonsterInsights«
Vérifier que Google Analytics et Google for Webmasters nous considèrent toujours comme propriétaire du site : j’ai laissé un enregistrement TXT contenant un code de vérification Google dans les enregistrements DNS sur OVH (cf l’article Réglages DNS d’un hébergement tiers à domaines gérés par OVH). En principe il n’y a pas de problème mais il vaut mieux vérifier car on peut avoir oublié de transférer un fichier html de vérification ou ne pas avoir défini l’enregistrement TXT.
(6) Yoast SEO
Vérifier que les réglages de l’extension sont correctement faits ;
Vérifier que la connexion à la search console est faite correctement ;
Si les sitemaps dans google for webmasters ne sont pas récents, les soumettre à nouveau ;
Dans Google for Webmasters, regarder les erreurs d’exploration et les corriger (redirection) ;
Dans un site nouvellement créé, on vérifiera aussi que l’on a correctement rempli les extraits SEO pour l’ensemble des contenus.
(7) vitesse du site
Tester le site avec Google Test My Site puis corriger les défauts éventuels. Ce site teste l’ergonomie sur appareil mobile, la vitesse sur mobile et la vitesse sur ordinateur.
Avec WordPress, une bonne pratique de sécurité est d’utiliser un préfixe de base de données différent du préfixe par défaut. Celà complique en effet la tâche d’éventuels pirates.
Le préfixe par défaut de WordPress est « wp_ ». On peut le changer lors de l’installation de WordPress ou plus tard. Nous allons voir dans cet article comment changer le préfixe d’un site existant.
Attention, ce changement nécessite une bonne compréhension du fonctionnement d’une base de données pour WordPress. On peut casser un site internet si on le fait mal.
Il faut sauvegarder la base de données avant tout changement.
Ce tutoriel s’applique aux installation WordPress classiques. Pour une installation multisite, suivre les instructions de cet article de WPmuDev.
Changer le préfixe des tables
Quel préfixe choisir ?
L’idéal est d’utiliser 6 à 10 caractères composés de lettres minuscules ou majuscules et de chiffres, tel que p7fQ25Hg_ ou i9s5c0Fu1P_. Pour le créer, l’idéal est d’utiliser lastpass password generator, en n’oubliant pas d’ajouter « _ » à la fin du préfixe généré.
Avec phpMyAdmin :
Sauvegarder la base de données ;
Remplacer le préfixe de table : en sélectionnant toutes les tables (tout cocher) puis « remplacer le préfixe de table ».
WordPress : changer le préfixe de base de données (2)
Et voilà, le préfixe des tables de notre base de données est devenu « newprefix_ ». A ce stade, notre site ne fonctionne plus du tout ! En effet, on n’a pas encore « dit » à WordPress que le préfixe de tables a changé.
Modifier wp-config.php
On édite wp-config.php pour que la ligne :
$table_prefix = 'wp_';
devienne
$table_prefix = 'newprefix_';
Après enregistrement du fichier modifié, les internautes peuvent de nouveau accéder au site. Mais l’accès au tableau de bord reste bloqué.
Changer le préfixe de certains contenus des tables
Le préfixe de table est également utilisé à l’intérieur de certaines tables. C’est le cas de certains contenus du champ option_name de la table « newprefix_options », et du champ meta_key dans la table « newprefix_usermeta ».
Modifier les « option_name » avec l’ancien préfixe
La commande SQL pour afficher les lignes concernées, de la table « newprefix_options » est :
SELECT * FROM `newprefix_options` WHERE `option_name` LIKE '%wp_%'
On peut aussi le faire dans l’interface graphique de phpMyAdmin.
On obtient une liste d’éléments de la table qui contiennent wp_. Mais attention, bon nombre de lignes ne doivent pas être modifiées. Pour le site dont je réalise la modification en écrivant ce tutoriel, j’ai obtenu 78 lignes dans lesquelles ‘option_name’ est « LIKE » ‘wp_’. En fait, la seule à modifier (à la main) est wp_user_roles qui devient newprefix_user_roles .
Modifier les meta_key avec l’ancien préfixe
La commande SQL pour afficher les lignes concernées, de la table « newprefix_usermeta » est :
SELECT * FROM `newprefix_usermeta` WHERE `meta_key` LIKE '%wp_%'
Pour s’y retrouver, on ordonne la colonne « meta_key » puis on modifie, à la main, toutes les entrées pour lesquelles la valeur de « meta_key » commence par wp_. En général on trouve les valeurs suivantes, autant de fois qu’il y a d’utilisateurs enregistrés pour le site :
wp_capabilities
wp_dashboard_quick_press_last_post_id
wp_media_library_mode
wp_user-settings
wp_user-settings-time
wp_user_level
A ce stade, on vérifie que tout va bien en se connectant au tableau de bord du site modifié. Si tout va bien, on arrive à se connecter et on a terminé.
En cas de problèmes
Cet article de WPmuDev, donne quelques pistes si on observe des dysfonctionnements après le changement de préfixe.
Problème n° 1 : pas d’accès au site
Lorsqu’on met l’adresse du site dans un navigateur, on arrive à un écran nous proposant d’installer WordPress !
La solution est de modifier wp-config.php pour que la ligne $table_prefix = ‘newprefix_’; contienne la bonne valeur du nouveau préfixe.
Problème n°2 : les utilisateurs n’ont plus la permission de se connecter au site
Dans ce cas, on a omis de modifier une ou plusieurs entrées de la table « newprefix_usermeta » et certaines valeurs de « meta_key » contiennent toujours le préfixe « wp_ ». Il faut donc vérifier ce que l’on a fait.
Notre problème n’est pas résolu ?
Voir l’article How to Fix “Error Establishing Database Connection” for WordPress. Il arrive en particulier que des extensions mal codées utilisent uniquement le préfixe par défaut « wp_ ». Dans ce cas, elles ne peuvent plus fonctionner une fois le préfixe changé. Pour les identifier, on désactive toutes les extensions puis on les réactive une à une jusqu’à ce que le site casse. Une fois l’extension problématique identifiée, on la supprime. On peut aussi revenir à la copie de la base de données réalisée avant le changement.
Dans les enregistrements DNS du domaine, deux enregistrements (MX et TXT renseignant spf) définissent que Plesk doit gérer la messagerie. Voir l’article Réglages DNS d’un hébergement tiers à domaines gérés par OVH pour plus de précisions.
On pourra définir des adresses et leurs redirections éventuelles. On peut également définir des alias de messagerie. Si quelqu’un envoie un mail à cet alias, elle est automatiquement redirigée vers l’adresse principale. C’est pratique comme adresse « jetable ». Si elle est trop spammée, on la supprime.
J’utilise RoundCube comme messagerie web. Dans ce cas, l’utilisateur peut y accéder par l’url http://webmail.mon-domaine.com/roundcube/ .
le service Plesk doit être désactivé en décochant « activer le service de messagerie » dans les paramètres de messagerie du domaine.
Cas 3 : un script php envoie des mails à partir d’un sous-domaine
J’ai un sous-domaine qui contient une page web servie par un fichier php. Lorsqu’on ouvre cette page, ça déclenche une vérification. Si il y a une anomalie, un mail m’est envoyé. Une tâche planifiée (cron) fait la même chose régulièrement.
Le problème c’est que le domaine principal est réglé pour que G Suite gère la messagerie. Dans ce cas, un mail émis par un script php est bien expédié mais je reçois un message (en spam) me disant que le mail est peut-être un spam.
La solution :
Il faut modifier l’enregistrement DNS suivant, dans Plesk :
Dans ce quatrième article de la série Démarrer avec un hébergement VPS Plesk d’OVH, nous allons parler d’une fonctionnalité très utile de l’interface Plesk. Il s’agit de la possibilité de visualiser, et même de modifier, un site internet alors même qu’il n’est « officiellement » pas hébergé (il pointe vers un autre hébergement).
Le cas d’utilisation type est le transfert d’un site, d’un hébergement vers un autre, équipé de Plesk.
Vérifier que la page d’accueil paraît OK
Si vous voulez simplement vérifier le site avant de pointer l’enregistrement DNS de type « A » vers l’IP du serveur Plesk, vous utilisez la fonction « aperçu » (cf documentation Plesk).
On voit alors un site dont l’adresse du type http://149.202.166.57/plesk-site-preview/knowledge.parcours-performance.com/149.202.166.57/
Les liens, et donc les menus, ne fonctionnent pas puisque notre site est réglé avec des liens de type https://knowledge.parcours-performance.com . Mais on voit ainsi facilement si le site a l’aspect qu’il devrait avoir.
Faire des modifications avant de pointer vers cet hébergement
Lorsqu’on pointe le nom de domaine vers le nouvel hébergement, il peut s’écouler jusqu’à 24 heures avant que l’ensemble des ordinateurs du monde aient cette information. Si l’ancien hébergement fonctionne toujours (préférable pour éviter une erreur 404 en attendant la propagation des DNS), on ne sait pas si le site qu’on voit est l’ancien ou le nouveau. Il faut donc qu’il y ait une petite modification quelque part pour le savoir.
Modifier dans la base de données du nouvel hébergement
C’est ce que j’ai fait jusqu’à présent. Dans la table prefixe_options, j’ai ajouté un « . » ou un « ! » dans la description du site. Comme ça je vois d’un coup d’œil si je regarde l’ancienne ou la nouvelle version.
Modifier le site « virtuel »
Nous avons vu tout à l’heure qu’on peut prévisualiser le site avec la fonction aperçu de Plesk.
Si son adresse est http://149.202.166.57/plesk-site-preview/knowledge.parcours-performance.com/149.202.166.57/ , on peut se connecter à son tableau de bord avec l’url http://149.202.166.57/plesk-site-preview/knowledge.parcours-performance.com/149.202.166.57/wp-login.php .
Il suffit ensuite de modifier l’adresse du site dans le menu « Réglages » > « Général » de WordPress :
Plesk modifier les permaliens en mode aperçu
Après avoir enregistré ce réglage, on va dans le menu « Réglages » > « Permaliens » et on clique sur « enregistrer les modifications », sans faire aucune modification. Maintenant tous nos liens fonctionnent, sauf s’ils ont été créés avec une référence absolue, par exemple dans un widget texte. On peut donc faire toutes les modifications qu’on veut dans un site que personne d’autre ne voit.
Evidemment, avant de pointer les DNS sur ce site, il faut aller remettre les réglages du site comme ils étaient et enregistrer les nouveaux permaliens.
Commentaires récents