Wie /var auf separate vmdk als Sicherheit vor dem GAU

[Mr. T]

Hallo,

ich möchte mir gern ein neues System (Debian) aufsetzen und dabei gleich von vornherein die Festplatte so anlegen, dass die Datenbank- und Websever-Daten auf einer separaten Platte abgelegt werden. Der Hintergedanke dabei ist, mit verschiedenen Debian-basierten virtuellen Maschinen (nicht gleichzeitig) darauf zugreifen zu können und - vor allem - für den Fall, dass aus irgendeinem Grund die VM mit dem OS mal kaputt gehen sollte (korrupte Host-System-Festplatte), möchte ich diese Daten gern sicher wissen und unbesorgt das Linux neu aufsetzen können, um die Datenbank- und Webserver-Daten anschließend einfach wieder einbinden zu können.

Allerding scheitere ich schon direkt am Anfagen, wenn es daran geht, das neue System in VMWare einzurichten. Mir ist nicht klar:

a) welche initiale Größe ich dem System zuweisen soll,
b) ob ich damit richtig liege, 2 Platten anlegen zu müssen
c) ob ich damit richtig liege, dass die 2. Platte dann doch in der VM-Konfiguration der VM zugeschrieben wird und es zu Problemen bei der Verwendung durch andere VM kommen könnte

Da ich so etwas nicht jeden Tag mache, sind die verschiedenen Begriffe (Container, Physical Drive, LVM, Virtueller Container, Volume Group) für sich gesehen, einleuchtend, aber sobald ich daran gehe, zu installieren und partitionieren, hab ich ein Brett vorm Kopf.

Könnt ihr mich bitte mal aufklären, ob das geht, was ich ggf. beachten muss und wie ich am besten vorgehe?





Moderator an
Gänsefüsse im KB-Link gelöscht
Moderator aus

[Dayworker]

Ob du den Mountpunkt /var als weitere Platte deines Debian-Gastes einrichtest, spielt für das Host-OS keine Rolle. Wenn dessen Host-Datenträger (SSD, HDD, SD-Card, USB-Stick) defekt ist, hilft dir das im Gast-OS rein garnichts. Du wirst daher nicht drum herumkommen, den abgeschalteten Gast regelmäßig ausserhalb des Host-Rechners auf einen externen Datenträger abspeichern zu müssen.

Ob du den Mountpunkt /var überhaupt auf eine zweite Platte auslagern kannst oder ob /var immer mit auf der Root-Partition liegen muß, entzieht sich meiner Kenntnis. Ich schmeiß im Normalfall fast alles zusammen und richte eigentlich nur für /swap sowie in Einzelfällen auch für /home weitere Mountpunkte auf weiteren VMDKs ein. Swap könnte wichtig werden, wenn man den vRAM deutlich erhöht und die Swap-Partition dazu passend einfacher vergrössern will oder selbige Vergrösserung auch seinen unter /home abgespeicherten Benutzern angedeien lassen will.


Wie du die Aufteilung innerhalb des Gastes machst und dafür eine klassische Partitionierung oder LVM nutzt, mußt du für dich selbst herausfinden. Ich komme auf meiner Entwickler-VM für Cuda unter Ubuntu13.10 jedenfalls mit 10GB aus und ohne den zur Verwaltung der Sourcen eingesetzten Github wäre noch mehr frei als es die momentanen 2GB sind. Ich hab hier aber auch eine VM, ebenfalls unter Ubuntu13.10, mit einer TTRSS-Installation, bei der nur die dafür notwendigste SW sprich Apache, SQL, PHP installiert wurde und die trotz LXDE-Desktop noch über 5GB freien Speicherplatz hat. Bei einer Zabbix-Appliance unter OpenSUSE habe ich die vorherigen 50GB auf 24GB verkleinert und jetzt nach über 24Monaten kontinuierlichen Loggings von 5 Rechnern sind gerade mal 8GB inklu OS belegt. Die Swap-Partition von 2GB kommt noch ontop dazu. Diese richte ich jedoch eigentlich immer als Sparse/Thin sprich Dynamisch ein.

[~thc]

