Empfehlungen Partitionsgrösse

stebu

New Member
Ich habe bei Hetzner einen Root-Server mit 2x160 Gb, den ich mit Raid 1 konfigurieren möchte. Wir möchten das Gerät ausschliesslich als Webserver brauchen und vor allem Typo3/Joomla! und Moodle nutzen. Dabei werden wir wohl realtiv viele Fotos und einiges an Videos einsetzen. Ich suche nun eine Empfehlung für die verschiedenen Partitionsgrössen. In der Literatur habe Empfehlung für die untenstehenden Verzeichnisse gefunden, bei den angegebenen Grössen war mir aber nicht klar, auf welche Festplattengrösse und welche Einsatzart sich das bezog.
Zudem bin ich nicht sicher, wo ich die Typo3/Joomla!- und Moodle-Daten ablegen soll - in das Verzeichnis /var?? (Dann müsste wohl dieses sehr gross sein)
Welche Partitionsgrössen kann man mir empfehlen? Sollte ich noch weitere Partitionen einrichten?

/ (root) - 300 MB??
/ (swap (2GB, weil wir 1 GB RAM haben)
/tmp - 200 MB
/var - 10 GB
/var/lib - ?
/usr - 5 GB
/home - Rest
brauche ich ein /boot?
 
Last edited by a moderator:
swap-files oder -Partitionen sollte man nur dann aktivieren, wenn man sie wirklich braucht, sonst swappt der Rechner sinnlos - und alles wird langsam. Regel: wenn man open office benutzt, swap bis incl. 256 MB Speicher (swap-File auch 256 MB); wenn nicht, swap wenn man nur bis incl. 128 MB Speicher hat (swap-File selbe Grösse)

Bzgl. sonstiger Partitionen, halte ich selbst die 'Sicherheitsgründe' mehrere zu machen nur für theoretisch relevant, und tue alles (für einunddieselbe Linux-Installierung) in eine Partition, aber das mag bei gemieteten / von vielen Leuten zusammen benutzten Servern vielleicht anders sein.
 
Also ich kam bislang immer mit einer SWAP die doppelt so groß wie der Ram ist aus, ohne das sinnlos geswappt wird.
Bei 1 GB Ram und Raid 1 mit 2x160GB würde ich so partitionieren:

/ 158GB
swap 2GB

Und bislang bin ich damit gut gefahren :D
 
Also muss ich eher keine Angst haben, wenn ich nur eine Partition (neben SWAP) mache? Ist das Risiko, dass mir irgendein Teil voll wird und damit der Server zum Absturz kommt nicht als allzu gross einzuschätzen?
Die eine Partition würde die Verwaltung natürlich stark vereinfachen.
 
HiHo

In der Literatur habe Empfehlung für die untenstehenden Verzeichnisse gefunden, bei den angegebenen Grössen war mir aber nicht klar, auf welche Festplattengrösse und welche Einsatzart sich das bezog.
...
brauche ich ein /boot?

Nun, da mir nicht genug Informationen ueber Deine Quellen vorliegen koennte ich Dir da leider nur eher ungezielt bis gar nicht Erlaeuterungen zu geben aber da ich da so eine Ahnung habe, worum es dabei gehen koennte mal meine Darlegung fuer Deinen Fall.
1. Swap auf eigene Partition = gut (besser als ein swapfile).
2. /boot brauchst Du, aber es muss nicht auf einem separat eingehaengten Dateisystem liegen.
3. Von vorne herein mehrere Dateisysteme einzuhaengen macht besonders dann Sinn, wenn man sie durch Austauschen der darunter liegenden Datentraeger ersetzen koennte z.B. ein /home auf einer 800MB grosser HDD durch eines auf einer 8GB grossen HDD austauschen.
Auch fuer die Lastverteilung und ggfs. fuer die Datensicherung kann man da sinnvolle Konfigurationen erstellen.
Da sowas in Deinem Fall wohl nicht der Fall ist und auch nicht werden wird faellt diese Motivation flach.
4. (Und damit beschaeftigte sich evtl. auch die von Dir genannte Literatur) Man will fuer unterschiedliche Nutzungsarten unterschiedlich eingerichtete Dateisysteme haben, extn mit grossen Bloecken fuer grosse (Multimedia/Datenbank) Dateien und ext2 mit kleinen Bloecken fuer kleine und besonders viele Dateien (Textarchive, Script-Libraries also auch die Script-frameworks Typo3 und Joomla bieten sich hierfuer an). Dazu siehe auch mkfs.ext2(8): create ext2/ext3 filesystem - Linux man page dort die Optionen -b und -T.

Meine Meinung zu dem einzig relevanten Punkt 4 ist, dass es sich nicht lohnt zum einen den Aufwand in der Konfiguration zu machen. Die Scriptframeworks sind nur wenige MB/zig-MB gross und muessen nicht fuer jeden "Auftritt" volstaendig dupliziert werden (=> link ), der Einspareffekt wuerde zwischen einem grob- oder fein-geblockten Dateisystem nicht wirklich gross sein in Relation zu den verfuegbaren zu erwartenden 145 GB.
Ausserdem hat man noch Verschnitt, da man die Kapazitaeten der Dateisysteme nicht einfach verschieben kann dorthin, wo man sie halt braucht.

Mach einfach mal eine Referenzinstallation lokal (wenn das produktiv laufen soll empfehle ich auch eine Referenzumgebung im LAN um z.B. Updates zuerst dort durch zu spielen), da kannst Du etwas den Einfluss des Dateisystems auf den Speicherbedarf der Dateien in Deiner konkreten Konfiguration ermitteln und dann entscheiden, ob sich sowas lohnt.
Ansonsten bin ich der Meinung, dass bei den verfuegbaren Kapazitaeten eigentlich der Aufstand nicht lohnt und man sich besser ein grosses Dateisystem zur flexiblen Verwendung hernimmt, ist doch ueppig Platz da (das antizipiere ich einfach mal da ich ueber Deinen konkreten Platzbedarf keine informationen habe).

Ciao,
Mercy.

P.S.: Wenn ich nicht sehr falsch liege werden die Inhalte, ueber die euer Webserver gebieten soll ebenso wie etwaige Datenbanken unterhalb von /var liegen und nicht unter /home, ich hielte dann fuer sinnvoller ein kleines Dateisystem unter /home einzuhaengen und den Rest unter /var statt andersrum. Aber das kann in Deiner Konfiguration natuerlich auch anders sein.

Edith sagt: Upds da habsch schon wieder zu lange geschrieben ... Das
Ist das Risiko, dass mir irgendein Teil voll wird und damit der Server zum Absturz kommt nicht als allzu gross einzuschätzen?
steckt hinter dem was ich mit Verschnitt meine, Du hast im Endeffekt nur ca 145 GB raus, je mehr Dateisysteme Du daraus machst, desto groesser ist die Wahrscheinlichkeit, dass Dir mal eines davon ueberlaeuft.
 
Last edited by a moderator:
Vielen Dank für die umfangreiche Antwort. Für meinen Fall treffen wie vermutet die 4 Gründe eher weniger zu, am ehesten noch die verschieden Dateisysteme.
Der Autor (Dezidierte Webserver, Hilscher) argumentierte mehr auf dieser Ebene: Wenn einzelne Dienste, Benutzer oder bei einem Einbruch zu viele Daten ablegen, wird bei mehreren Partitonen nur eine gefüllt. Der Server bleibt immer noch lauffähig. So können zu grosse Logfiles beispielsweise nicht den Server blockieren.
 
HiHo
Wenn einzelne Dienste, Benutzer oder bei einem Einbruch zu viele Daten ablegen, wird bei mehreren Partitonen nur eine gefüllt. Der Server bleibt immer noch lauffähig. So können zu grosse Logfiles beispielsweise nicht den Server blockieren.

Na ganz ist das nicht von der Hand zu weisen, es hatte schon seinen Grund, dass mir unter 3. ausgerechnet /home als ein evtl. zu erweiterndes weil voll gelaufenes Dateisystem in den Sinn kam.
Aber dafuer kann man heute auch quotas auf software Ebene setzen habe mich allerdings damit noch nie beschaeftigt.
So oder so ist es aber halt problematisch da Regeln zu erstellen; Wenn /var/log vollaeuft glaube ich nicht, dass Webserver und Datenbank das moegen werden und alle anderen Dienste, die dahin loggen auch nicht.;)
Wenn die home-Verzeichnisse voll laufen wird der mailserver wohl seinen Job nicht richtig machen etc.p.p. .
btw. gibts fuer logfiles speziell logrotate(8): rotates, compresses, and mails ... - Linux man page

