VPS HS suite espace disque saturé puis BD supprimée

ThibautP 2018-06-04 10:20:16 UTC #1

Hello ;)

Je débute en VPS et j'ai un gros souci. Sur un VPS comptant 3 sites WordPress fonctionnels, j'ai ajouté un nouveau site et j'ai saturé l'espace disque en essayant des créations de contenu automatisées. Mon VPS est alors planté avec message d'erreur pour m'indiquer le souci. Sauf que je ne peux pas accéder à mon interface Plesk, seul le SSH est disponible.
J'arrive après moultes péripéties dans cd /var/lib/mysql et je supprime la base de données problématique qui a occupé tout l'espace disque. Or, depuis, le VPS est complètement HS (plus d'erreur mais inaccessible). OVH me parle de plantage KVM mais ça reste du chinois.

Quelqu'un aurait une idée pour me permettre de m'en sortir ? J'ai voulu faire une sauvegarde en ligne de commande de mes bases de données mais j'ai toujours une erreur (probablement à cause de l'espace de stockage)...

Merci <3

janus57 2018-06-04 11:05:15 UTC #2

Bonjour,

Quel est le message d'erreur quand vous vous connectez via le KVM ?

Cordialement, janus57

ThibautP 2018-06-04 12:08:00 UTC #3

Hello Janus.

Voici en PJ, cela vous aide ?

janus57 2018-06-04 15:18:50 UTC #4

Bonjour,

Vous avez effectué quoi comme commande exactement avant qu'il affiche ça ?

Car j'ai l'impression que vous avez supprimé des choses que vous n'auriez jamais dû supprimer.

Cordialement, janus57

ThibautP 2018-06-04 19:17:01 UTC #5

Alors j'ai surtout essayé de localiser l'endroit où était ma base de données puis de supprimer celle qui me posait problème.

Voici ce que j'ai du faire en rescue :

login as: root
root@vpsXXX.ovh.net's password:
root@rescue-pro:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 2.9G 1.6G 1.2G 57% /
udev 10M 0 10M 0% /dev
tmpfs 393M 5.3M 388M 2% /run
tmpfs 982M 0 982M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 982M 0 982M 0% /sys/fs/cgroup
/dev/vdb1 9.8G 9.4G 0 100% /mnt/vdb1
root@rescue-pro:~# chroot /mnt/vdb1/
[root@rescue-pro /]# ls -l
total 184
-rw------- 1 root root 9216 May 31 22:42 aquota.group
-rw------- 1 root root 9216 May 31 22:42 aquota.user
dr-xr-xr-x. 2 root root 4096 May 18 03:30 bin
dr-xr-xr-x. 4 root root 4096 May 26 00:44 boot
drwxr-xr-x 2 root root 4096 Oct 4 2017 cgroup
drwxr-xr-x. 2 root root 4096 May 31 22:03 dev
drwxr-xr-x. 105 root root 12288 Jun 4 14:43 etc
drwxr-xr-x. 6 root root 4096 Sep 18 2017 home
dr-xr-xr-x. 12 root root 4096 Sep 12 2017 lib
dr-xr-xr-x. 9 root root 12288 May 18 03:30 lib64
drwx------. 2 root root 16384 Mar 3 2017 lost+found
drwxr-xr-x. 2 root root 4096 Sep 23 2011 media
drwxr-xr-x. 2 root root 4096 Sep 23 2011 mnt
drwxr-xr-x. 5 root root 4096 Sep 12 2017 opt
drwxr-xr-x. 2 root root 4096 Mar 3 2017 proc
dr-xr-x---. 6 root root 4096 Oct 8 2017 root
drwxr-xr-x 3 root root 4096 Sep 12 2017 run
dr-xr-xr-x. 2 root root 12288 May 18 03:30 sbin
drwxr-xr-x. 2 root root 4096 Mar 3 2017 selinux
drwxr-xr-x. 2 root root 4096 Sep 23 2011 srv
drwxr-xr-x. 2 root root 4096 Mar 3 2017 sys
drwxrwxrwt. 4 root root 36864 May 31 22:42 tmp
drwxr-xr-x. 13 root root 4096 Mar 14 2017 usr
drwxr-xr-x. 24 root root 4096 Sep 12 2017 var
[root@rescue-pro /]# cd /var/lib/mysql
[root@rescue-pro mysql]# ls -l
total 421956
drwx------ 2 mysql mysql 4096 Sep 12 2017 apsc
drwx------ 2 mysql mysql 4096 Sep 12 2017 horde
-rw-rw---- 1 mysql mysql 421527552 May 26 00:42 ibdata1
-rw-rw---- 1 mysql mysql 5242880 May 31 22:42 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 May 31 22:42 ib_logfile1
drwx------ 2 mysql mysql 4096 Sep 12 2017 mysql
drwx------ 2 mysql mysql 4096 Sep 12 2017 phpmyadmin_XJbioXXX
drwx------ 2 mysql mysql 12288 Sep 15 2017 psa
drwx------ 2 mysql mysql 4096 Sep 12 2017 roundcubemail
drwx------ 2 mysql mysql 4096 May 25 01:08 BD1
-rw-r--r-- 1 root root 0 Jun 4 11:11 [BD1].sql
-rw-r--r-- 1 root root 0 Jun 4 11:11 BD1.sql
drwx------ 2 mysql mysql 12288 May 25 04:00 BD2
drwx------ 2 mysql mysql 12288 Sep 12 2017 sitebuilder5
drwx------ 2 mysql mysql 4096 May 3 13:18 BD3
drwx------ 2 mysql mysql XXX XXX 3 13:18 BD4 (ce que j'ai supprimé via la commande rm)

A ce stade, je pensais avoir supprimé ma base de données problématique BD4 qui était la seule occurence relative au site en question. Avant cette suppression, j'avais un message d'erreur :

"ERROR: Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] No such file or directory

Mon idée était donc de supprimer ma BD pour récupérer de l'espace disque mais, après la fameuse suppression, je n'ai plus d'erreur au redémarrage mais un VPS HS (pas de ping).

Cela vous éclaire ?

janus57 2018-06-04 19:22:47 UTC #6

Bonjour,

pas trop, vu que l'erreur que vous avez dans les KVM est probablement dû à la suppression d'un élément du système.

Perso à ce stade je vois 2 solutions :
1 - repartir de zéro sur des backups
2 - voir avec le support de plesk

Enfin, il ne faut jamais essayer de supprimer des choses comme ça pour gagner de la place, si vous voulez supprimer une BDD par exemple il faut le faire proprement en ligne de commande et pas supprimer le fichier de la base (car en générale il est pas seule).

Cordialement, janus57

ThibautP 2018-06-04 19:25:31 UTC #7

Alors repartir de zéro, c'est compliqué vu que je n'ai pas check les backups et je doute. Je voudrais récupérer les bases de données des trois autres sites avant de reset le VPS.

Je n'avais pas pensé à Plesk mais j'ai peur :)

Et je pensais bien faire et supprimer proprement mais aucun gain au niveau du stockage ni de changement... Vous savez s'il y a une poubelle et un moyen de restaurer tout ça ?

janus57 2018-06-04 19:34:14 UTC #8

Bonjour,

ah non, sous Linux un coup de RM est pratiquement définitif sauf à passer par des logiciel de récupération (et encore là dans ce cas précis je suis même pas sûr).

Normalement si vous payez une licence plesk vous avez accès au support, après vu les manipulation effectué, il peuvent refuser par contre.

Enfin vu que c'est plesk et que je sais pas comment c'est greffé à l'OS (d'ailleurs en dessous c'était quoi, du CentOS ?), c'est là aussi dur de donner des bonnes solutions/pistes.

L'erreur que vous avez mis en image semble correspondre à la désactivation/suppression de SELinux ou de sa configuration, ce qui fait planter le boot car SELinux est censé être présent au boot.

Cordialement, janus57

ThibautP 2018-06-04 20:19:21 UTC #9

Quand j'ai lu ça, je me suis dit que c'était ma BD et comme je ne trouvais rien pour manœuvrer en ligne de commande, j'ai tenté...

Oui CentOS dessous et oui, j'ai une licence Plesk.

Et pour l'erreur, je n'ai rien vu. C'est le support OVH qui m'a envoyé le screen...

ThibautP 2018-06-04 20:43:47 UTC #10

Et donc non : We identified that the Plesk license was purchased not directly from Plesk but through one of the Plesk Resellers.In this case, you need to contact your license provider for support service.

Le seul support reste OVH du coup mais cela tourne en rond.

janus57 2018-06-04 21:00:21 UTC #11

Bonjour,

le support OVH ne fera rien, c'est certain c'est écrit dans les CGU/CGV que vous êtes le seule et unique responsable du VPS et êtes capable de le gérer.

Cordialement, janus57

ThibautP 2018-06-04 21:31:26 UTC #12

Ils me l'ont déjà dit, c'est pour ça que je passe par le forum comme ils me le demandent ;)

ThibautP 2018-06-04 21:32:17 UTC #13

Il faudrait que j'arrive en rescue à vider /dev/vdb1 9.8G 9.4G 0 100% /mnt/vdb1 car full et j'arriverai peut-être ensuite à me débrouiller pour récupérer mes BD.

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVH Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres OVH Community.