Wenn man im Patitionierungs-Assistenten auf "Manuell" umschaltet, kann man für beliebige Mount-Punkte eigene Platten bzw. Partitionen festlegen. So lässt sich dort auch eine zweite Platte partitionieren und eine Partition "/var" zuweisen.

Den Vorteil, den du dir davon erhoffst - das du die separate Platte einem anderen Gast als "/var" präsentierst - sehe ich allerdings nicht. Unter "/var" liegen viele systemrelevante Daten, die eine "fremde" Neuinstallation erheblich durcheinanderbringen würde.

[Dayworker]

Vielleicht ist /var in diesem Fall der falsche, weil mit zuvielen Abhängigkeiten versehene Mountpunkt. Ich würde dann nur über die direkte Auslagerung von SQL und "htdocs" nachdenken.

[rprengel]

Hallo,

ich möchte mir gern ein neues System (Debian) aufsetzen und dabei gleich von vornherein die Festplatte so anlegen, dass die Datenbank- und Websever-Daten auf einer separaten Platte abgelegt werden.

Hallo,

ich mache ähnlcihes aber ich trenne die Partitionen funktional.
z.B. liegt der Downloadbereich eines Webservers auf einer eigenen Partition.
Gleiches plane ich gerade für den Ordner in dem die mysql-Datenbanken liegen.

Gruss

[Mr. T]

Vielleicht ist /var in diesem Fall der falsche, weil mit zuvielen Abhängigkeiten versehene Mountpunkt. Ich würde dann nur über die direkte Auslagerung von SQL und "htdocs" nachdenken.

Das trifft es. Ich weiß, dass auf /var vor allem dynamisches Zeugs liegt, dass nicht mit anderen Maschinen geteil werden sollte. Mir geht es vornehmlich um /var/www bzw. /srv/www (je nachdem, für welche Variante ich mich entscheide) sowie um Datenbanken unter /var/lib/mysql.

Ich möchte gern verschiedene Distros ausprobieren und finde es extrem praktisch, wenn man die Datenspeicher für Webserver und Datenbank einfach nur zu mounten braucht anstatt doppelte Haushaltsführung zu betreiben und immer nervig Datenbanken hin- und herkopieren zu müssen.

Gleiche Denke bezüglich /home.

Wenn man im Patitionierungs-Assistenten auf "Manuell" umschaltet, kann man für beliebige Mount-Punkte eigene Platten bzw. Partitionen festlegen. So lässt sich dort auch eine zweite Platte partitionieren und eine Partition "/var" zuweisen.

So hatte ich mir das auch vorgestellt. Jedoch war ich mir nicht sicher, ob die Installation dann die Platten verwendet oder ob sie die Ordner dann einfach auf der ersten Platte unter / neu erstellt.

Mein gedanklicher Ansatz ist:

.vdmk1 - 512MB - /boot - Primäre Partition
.vdmk2 - 2048MB - /swap - Primäre Parition

und die folgenden irgendwie in einer Volume Group zusammenzuhalten, um ggf. Vergrößerungen vornehmen zu können.

.vdmk3 - 6144MB - /
.vdmk4 - 5120MB - /home
.vdmk5 - 5120MB - /srv
.vdmk6 - 5120MB - /var für die Datenbanken und den Webserver

Falls das blödsinnig ist, bitte ich um Nachsicht. Ich arbeite mich in dieses Thema gerade erst ein. Partitionierung, LVM und Volume Groups sind Neuland für mich, und ich bin noch dabei, das zu verstehen. Hilfreiche Kommentare hierzu sind gern willkommen.

Insbesondere die letzte Platte bereitet mir Kopfzerbrechen, da ich ja nur bestimmte Verzeichnisse auslagern will - /var/www (sofern ich mich nicht für /www unter /srv entscheide) und /var/lib/mysql. Alles andere soll 'intern' bleiben. [/quote]

[Aricon]

Du kannst generell unter Linux in jeden Pfad ein anderes Verzeichnis bzw. Laufwerk (z.B. per NFS) mounten bis auf wenige Ausnahmen wie /root, /boot etc.

[Mr. T]