Alles in allem macht es schon Sinn, die kritischen Dateisysteme vor Ueberlaeufen zu schuetzen ist halt dann die Frage was fuer den Einzelnen so als kritisch durchgeht. Und letztlich kommt es ja auch auf die Art eines Einbruches an, wie man dem dann begegnen kann. Wenn Du keine User hast, die Daten in /home beliebig aendern wuerden brauchts das nicht zu begrenzen und wenn doch knallt es halt weil /home voll ist.

Wenn fuer Dich also hinreichend wichtig ist, dass das System selbst noch einwandfrei laeuft auch wenn evtl Webserver, Datenbanken, Maildienste, Webfrontends und so im Eimer sind, dann macht so eine Massnahme Sinn nur schau dann am Besten auch mal mit einer Referenzimplementierung vorab, wo Du welche Kapazitaeten brauchst (/home, /var/lib /var/log und so) denn das laesst sich nachtraeglich nicht so einfach aendern ohne die vorliegenden Daten irgendwo anders zwischen zu lagern (hast Du eigentlich bei dem Paket/hoster 100% FTP-Backup Kapaziateten?), Aufwaendig wird eine nachtraegliche Veraenderung auf jeden Fall.
Fazit: Wenn so eine Massnahme getroffen wird muss man auch einen Plan haben, wie man verfaehrt, wenn der Schadensfall eintritt und sich mit den Konsequenzen dann auch arrangieren koennen. Damit denke ich nicht zu letzt auch an den Aspekt, dass Dir bei mehreren kleinen Daten haltenden Dateisystemen natuerlich eher mal eines ueberlaeuft aus ganz natuerlichem Grunde und dann muss man halt wissen, welche Massnahmen man dann ergreift denn einfach groesseres Medium drunter klemmen ist bei den meisten hostern nicht drin.


