Linux (allgemein)

ID #1268 1und1-Server: /var/ zu klein

Problem:

Was auch immer sich 1und1 dabei gedacht hat, es ist eine kleine Zeitbombe!
Und zwar werden aktuelle (mind. seit September 2007) dedizierte Server mit folgender Partitionierung ausgeliefert:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1 972404 69576 853432 8% /
udev 2017076 104 2016972 1% /dev
/dev/sda5 4881504 1330576 3550928 28% /usr
/dev/sda6 4881504 156356 4725148 4% /var
/dev/sda7 19532800 296 19532504 1% /home
/dev/sda8 280090688 299216 279791472 1% /srv
none 2017076 32 2017044 1% /tmp

Wie man sieht, sind für das /var/ keine 5 GB reserviert.
Wenn man aber bedenkt, daß in dieser Partition auch User-Spezifische Daten wie MySQL-Datenbanken und Email-Postfächer lagern, wird einem schon mal bange. Die Logfiles tun dann ihr restliches dazu...
Der Festplatten-GAU ist bereits vorprogrammiert.

Lösung:

Es gibt zwei Lösungsansätze:
a) Umpartitionieren (kommt vor allem bei frischen Systemen in Betracht)
b) Email-Postfächer und MySQL-Dateien verlagern (Quick & Dirty)

a) Umpartitionieren:

Es gibt Um-Partitionierungs-Programme, die die ganze Arbeit für einen Abnehmen können. (Programm-Tips bitte als Kommentar oder per Kontaktformular.)

Das Prinzip ist jedesmal das Selbe:

  1. Booten im Rescue-System
  2. Sichern der Daten der zu veränderten Partition auf eine davor liegende Partition.
  3. Partition(-en) ändern und schreiben.
  4. Mit mkfs die Partitionen formatieren.
  5. Die gesicherten Daten auf die veränderten Partition(-en) zurück spielen.

Eine Anleitung wie man die letzte Partition verkleinert um dann evtl. dahinter eine neue Partition anlegt findet sich im Server Support Forum. (Genauer Link ist leider verloren gegangen.)

b) Verlagern:

Wir verlagern wie angekündigt die MySQL und die Email-Daten auf die /srv/-Partition:

#stoppen der Dienste:
/etc/init.d/qmail stop && /etc/init.d/xinetd stop
/etc/init.d/mysql stop

#Verlagern:
mv /var/qmail /srv/.
ln -s /srv/qmail /var/qmail
mv /var/lib/mysql /srv/.
ln -s /srv/mysql /var/lib

#neustart der Dienste:
/etc/init.d/qmail start && /etc/init.d/xinetd start
/etc/init.d/mysql start

Sicherheitshalber in den Logfiles nachsehen, ob der Restart korrekt vollzogen wurde oder ob es Probleme gab.

Update-Artikel: Partitionierung bei 1und1 mit LVM

 

sozial Bookmarking
Bookmarken bei YIGG Bookmarken bei Mister-Wong Bookmarken bei Icio Bookmarken bei del.icio.us Bookmarken bei Technorati Bookmarken bei Furl Bookmarken bei Spurl Bookmarken bei Yahoo Bookmarken bei Google

vom 2007-10-24 14:37, zuletzt 2011-12-01 08:02     Artikel ausdrucken Artikel weiterempfehlen Als PDF-Datei anzeigen

Dieser Inhalt ist unter der Creative-Commons Lizenz lizensiert.

Probleme bitte im Server-Support-Forum diskutieren.

überflüssig 1 2 3 4 5 wertvoll  
Durchschnittliche Bewertung:   3.71 von 5 (7 Bewertungen)

Artikel kommentieren

Kommentar von Roger Wilco (2008-03-28 17:36:19):
Warum die Krücke mit den Symlinks? Einfach das Datenverzeichnis für MySQL (bzw. den mysqld) in der /etc/mysql/my.cnf ändern.
Analog sollte es mit qmail funktionieren (/etc/psa/psa.conf -> QMAIL_MAILNAMES_D und danach die Mailkonfiguration neu generieren lassen).

Kommentar von huschi (2008-05-13 21:13:59):
Der Grund für die "Krücke" ist ganz einfach:
Damit bleiben die Verzeichnisse dort, wo jeder erfahrene Admin sie als erstes Vermutet und das "Versteckspiel" bleibt aus. :)

huschi.

Kommentar von Quante (2008-05-28 06:12:43):
Habe das ganze so durchgezogen. Gab auch keinerlei Probleme. Nach einigen Wochen wollte ich nun eine neue Mailadresse anlegen. Diese ist sichtbar aber empfängt keine Mails. Ebenso funktionieren Mailgruppen nicht mehr. Es wurde sonst nichts verändert. Ideen?

Kommentar von huschi (2008-09-06 08:35:16):
Bei OVH-Servern sieht es ähnlich aus. Hier sind sogar nur 2,9 GB für das gesamte root(/)Verzeichnis eingerichtet. Die restliche Festplatten-Kapazität hängt unter /home/.

Dateisystem Größe Benut Verf Ben% Eingehängt auf
/dev/sda1 2,9G 2,8G 0 100% /
/dev/sda2 456G 33M 432G 1% /home

Kommentar von Webschmied (2009-11-09 18:53:12):
Zunächst: danke! Funktioniert.
Gleiches sollte mit var/lib/psa/dumps/ gemacht werden. Hier laufen sämtliche Plesk-Backups auf. Siehe http://www.huschi.net/2_296_de-festplatte-voll.html , wenn da mal ein Backup nicht auf den Backup-Space geschoben werden kann, ist die Partition voll.

Kommentar von Thomas (2011-11-30 15:21:53):
Der Artikel ist schon ein Stück alt aber einen Kommentar wert ;)

1und1 benutzt bzw. legt dynamische Partitionen an die man dann selbst (mit einem LVM - Logical Volume Manager) in der Größe verändern kann. Sollten mounts wie "/dev/vg00/var" vorhanden sein, kann man davon ausgehen, "vgdisplay -v vg00" sollte Klarheit schaffen und mit "lvextend -L +150G /dev/vg00/var" bekommt man z.B. 150GB dazu. Nun noch das Dateisystem vergrößern (z.B. bei xfs mit "xfs_growfs /var"). Beachtet bitte, das sich die obigen Befehle immer auf den oben genannten Beispielpfad und xfs als Dateisystem beziehen.

Ich hoffe es hilft doch noch einigen ... vg tom

Kommentar von huschi (2011-12-01 07:03:44):
Danke Tom!
Allerdings gibt es bereits ein Nachfolge-Artikel mit der LVM-Partitionierung:
http://www.huschi.net/30_411_de.htm

Kommentar von mrs.knaeck (2012-01-13 11:09:18):
Gab es bei jemandem ähnliche Probleme wie Quante sie hatte? Weil sonst würde ich das ganze jetzt gern als Übergangslösung nutzen bis ich einen neuen Server hab...