Speicherplatz in Plesk

rhartinger

New Member
Hallo,

ich erhalte seit heute laufend Fehlermeldungen in Plesk. Laut Strato liegt es daran dass mein Speicher voll ist. Ich habe Version psa v8.2.0_build82070706.15 os_SuSE 9.3

Die HTML Seiten auf den Domains belegen nciht soviel Speicher wie ich habe. Allerdings wird in der Statistik des Servers unter Festplattenauslastung angezeigt dass ich nur 150 MB frei habe. Wo kann ich denn hier was lsöchen dass ich mehr von den 10 GB frei kriege
 
Du hast gerademal 1,5 MB frei.
Code:
du -ma | sort -rn | more
gibt dir eine sortierte Liste aller Verzeichnisse und Dateien, so kannst du am Ehesten herausfinden, was deinen Speicherplatz frisst.
 
Das sieht dann so aus. Alle weiteren Verzeichnisse haben eine 1 davor stehen
Wenn ich nur wüte wo der Speicher verbraten wird? Wo finde ich die Imapdaten? Auf einer Domain werden die MAils mit Imap geholt

940 .
938 ./psa
246 ./psa/PSA_8.1.0
229 ./psa/PSA_8.1.0/dist-rpm-SuSE-9.3-i386
209 ./psa/PSA_8.0.0
174 ./psa/PSA_8.0.0/dist-rpm-SuSE-9.3-i386
164 ./psa/PSA_8.1.1
163 ./psa/PSA_8.1.1/dist-rpm-SuSE-9.3-i386
163 ./psa/PSA_7.5.4
157 ./psa/PSA_8.2.0
143 ./psa/PSA_8.2.0/dist-rpm-SuSE-9.3-i386
140 ./psa/PSA_8.1.0/dist-rpm-SuSE-9.3-i386/opt
107 ./psa/PSA_8.0.0/dist-rpm-SuSE-9.3-i386/opt
98 ./psa/PSA_8.1.1/dist-rpm-SuSE-9.3-i386/opt
96 ./psa/PSA_7.5.4/rpm_SuSE_9.3
89 ./psa/PSA_8.1.0/dist-rpm-SuSE-9.3-i386/base
86 ./psa/PSA_8.2.0/dist-rpm-SuSE-9.3-i386/opt
80 ./psa/PSA_8.1.0/dist-rpm-SuSE-9.3-i386/opt/vault
72 ./psa/PSA_7.5.4/rpm_SuSE_9.3/opt
67 ./psa/PSA_8.1.1/dist-rpm-SuSE-9.3-i386/opt/vault
67 ./psa/PSA_8.0.0/dist-rpm-SuSE-9.3-i386/base
60 ./psa/PSA_8.0.0/dist-rpm-SuSE-9.3-i386/opt/vault
56 ./psa/PSA_8.2.0/dist-rpm-SuSE-9.3-i386/base
 
Unter einer Domain stehtbei den Berichten Benutzter Speicher von Logdateien und statistische Berichte 1.58 GB

Wenn ich mich mit ftp einlogge finde ich aber die Dateien nciht. Wieso kann ich die nicht löschen?
 
/statistics/logs/ (im entsprechenden VHOST)

die Dateien gehören bestimmt dem User ROOT oder sonstigen und nicht dem FTP User ?

Also auf ssh einloggen in das Verzeichniss wechsel, prüfen warum die LOG's so groß sind, sind sie schon rotiert / gepackt ?
 
Da komtm dann das


find: WARNING: Hard link count is wrong for /proc/vz: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
find: /proc/11531/task: No such file or directory
find: /proc/11531/fd: No such file or directory
find: /proc/15667/task: No such file or directory
find: /proc/15667/fd: No such file or directory


Wie st das eigentlich mit einer Neuinstallation des Servers? Wie kann ich alle Datenbanken, Kundendaten, Websites, Emailadressen usw... wieder zurücksichern? Bei Strato ist die Neuionstallation relativ einfach aber es sind dann alle Daten weg. Kann ich irgendwie alles in Plesk sichern und dann zurückspielen?
 
Du musst ja nicht gleich den Server neuinstallieren ich würde erstmal hergehen und alle Logfile leeren die so rumfahren... meisten sind in den Kundenverzeichnissen direkt z.b. /srv/www/vhosts/geiledomain.tld/logs/ diverse riesen Logs drinne... Hast du im Plesk auch jeweils das Logrotate eingeschalten? Sprich das er auch nach 3 Monaten oder so die Logfiles kickt?
 
Die Fehlermeldung ist Banane. Liegt daran, dass Du einen vServer hast. Mich wundert allerdings, dass er keine Dateien findet, die größer als 50 MB sind. Hast Du das als Root ausgeführt?

Edit: Ähm, hallo?! Wenn mein Befehl keine Dateien ausgibt, wirds eng.
 
Du solltest in naher Zukunft auf einen managed Server wechseln. Das liest sich ja fürchterlich.

Poste uns die Ausgabe von
Code:
df -h
Danach dann bitte
Code:
du -h --max-depth=1 /
(Den Slash hinten nicht vergessen).
 
Ganz großes Kino...! :mad:
Code:
/etc/init.d/syslog restart
kannst gleich hinterherjagen. Aber ich glaube, Du wirst da gleich massiv Probleme haben...
 
Angst und Panik sind keine guten Ratgeber. Erst recht nicht in der fatalen Situation, in der Du Dich gerade befindest, zwischen Atomkrieg und Pilzbefall.

0) ssh auf Server und zum Sub0r Us0r werden (su)
1) du --max-depth=1 -h /
2) Das Verzeichnis, das viel belegt verfolgen mit
du --max-depth=1 -h /VerzeichnismitvielDatendrin/
3) Wiederhole das solange, bis Du bei dem Verzeichnis angekommen bist
4) Lösche überflüssige
5) packe wichtige Files mit gzip -9 FILENAME

Grüße
Sinepp

P.s.: Da war der Herr Marneus wohl schneller.
 
Der beobachtete Effekt kann u.U. daran liegen, dass ein Programm, dass eine (log-Datei) zum Schreiben geöffnet hält, munter weiterschreibt, während die Datei zwischenzeitlich durch ein anderes Programm (z.B. logrotate) umbenannt und komprimiert wurde (die ursprüngliche Datei wird beim Komprimieren gelöscht).
Die gelöschte Datei taucht dann bei einem 'ls' oder 'du' nicht mehr auf, braucht aber immer noch die i-nodes im Dateisystem und sorgt für hohe Werte beim 'df'.
Sobald das Programm beendet wird, verschwindet die Datei dann wirklich und der Plattenplatz wird wieder frei gegeben. Vermutlich konnte logrotate eines der Programme nicht beenden und neu starten und hat damit den Effekt verursacht.
Also entweder mit 'lsof' versuchen, das Programm zu identifizieren, das die Datei geöffnet hält, oder einfach die klassische Windows-Variante (reboot) wählen.

Viele Grüße,
LinuxAdmin
 
Last edited by a moderator:
Back
Top