Ciao,
Mercy.
 
Das Offensichtlichste ist mir natuerlich wieder runter gefallen;
Wenn jemand Dein System angreift und die sage und schreibe 140 GB vollkuebelt dann
- hat er das System uebers Netz Monate lang vollgekuebelt waehrend Du Monate lang durch Abwesenheit geglaenzt hast (sehr unwahrscheinlich) oder
- hatte er lokalen Zugriff und dein /dev/null irgendwohin entleert, wenn er lokal ans System kommt hast Du aber noch ganz andere Probleme und sowas Auffaelliges wie das Dateisystem zum Ueberlaufen bringen waere das letzte, was ich machen wuerde oder
- /temp wird vom Virenscanner aufgeblasen weil ein wenige Byte grosser Dateianhang entpackt wird (dem kann man auch anders vorbeugen, der Anhang ist uebrigens ein gepacktes Archiv das eine unendlich grosse Zahl ein und desselben Zeichens enthaelt).

Ich denke doch, Du kannst auch mit quotas (Disk Quota - LinuxClub) auf dem Dateisystem und den Konfigurationsmoeglichkeiten der Dienste auskommen fuer z.B. Limit beim Entpacken von Dateianhaengen, beim FTP/http upload etc. .
Ansonsten ist es halt sehr unwahrscheinlich, dass 100+ GB uebers Internet einfach mal eben so gefuellt werden. ;)
Zumal das System ja nur als Webserver mit CMS dienen soll.

Ciao,
Mercy.
 
Back
Top