Ist klar, nur geht es mir gerade speziell um die vorbereitende Arbeit. Ich möchte gern wissen, ob ich mit meinem Ansatz auf dem richtigen Weg bin oder dies wenig sinnvoll ist (wann ja, warum) bzw. ob es einfacher geht.

[Dayworker]

Wenn du dein System sowieso in getrennte VMDKs und somit Datenträger aufteilst, was willst du da mit LVM?
So wie ich LVM verstanden habe, richtet man sein System darüber ein und verteilt dann damit feinkörnig auf die gewünschten Datenträgergrössen. Wenn du von LVM auch so viel Ahnung wie ich hast, würde ich LVM komplett sein lassen und eine ganz normale Partitionierung anstreben. Einzelne VMDKs kannst du auch so sehr einfach vergrössern, in dem du zuerst die VMDK in der Workstation vergrösserst und dann im Gast-OS die Partition auf die neue Grösse aufbläst.

[rprengel]

Wenn du dein System sowieso in getrennte VMDKs und somit Datenträger aufteilst, was willst du da mit LVM?
So wie ich LVM verstanden habe, richtet man sein System darüber ein und verteilt dann damit feinkörnig auf die gewünschten Datenträgergrössen. Wenn du von LVM auch so viel Ahnung wie ich hast, würde ich LVM komplett sein lassen und eine ganz normale Partitionierung anstreben. Einzelne VMDKs kannst du auch so sehr einfach vergrössern, in dem du zuerst die VMDK in der Workstation vergrösserst und dann im Gast-OS die Partition auf die neue Grösse aufbläst.

LVM macht nur Sinn wenn man auf einer Platte Partitionen fix mal resizen will oder bnach und nach mehr Platten in ein Volume einbinden will.
Ich halte davon nicht viel weil:
1)
Rettungsversiche durch eine zusätzliche organisatorische Schicht müssen
2)
Fliegt eine Platte auseinander sind die Daten weg.

LVM hat sicher seinen Sin aber nicht wenn man sein Partitionen sowieso physikalisch organsiert.

Gruss

[Mr. T]

Wenn du dein System sowieso in getrennte VMDKs und somit Datenträger aufteilst, was willst du da mit LVM? So wie ich LVM verstanden habe, richtet man sein System darüber ein und verteilt dann damit feinkörnig auf die gewünschten Datenträgergrössen [...]

Ich hab in den vergangenen Tagen in den LVM docs an einem Beispiel gelesen (bitte nicht nach einem Link fragen, ich find die Seite grad nicht wieder), dass die Verwendung eines LVM das nachträgliche Einbinden einer neuen Festplatte zur Platzerweiterung die bessere Voraussetzung sei (Stichwort: Volume Group), weil man somit nicht erst umständlich Daten hin- und herschieben müsse, um alte Partitionen löschen und durch neue, größere ersetzen zu können. So hab ichs zumindest verstanden und kann es besser nicht wiedergeben. Wenn das so nicht korrekt sein sollte, bitte ich um Korrektur - auch für andere Leser. Quintessenz des ganzen Lesestoffs war für mich, dass LVM die empfohlene Herangehensweise sei, eine Platte mit mehreren Partitionen zu verwalten - mit Blick auf die Zukunft.

Ich blick doch da auch nicht wirklich durch. Das ist alles Neuland für mich.

[...] eine ganz normale Partitionierung anstreben. Einzelne VMDKs kannst du auch so sehr einfach vergrössern [...]

Wäre mir auch recht. Nur sitze ich wie gesagt bei der dritten Partition, auf die das System kommen soll, wie die Kuh vorm Uhrwerk und weiß nicht weiter. Ich lese Docs, schaue mir Tutorials zur Formatierung bei Youtube an, aber sobald ichs anwenden will, klappts nicht wie vorgestellt und ich grübele, warum und weiß nicht weiter.

Parallel dazu lese ich ein sehr gutes Buch zum Thema, aus dem ich mir auch Anreize geholt habe. Das für mich naheliegendste Beispielszenario basiert beim Autor allerdings auf einem Raid1-Verbund. Ich versuche daraus für mich abzuleiten. Er bereitet die Platten so vor:

