Site Hors Service, SAV incapable de dépanner

Bonjour @Quigon 

Quelle est l'adresse de votre site ?

Passer en environnement Développement pour voir la cause de l'erreur Erreur 500

Voir dans mon guide le paragraphe : P2 - Erreur 500 - Environnement développement

Vos erreurs 500 proviennent certainement d'un plugin ou thème qui n'est plus à jour.

Désactivez tous les plugins puis remettez les en service l'un après l'autre.
Vous trouverez ainsi le plugin défectueux.
Voir dans mon guide le paragraphe : W - PLUGINS en erreur, dossier PLUGINS

________________________________________________________________________________________________

 Faites-vous des sauvegardes régulières de votre hébergement et Base de données sur votre PC ?

Les sauvegardes chez OVH de votre site ne sont pas éternelles.

Extrait de mon guide : T - Restauration OVH de votre site à une date antérieure

Chez OVH, la restauration de votre hébergement ne permet de remonter qu’au maximum à deux semaines.

Si le piratage de votre site remonte à 3 semaines, vous êtes foutu et obliger de tout supprimer et reconstruire complètement votre site.

Chez OVH, la restauration de votre base de données ne permet de remonter qu’au maximum à deux mois

Penser à faire une sauvegarde Hébergement et Base de données sur votre PC une fois par mois.
Voir dans mon guide le paragraphe : Ua - Sauvegarde complète de votre site sur votre PC

Quelle taille fait votre base de données ?

Vous avez DEUX problèmes :

1er problème :
 - Warning: Constant WP_CACHE already defined in /home/aeterny/www/wp-config.php on line 9
 - Warning: Constant WP_DEBUG_LOG already defined in /home/aeterny/www/wp-config.php on line 91
 - Warning: Constant WP_DEBUG_DISPLAY already defined in /home/aeterny/www/wp-config.php on line 92

 --> Désactiver le plugin WP_CACHE

2ème problème :
 - Erreur lors de la connexion à la base de données

 --> Restaurer une sauvegarde complète de l'hébergement et de la base de données d'il y a plusieurs jours :

Extrait de mon guide : T - Restauration OVH de votre site à une date antérieure

Bonjour @JLam 

Il est 12h13. Je ne vois pas la réponse de @Quigon  postée à 11h57

Apparemment même ici c'est compliqué, je retente de vous envoyer ce que je disais donc

le dump de la BDD fait environ 260Mo

Quant aux méthodes de restauration de celles ci, que ce soit par l'interface OVH ou par PHPmyadmin, dans les deux cas cela échoue. Pourtant le dump est bon, j'ai pu l'uploader sur une BDD personnelle à côté.

Quand une Base de données est très grosse, il faut :

• La compresser sur le PC en ZIP ou GZIP
• Transférer le ZIP sur votre hébergement
• La restaurer

De cette façon, vous devriez éviter de partir en Time-Out

Je suppose qu'il y a des réponses mais elles ne s'affichent pas parce que le compteur est négatif !

Je vais donc faire 2 réponses sans intérêt, afin de faire repasser le compteur à +1, et ainsi voir s'il y avait des réponses cachées ou pas.

Ceci est la réponse inutile 1 de 2

Ceci est la réponse inutile 2 de 2

Le procédé semble fonctionner. On est à zéro.

Il y avait au moins 5 réponses ! Succès !!!

