- WordPress :6.7
- Statut : non résolu
- Ce sujet contient 30 réponses, 3 participants et a été mis à jour pour la dernière fois par
, le il y a 2 mois et 2 semaines.
-
Messages
-
Quel est votre hébergeur ? Vous pourriez peut-être restaurer une version précédente de votre espace d’hébergement … et recommencer toute la procédure, mais en faisant un download progressif du dossier uploads (mois par mois, année par année)
Mon hébergeur est OVH.
Vous soulez dire que si je restaure la base de données d’hier disponible sur mon espace personnel OVH je retrouverai les médias qui manquent aujourd’hui dans mon dossier « uploads » après rechargement ?
Si oui je n’ai jamais fait de restauration depuis OVH mais celà semble à ma portée.
Je viens de restaurer la base d’hier à partir d’OVH. Cela ne ramène pas les médias manquants.
Je suis coincé et vais sans doute devoir recharger x.000 fichiers manquants sur le serveur. Je vais regarder comment faire ceci de la moins problématique possible.
J’ai sans doute loupé quelques chose dans le download du dossier « uploads » tout à l’heure. Je ne sais pas où.
J’aurais dû bien vérifier que le nombre de fichiers downloadés correspondait bien au nombre existant sur le serveur. Peut-être pourriez-vous compléter la procédure en conséquence pour les prochains ?
Vous soulez dire que si je restaure la base de données d’hier disponible sur mon espace personnel OVH je retrouverai les médias qui manquent aujourd’hui dans mon dossier « uploads » après rechargement ?
Vous auriez dû attendre ma réponse, car la réponse est « non ». Ce n’est pas la base de données qu’il fallait restaurer, mais l’espace d’hébergement, c’est à dire les dossiers et fichiers de l’installation WordPress, qui sont accessibles par FTP.
→ suivez ce tuto de restauration de l’espace de stockage chez OVH
Cela restaurera votre dossier « uploads« , mais aussi tout le dossier wp-content avec tout ce que vous aviez nettoyé. C’est pour ça qu’il faudra ensuite reprendre la procédure à zéro.
J’ai sans doute loupé quelques chose dans le download du dossier « uploads » tout à l’heure. Je ne sais pas où.
Sauvegardez des milliers de fichiers peut prendre du temps selon la qualité de votre connexion Internet. Si elle est un peu limitée, de micro-coupures peuvent entraîner des fichiers qui ne passent pas. Dans Filezilla, on peut voir les fichiers non-transférés dans un onglet en bas, et les remettre en « file d’attente » pour un nouveau transfert.
Parfois, c’est le nom du fichier qui est trop long : il faut alors l’abréger en cours de sauvegarde. (mais dans ce cas, la base de données ne le reconnaîtra plus pour le ré-insérer dans le contenu)Vous avez des milliers de fichiers-médias et vous n’aviez jamais fait de sauvegardes de votre espace d’hébergement ??
J’aurais du attendre votre réponse. Suis un peu fébrile depuis cet après-midi… J’ignorais tout de l’espace de stockage c’est pourquoi j’ai confondu avec la base de données et que je n’avais jamais fait de sauvegarde de mes milliers de fichiers sur cet espace. C’est le métier qui rentre avec votre aide.
Je viens de restaurer mon espace de stockage, je vais mieux :). Je reprendrais demain la procédure de nettoyage sans oublier de faire une sauvegarde de mon espace le dossier « uploads » de mon espace d’hébergement. C’est quand même bien fait toute cette architecture pour récupérer les mauvaises manoeuvres des néophytes.
Merci.
Merci Ferman de vous préoccuper de mon site :).
Suite à différentes mauvaises manoeuvres de ma part, cf. dialogue avec Flobogo, je n’ai pas pu restaurer intégralement les quelques 5 000 fichiers médias qui existaient avant le nettoyage dans le dossier « uploads » sur le serveur. Flobogo a émis des hypothèses explicatives à ce sujet. J’ai donc restauré mon espace de stockage et la base de données (ce que je n’aurais pas du faire pour cette dernière).
Je relance le processus de nettoyage ce soir sans toucher au dossier « uploads ». Je vous tiendrai au courant du résultat de cette deuxième tentative.
Bien à vous.
Pas facile la vie numérique…
Je viens de trouver sur mon site enfant deux dossiers ‘wp-content/nfwlog’ et ‘wp-content/mu-plugins’. Quand j’ouvre le premier j’y trouve des fichiers pleins de choses bizarres, cf screen shot. Le second dossier est vide. J’avais également à la suite de ce dossier douteux une quinzaine de fichier nommés ‘temp-write-test-66cece311526b2-96867626’ et équivalent. J’ai tout supprimé sur le site enfant et ils ont aussi disparu du ‘wp-content’ du site parent. Du coup le site enfant ressort en erreur d’accès à la base de données et las le parent alors que c’est la même base.
Le temps de me retourner et le dossier douteux ‘wp-content/nfwlog’ est déjà revenu sur le site enfant, il devrait aussi réapparaître sur le site parent je suppose. J’ai déjà changé x fois les mots de passe de la BD, d’accès à OVH et d’accès aux 2 sites. Je vais relancer la procédure de nettoyage pour les 2 sites ce soir mais j’ai l’impression que l’on se courre après avec le pirate et qu’il court largement plus vite que moi.
Auriez-vous les référénces d’un professionel qui pourrait régler ce problème conre facturation ?
Bonjour,
Pour le premier (wp-content/nfwlog) c’est un dossier légitime créé par Ninja Firewall. De même les fichiers « temp-write-test-etc » ne sont pas des dossiers de piratage mais ils signalent quand même que quelque chose ne va pas (sans que ce soit du piratage). Regardez aussi ICI. Avez-vous les bonnes permissions sur les dossiers et fichiers du site? Cela se contrôle dans filezilla: vous cliquez (bouton droit de la souris) sur les dossiers principaux (contents, include, admin) et vous cliquez sur « droits d’accès aux fichiers ». vous devez lire 755 (sur la copie d’écran j’ai 705 car l’hébergement est un peu ancien . Cela fonctionne quand même bien).
Les valeurs sont les suivantes (extrait de ce document):
Pour des raisons de sécurité, les fichiers et dossiers sur les serveurs disposent d’autorisations qui déterminent qui peut lire, écrire, accéder et modifier ces fichiers et dossiers. Les autorisations sont présentées avec des valeurs numériques et, pour WordPress, elles doivent être définies sur 755 pour les dossiers et 644 pour les fichiers (dans les anciens comptes d’hébergement Web et Managed WordPress, ces valeurs sont 705 pour les dossiers et 604 pour les fichiers).
Petite précision, si vous rectifiez une valeur sur le dossier parent (par exemple wp-content, vous avez mis 755) et que vous cochiez « récursion dans les sous-dossiers » et « appliquer uniquement aux dossiers » , tous les sous-dossiers de wp-content prendront cette valeur. Cela fait gagner du temps. Pareil pour les fichiers.
Pour une adresse de développeur permettant de remettre votre site en ordre, je n’ai pas d’idée; attendez l’avis d’un autre participant. En tout cas je ne pense pas que ce soit un problème de piratage.
Vous dites:
Le temps de me retourner et le dossier douteux ‘wp-content/nfwlog’ est déjà revenu sur le site enfant, il devrait aussi réapparaître sur le site parent je suppose
Et est-ce que vous avez alors disparition du message « erreur d’accès à la base de données »?
EDIT: Je viens seulement de vérifier votre site. Il semble fonctionner normalement donc si vous avez accès à votre administration ce n’est pas la peine à mon avis de modifier quoi que ce soit dans les droits d’accès. je pense que votre site n’est plus piraté. Que contient le dossier mu-plugin? Ninja firewall par hasard?
Merci Ferman de prendre soin de mes problèmes.
Nous avions conclu avec Flobogo qu’il s’agissait d’un piratage car :
- Un compte administrateur a été créé il y a quelques jours sur le site parent avec email d’administration qui n’était pas le mien. J’ai supprimé ce compte et modifié l’email dans phpMyAdmin.
- Un lien a été incrusté surl’écran de connexion, cf. copie d’écran. Le lien donne sur un poste écrit en 2014.
Je viens didentifie un fichier ‘._wp-config-sample.php’ en lettres asiatiques, cf . copie d’écran. Je l’ai supprimé.
Après que ce soit piratage ou spams mon problème est que le site est poussif et affiche régulièrement l’écran ‘installation de WP en 5 mn’ au lieu de la page d’accueil ou d’un article, cf. copie d’écran. C’est assez aléatoire et vient de se produire encore à l’instant. OVH m’a sorti régulièrement du site mutualisé pour ‘max ressources’ dépassé, avant de m’y réintégrer. Lors d’un précédent ticket ouvert sur le forum on m’avait dit que lorsque le temps de réponse du serveur est trop long la requête n’arrive pas à trouver/ouvrir WP et propose donc de l’installer…
- Le non accès à la DB était une question de mot de passe.A force de le changer je n’avais pas mis le dernier dans le wp_config. C’est réglé.
- Dans ‘mu-plugins’ j’ai effectivement des fichiers Ninja. Pour le moment j’ai désactivé Ninja sur les deux sites car il déclenche une erreur ‘session PHP active détectée’. Je vais ouvrir un sujet sur le forum ‘plugins’ plus tard.
- J’avais modifié les droits d’accès avant de lire votre nota bene. Celà ne doit pas prêter à conséquences je suppose.
Que me consillez-vous pour éviter de tomber régulièrement, moi ou mes visiteurs, sur d’installation de WP en 5 mn au lieu de la page d’accueil ?
Nous avions conclu avec Flobogo qu’il s’agissait d’un piratage
Vous avez effectivement sans doute eu un piratage mais je pense que vous ne l’avez plus.
J’avais modifié les droits d’accès avant de lire votre nota bene. Celà ne doit pas prêter à conséquences je suppose.
Non; ça ne pose pas de problème.
Je viens didentifie un fichier ‘._wp-config-sample.php’ en lettres asiatiques, cf . copie d’écran. Je l’ai supprimé.
C’est ce qu’il fallait faire mais j’ai du mal à comprendre comment ce fichier n’a pas été supprimé lors des étapes du tuto. Peut-être un résidu qui a échappé au nettoyage. Quoi qu’il en soit surveillez de temps en temps qu’il ne revient pas.
Pour le reste (l’install qui revient de temps en temps), il me semble que vous avez ça également sur un autre site (où le problème est plus sévère). Ces deux sites sont-ils sur le même hébergement (multisites au sens OVH) ou sur deux hébergements différents? Et quelle(s) offre avez vous: (personnel, pro…)?
Pour le reste (l’install qui revient de temps en temps), il me semble que vous avez ça également sur un autre site (où le problème est plus sévère).
Comme les trop nombreuses tentatives de connexion et/ou attaques et/ou redirections vers des pages douteuses font exploser vos compteurs chez l’hébergeur, cela fragilise votre hébergement (c’est pourquoi OVH vous « isole »). Mais avant d’être « isolé », votre hébergement est instable, WordPress ne parvient pas à se charger, et charge donc la page de démarrage d’installation car elle est basique.
Un « petit malin » en a profité pour installer un nouveau WordPress, en écrasant votre site.
→ voir ce topic : https://wpfr.net/support/sujet/site-wp-ecrase-par-wp-en-5-mn-sans/
Bonne nouvelle si je ne suis plus piraté.
Ces deux sites sont-ils sur le même hébergement (multisites au sens OVH) ou sur deux hébergements différents? Et quelle(s) offre avez vous: (personnel, pro…)
Oui :
- https://rehve.fr/ offre « pro », datacentre « eu-west-gra »
- https://amis-chapelle-penvern.fr/ offre « Perso », datacentre « eu-west-gra »
Un « petit malin » en a profité pour installer un nouveau WordPress, en écrasant votre site.
Ce n’est peut-être même pas un « petit malin » malfaisant qui a installé un nouveau WordPress mais plus simplement un visiteur « normal » qui s’est trouvé devant l’écran d’install et a cliqué sur les boutons croyant bien faire… D’où ma question posée sur le topic https://wpfr.net/support/sujet/site-wp-ecrase-par-wp-en-5-mn-sans/ : comment faire pour que cet écran d’install ne s’affiche plus malgré de trop nombreuses tentatives de connexions afin d’éviter le renouvellement de cet incident ? Il est quand même problématique que n’importe qui puisse installer un WP neuf !
Merci encore de tous vos bons conseils.
Il est quand même problématique que n’importe qui puisse installer un WP neuf !
Non, ce n’est pas possible. Voir ICI.
Vous avez deux hébergements différents correspondant à vos deux offres « pro » et « personnel ». Dans les deux cas, l’écran install apparaît pour la même raison: perte de connexion à la base de données. Toutefois les causes sont différentes:
- pas de connexion intermittente car vous excédez le nombre de requêtes par heure.
- pas de connexion permanente car les préfixes sont différents dans wp-config et la base de données.
Les deux problèmes sont à traiter séparément;
Pour le premier cas, vous avez déjà testé si le problème persistait après avoir désactivé vos extensions. Maintenant que vous avez nettoyé le site, vous pouvez réessayer.
Dans phpmyadmin, pouvez- vous regarder la taille de votre base de données et la taille des tables? Y en a-t-il de particulièrement volumineuses?
Pour le deuxième cas, voir votre autre sujet.
- Vous devez être connecté pour répondre à ce sujet.