* Partition1 - /boot
* Partition2 - swap
* Partition3 - /system (LVM Volume Group)
* /system/root - wird später an / gemountet
* /system/home - wird später an /home gemountet
* /system/srv- wird später an /srv gemountet
* /system/var - wird später an /var gemountet

Bis hier hin bin ich mit dem Autor theoretisch d'accord, weil es meiner Vorstellung der Separation entspricht. Allerdings geht es ganz anders weiter. Da es sich um einen Root-Server handelt, installiert er das System remote aus einem bereits vorinstallierten System heraus (Debian debootstrap). Dazu erzeugt er im debootstrap-Verzeichnis ein Arbeitsverzeichnis /debian, mountet daran Partition 3 und erzeugt die Verzeichnisse, an welche die entsprechenden /system/* Partitionen gemountet werden. An der Stelle bin ich raus, denn

a) will ich keine Remote-Installation vornehmen und
b) weiß nicht, wie ich das Erstellen der /home, /srv, /var Ordner im manuellen Partitionierer im Zuge der Debian-Installation realisieren könnte

Ich hab schon mehrfach mit GParted die Platten partitioniert bzw. auch mit fdisk. Seltsamerweise bootet die VM danach nicht mehr, um die Debian-Installation anzustoßen - selbst ein Reboot von GParted endet mit einem Blackscreen und nicht blinkenden Cursor. Allerdings habe ich am GRUB nichts verändert und auch keinen MBR schreiben lassen, wie es bei der Manuellen Partitionierung während der Installation vorgenommen wird. Das Löschen des Locks hat auch nichts geholfen. Solche unvorhergesehenen Probleme, die ich nicht verstehe und folglich nicht lösen kann, erschweren mir das Verständnis des ganzen noch zusätzlich und verderben mir den Spaß, mich weiter in die Materie einzuarbeiten.

Gehe ichs vielleicht vom Ansatz her schon falsch an? Sollte ich lieber alles auf die 3. Partition installieren und im Zuge der Installation einfach die Option zur Erstellung separater /home, /usr, /var und /tmp Verzeichnisse wählen und im gebooteten System die anderen Container einfach manuell mounten? Wenn ich mir das überlege, komme ich an den Punkt, wo ich denke: "... dann stehen die Datenverzeichnisse aber nicht zur Verfügung, wenn das System bootet - der Webserver findet sein Zielverzeichnis nicht, die Datenbank auch nicht ..."

Ich komme nicht wirklich zu einer Lösung. Das kann doch alles nicht wirklich so schwer sein!?

[rprengel]

Ich komme nicht wirklich zu einer Lösung. Das kann doch alles nicht wirklich so schwer sein!?

Ist es auch nicht aber vielleicht fängst du einfach eine Nummer kleiner an und versuchst nicht sofort das ganz grosse Rad zu drehen.
Es gibt nicht umsonst IHK-Ausbildungen und Studiengänge rund um die IT.
Setzt dir erst mal ein einfaches Debian auf einer Festplatte auf und bring deinen Webserver an den Start.
Als nächstes bindest und eine zweite virtuelle Festplatte ein ziehst z.B. /var/log um.
Damit verhinderst du das die Logfile sein System voll schreiben.
Wenn das bootfest läuft schaust du was ggf. noch trennen willst.
In einer zweiten VM kannst du ja erst mal mit LVM spielen und auch üben wie man von einem Rettungsystem wieder an seine Daten kommt.
"black screen " nach Arbeiten an Partitionen kommen vor wenn der Bootmanager ins leere läuft, Partitionen beschädigt wurden oder Gerätenamen sich geändert haben.
Häufig hilft es ohne den boot-parameter silent zu starten um zu sehen wo das System hängen beibt.
Gruss

[Dayworker]