Du coup ma dernière réponse a disparu de nouveau :(

je la remets

"
Malheureusement l'upload échoue, alors que le fichier est correctement lu l'autre BDD.
Et je remarque ceci sur mon interface

database/restoreEn erreur14/11/2025, 20:50C'est la première tentative de restauration faite hier. Apparemment le script de restauration est tombé en erreur lui même."


A ce jour la BDD est toujours vide et le script de restauration de celle ci en erreur.

Bonjour @Quigon 

Malheureusement, j'ai le message suivant lors de la tentative d'import manuelle:
"Un problème est survenu lors de l'envoi. Veuillez réessayer. (Invalid status: restoring) "

Il faut faire un transfert SFTP avec FILEZILLA.

Voir dans mon guide le paragraphe :  E - Installation du logiciel FTP FILEZILLA  

Puis via un script xxx.php :

$FILE_SQL = "xxx.sql";             // USE nécessaire  ( use `Nom_de_la_Base`; )

$USER = "xxx";
$HOST = $USER.".mysql.db";
$PASS = "xxx"; 

$COMMAND = "cat ".$FILE_SQL." | mysql --host=".$HOST." --user=".$USER." --password=".$PASS." ";
$CR_exec = system($COMMAND, $RET_VAL);

Bonjour,

Vous dites: "Dans la journée du 14, la base de données tombe, et désormais l'erreur est "Erreur lors de la connexion à la base de données". "

Est-ce que vous avez toujours accès à votre base avec PHPmyadmin ? Est-ce que les tables sont présentes ? Est-ce que les identifiants de connexion (4 éléments) concordent entre votre wp-config.php et votre base ?

Est-ce que le préfixe des tables correspond entre votre wp-config.php et votre base ?

Qu'entendez-vous par "la base de données tombe" ?

Avez-vous pu être victime d'un piratage ?

Pour ceux qui nous lisent: 

la bonne réponse se trouvait dans les guides OVH. Il m'a fallu quelques minutes pour trouver et lire les guides en question.

Je sais que ça demande un effort et c'est bien le problème du SAV OVH qui se trouve débordé s'il doit répondre sans cesse à des "demandes d'assistance" alors que c'est parfaitement documenté.

Par contre le bouton "restore" depuis l'espace client qui ne fonctionne pas comme attendu, c'est un incident, et OVH a le devoir d'y répondre et de proposer une solution de contournement en l'absence de réparation de la fonctionnalité.

Bonjour,

je suis content de vous lire aujourd'hui, fritz2cat.

C'est bien ce que j'affirme, moi aussi,
depuis le crash de la Restauration à J -1
du 15 novembre sur Hébergement Cloud !

J'avais voulu par là  JUSTE récupérer
un long § de mon billet, en cours de rédaction sur mon blog n°1, et que j'avais perdu par maladresse.

Vous avez écrit >>> "Par contre le bouton "restore" depuis l'espace client qui ne fonctionne pas comme attendu, c'est un incident,
et OVH a le devoir d'y répondre et de proposer une solution de contournement en l'absence de réparation de la fonctionnalité. "

Il m'est arrivé la même chose que Par Quigon,
j'avais - aussi le 15 novembre 2025 - lancé une Restauration J -1
et mon site, et mes deux blogs avaient disparu.

J'ai mis un temps fou en heures et pendant 10 jours à faire revenir en entier avec FileZilla 
mon site de voyage www.hotchkiss.eu et son blog www.hotchkiss.eu/trabelblog
qu'il contient.

Par contre mon 2ème blog renoverzmaintenant67.eu  , le blog d'analyse économique et juridique,
est aussi revenu, je ne sais pas non plus trop comment, MAIS il a perdu 
environ 5000 images et tous les documents pdf annexés, (pdf de l'ONU, de la CPI de La Haye, du OHCHR, etc)
et là je galère aussi depuis le 15 novembre.

Mes deux blogs sont en ligne depuis le 06 VI 06, 
20 ans et des milliers d'heures de travail (20.000 photos pour le blog de voyage)

OUI, c'est un incident, et OVH a le devoir d'y répondre
et de proposer une solution de contournement en l'absence de réparation de la fonctionnalité. 

Mais bien sûr, un simple renvoi de la part de OVH
 à FileZilla n'est pas "une solution de contournement", ça c'est juste envoyer balader.
Et insinuer dans x-phrase que c'est moi le fautif, ça n'a pas de sens.
TOUT marchait PARFAITEMENT avant le 15 novembre 2025.

Les Restaurations à -snap4 du FTP et de la base de donnée à la même date
pour ce site d'analyse renovezmaintenant67.eu 
ne permettent pas de le réparer en entier,
alors qu'il a exactement le même moteur Dotclear que le blog de voyage récupéré en entier.

(La suite des phénomènes inexplicables se trouve ici >>> https://community.ovhcloud.com/community/fr/methode-explicite-pour-sauvegarder-ftp-a-snap4-et-restaurer-avec-filezilla?id=community_question&sys_id=fa3dfc62089972504a4e665cf8d3f902  )

Si vous tenez tellement à votre site web et à son histoire, j'espère que vous avez une copie de vos dizaines de millers de photos chez vous.

Uploadez-les à nouveau avec sftp.

Et si vous n'en avez pas gardé de copie, c'est le moment de relire le contrat qui stipule que vous êtes seul responsable de la préservation de vos données. Un hébergement peut disparaître du jour au lendemain (par exemple votre site est troué avec des problèmes de sécurité et un méchant hacker détruit tout, voire même un incendie chez l'hébergeur, voire même une cessation d'activités... il faut se préparer à tout)

Vous avez justement l'air d'être copain copain avec les textes juridiques, donc ça s'applique aussi à vous même si ça vous est défavorable cette fois-ci.

Je vous rappelle qu'il y a une semaine je vous avais proposé mon aide, vous m'avez sobrement dit d'aller voir votre blog (qui était en error500). Ca donne envie de donner un coup de main. Tant pis.

Néamoins je suggère que vous demandiez explicitement à OVH comment restaurer le -snap4 quand il y a plus de 5000 fichiers. 

(ping @Bruno B. car SFTP répond "user invalid" avec -snap4 et FTP est limité à 4998+2 fichiers. Que conseiller ?)

La page Error 500 affichait mon adresse mail de et sur OVH.

Il y avait écrit "veuillez contacter Postmaster..."

On ne peut diffuser ici une adresse mail privée à la vue de tout le monde

Bonjour @Rallarros 

J'avoue que je ne comprends pas très bien votre problème.

Via le manager OVH  > Hébergement  > FTP-SSH   >  Restauration, j'ai effectué sans aucun problème la restauration d'un dossier et de ses sous dossiers contenant 9814 fichiers  à deux reprises :
 - Hier soir,
 - Ce matin

Avec FILEZILLA en mode SFTP, je n'ai jamais eu de soucis :
 - Soit pour transférer des fichiers de 500 Mo,
 - Doit pour transférer des dossier et sous dossiers de près 15 000 fichiers.

Voir dans mon guide le paragraphe :  E - Installation du logiciel FTP FILEZILLA  

Bonjour @ Gaston     

oui        Sauvegarde et Restauration en    SFTP avec FileZilla     fonctionnent, 
j'ai découvert tout seul et par hasard
qu'il faut se connecter et remplir les cases en haut comme pour une restauration du FTP,
MAIS qu'il faut juste écrire    22   au lieu de 21    pour le port.

C'est donc une Sauvegarde à J 0,
mais on ne peut pas faire à -snap4, ou -snap3 ,  etc

-----------

C'est ma Restauration du 15 novembre 2025  depuis Hébergement Webcloud
qui a fait disparaître en entier mon multisite, mon site de voyage, mon blog n°1 de voyage, mon blog n°2 d'analyse.

J'ai pu avec grande peine et des centaines d'heures tout rattraper,
sauf le blog n°2 qui a perdu 99% de ses images, alors qu'il est le même Dotclear que le blog n°1.

--------------------------

@fritz2cat 🇧🇪 🇪🇺  l'a écrit aussi (voir plus haut) ,  OVH est responsable, 

                 et j'ai trouvé l'aveu de OVH >>>

et en plus, le 27 novembre, j'ai reçu pour la 1ère fois en 20 ans et sans que je le demande,
un nouveau genre de mail de la part de OVH, qui annonce ceci >>>

[GRA][Web Hosting] - Multiple Databases maintenance notification

Maintenance complete
The scheduled maintenance has been completed. 

>>>

--------------------

Dans mes tickets que j'ai ouverts directement sur le Support OVH,
ils ont écrit des longues phrases vides et sans aide réelle, parfois après trois ou quatre jours,
et ils m'ont juste envoyé voir le mode d'emploi d'une restauration en FTP,
même pas en SFTP, ou en SFTP -snap3, -snap2 quand il était encore temps
et -snap4 se termine aujourd'hui à minuit.
Et, bien sûr ils ne répondent à AUCUNE question.
OVH n'est plus ce qu'il était. Je suis chez eux depuis 20 ans.

----------------

Je relis dans différents filaires de la Community une phrase bizarre >>> " Si vous tenez tellement à votre site... " 
On ne m'a jamais dit >>> si vous tenez tellement à votre brosse à dent.

Hej @ Gaston  

aujourd'hui j'ai refait une installation complète de mon blog n°2, un Dotclear 2.27.3 .

Comme cela, ce blog n°2 est parfaitement "propre", si tant est qu'il y aurait pu contenir des saletés
suite à Restauration J -1 du 15 novembre 2025 plantée à cause de cet "Incident" officiel chez OVH.

Ce blog n°2 est strictement une copie du blog n°1 qui affiche de nouveau tout, 
et dans sa Médiathèque 22415 fichiers en 1121 pages (20 images par page).

Bien sûr, j'ai gardé tous les .htaccess comme le demande impérativement Dotclear.
Ils sont d'office dans le package.

------------------

J'ai téléchargé 19049 fichiers sans problème dans le blog n°2 >>> Public  avec SFTP FileZilla.

Mais, il n'affiche toujours presque pas d'images,
et la Médiathèque arrête toujours le nombre de fichiers à 4999 en 251 pages (20 images par page).

Quoi que je fasse depuis la Restauration plantée du 16 novembre, tout est bloqué sur ce chiffre 4999

------------

Question: est-ce que cette Restore ratée de OVH aurait pu affecter la base de donnée de ce blog n°2   ?

... mais heureusement que j'ai deux blogs Dotclear, je peux comparer...

Je ne suis pas informaticien.
Je cherche dans tous les fichiers php, etc du blog pour voir si se trouve ce chiffre barrière de 4999.

Obs !  Le serveur n°1 de dotclear.org   
s'est détruit irrémédiablement au début du mois de novembre 2025,
et tout le forum de conseils et d'aides a disparu.

Bonsoir @Rallarros 

Quoi que je fasse depuis la Restauration plantée du 16 novembre, tout est bloqué sur ce chiffre 4999

Est-ce que tous ces fichiers sont dans un même dossier ?

Si oui, c'est là la source de la limitation et du blocage.

> On sent bien que ce chiffre 4999 n'est pas un hasard, mais une barrière. 

C'est une limitation du serveur FTP d'OVH.

Hej @ Gaston,

après 17 jours suivant cet incident chez OVH depuis son Restore qui a dû affecter des centaines de clients,

j'ai aussi réussi à restituer l'intégralité et l'intégrité de mon blog d'analyses.

J'avais sur mon laptop une Sauvegarde Média zip.

J'ai décidé et simplement téléchargé 2568 images dans mon blog, toujours dans le quasi-seul et même dossier >>> public.

Il me manque encore un peu moins de 20 images dans mes billets les plus récents.

Et comme on le voit ce dossier est passé de 4999 à  7569 images.

En résumé:

• OVH est responsable de cet incident de Restore officiellement reconnu par sa direction
• il FAUT impérativement garder le .htaccess comme l'écrit dotclear.org
• les dossiers Public de la médiathèque, eux, ne sont PAS limités à 4999 fichiers 
• les deux derniers points m'ont été x-fois présentés ici dans la "Community" comme des must "sinon tant pis" agrémenté x-fois du "si vous tenez vraiment à votre site... alors donnez-moi un moyen de vous contacter", ce qui a été encore plus déroutant et bizarre...

Et ne parlons pas du Support officiel de OVH qui a été complètement NUL, de manière répétée, dans deux tickets.

Bonjour @Rallarros 

J'ai eu ce type d'incident en 2009.

Je l'ai résolu en déplaçant toutes les photos dans des dossiers datés de type : Année/Mois/jour

Depuis : aucun problème avec FILEZILLA.