Die Beispiel-Partitionierung würde ich im virtuellen Umfeld so nie umsetzen. Wozu mit Partitionen rumhampeln, wenn du auch direkt mit mehreren Platten arbeiten kannst?!
Fang doch mal einfach an und erstelle zwei vDISKs namens Boot- und Swap-VMDK. Auf die Boot-VMDK soll das gesamte System ohne Swap kommen. Sieh dir mal dazu bei der Automatischen Installer-Partitionierung an, wo der Installer gedenkt, das Linux zu installieren und welche Mountpunkte er dafür einrichtet. Wenn du bei der Frage der Installerautomatik zur Übernahme der Partitionierung auf NEIN klickst, kannst du die Partitionierung manuell vornehmen. Dabei bleibt root bzw / auf der Boot-VMDK (sollte als "sda" gelistet sein) und den Swap-Bereich verfrachtest du in die Swap-VMDK (sollte als "sdb" gelistet sein).

Wenn du mit den bisherigen Ausführungen nicht hinkommst, blätter mal bei den Ubuntuusers durch. Die haben für echt viele Dinge schon was geschrieben und Ubuntu beruht auf den Debian-Sourcen.


Wenn du damit sattelfester geworden bist, kannst du noch weitere vDISKs in der Workstation anlegen und diese als weitere Mountpunkte in dein lauffähiges Debian-System einbinden.

[Mr. T]

@all

Danke für eure Hinweise und Empfehlungen. Ich glaube, ich werd das wirklich erst mal Stück für Stück angehen.

[e-e-e]

Die Beispiel-Partitionierung würde ich im virtuellen Umfeld so nie umsetzen. Wozu mit Partitionen rumhampeln, wenn du auch direkt mit mehreren Platten arbeiten kannst?!
Fang doch mal einfach an und erstelle zwei vDISKs namens Boot- und Swap-VMDK. Auf die Boot-VMDK soll das gesamte System ohne Swap kommen. Sieh dir mal dazu bei der Automatischen Installer-Partitionierung an, wo der Installer gedenkt, das Linux zu installieren und welche Mountpunkte er dafür einrichtet. Wenn du bei der Frage der Installerautomatik zur Übernahme der Partitionierung auf NEIN klickst, kannst du die Partitionierung manuell vornehmen. Dabei bleibt root bzw / auf der Boot-VMDK (sollte als "sda" gelistet sein) und den Swap-Bereich verfrachtest du in die Swap-VMDK (sollte als "sdb" gelistet sein).

Wenn du mit den bisherigen Ausführungen nicht hinkommst, blätter mal bei den Ubuntuusers durch. Die haben für echt viele Dinge schon was geschrieben und Ubuntu beruht auf den Debian-Sourcen.


Wenn du damit sattelfester geworden bist, kannst du noch weitere vDISKs in der Workstation anlegen und diese als weitere Mountpunkte in dein lauffähiges Debian-System einbinden.

Ich kann mich da nur anschließen. Ich baue regelmäßig Linux-VMs zusammen und benutze dabei (fast) nie den Autoinstaller, sondern immer Variante "GastOS später installieren", lege mir dann statt Partitionen für jeden benötigten Zweig eine separate VMDK an und installiere das System wie bei einer physischen Maschine. Einzelne VMDKs kannst du, falls nötig, später ganz einfach vergrößern.

[Mr. T]

So hab ichs inzwischen auch realisiert. Dazu hab ich mal den Grafischen Installer verwendet, wodurch ich sehen konnte, welche Optionen es alles gibt, und dass man neben den automatisch erzeugten Mountpoints bei der automatischen Installation auch selbst manuell welche vergeben kann.

Allerdings habe ich dadurch ein kleineres Problemchen, welches mit dem Lesen von System-Mails zusammenhängt. Wenn ich per 'mail' meine Nachrichten lesen will und am Ende des Textes per 'q' das Lesen beenden will, erscheint ein Fehler der Art "Cannot create lock file ... /var/mail". Dieses Verzeichnis ist auf eine separate vmdk gemountet.

Die Ursache finde ich sicher auch noch raus.

[Dayworker]

Solche Meldungen deuten in meinen Augen immer auf ein Berechtigungsproblem oder eine bereits geöffnete Datei hin. Sieh dir mal an, welcher Benutzer- bzw Gruppen-Account für sämtliche Einträge unter /var/mail verantwortlich zeichnet und füge deinen Account zumindest dieser Gruppe hinzu.