[SOLVED] Alternative Vorgehensweise im Fall eines Systemcrashes möglich?

[whiterabbit]

Hi.
Folgendes Szenario: unsere Proxmox-Installation befindet sich auf einem Storage und alle VMs liegen in einem RAID-10 (also getrennt vom System) auf einem zweiten Storage.

Wenn nun durch einen Defekt das System neu erstellt werden muss, hat man eine Neuinstallation ja schnell erledigt. Das Einspielen von div. Backups dauert da schon länger. Daher meine Frage: Das müsste doch doch schneller gehen, indem man vom laufenden System die Dateien
/etc/network/interfaces sowie den Ordner mit den Conf-Dateien unter
/etc/pve/nodes/pve/qemu-server rettet und in das neu installierte System zurück holt?

Anschließend noch das alte RAID wieder mouten und als Storage einbinden. Fehlen da noch andere Dateien "auf der System-Seite" oder würde das ausreichen, damit die VMs dann sofort wieder starten??

 

[dietmar]

Anschließend noch das alte RAID wieder mouten und als Storage einbinden. Fehlen da noch andere Dateien "auf der System-Seite" oder würde das ausreichen, damit die VMs dann sofort wieder starten??

Ja, das sollte funktionieren.

 

[tschanness]

Alternativ ein ZFS Raid 10 bauen, dann geht das "von selber" sobald der Pool wieder gemountet wird. Ist mir heute aufgefallen

LG Jonas

 

[LnxBil]

Auf Systemen mit 2 Storages und im gleichen Layout wie deines kopiere ich mir täglich via rsnapshot oder einfachem rsync das System vom 1. Storage auf das 2 (inkl. /boot), sodass ich es noch schneller wiederherstellen kann. Arbeitsaufwand dafür ist sehr gering, dafür reduziert sich die Wiederherstellungszeit dramatisch.

 

[whiterabbit]

Auf Systemen mit 2 Storages und im gleichen Layout wie deines kopiere ich mir täglich via rsnapshot oder einfachem rsync das System vom 1. Storage auf das 2 (inkl. /boot),

Ok, darüber dachte ich auch schon nach, doch dann hast du 24/7 eine Platte mitlaufen, die sonst nichts macht, oder? Schöner wäre es da, wenn man die nach dem rsync wieder stromlos schalten könnte ... oder wie hast du's realisiert?

 

[LnxBil]

Ich dachte du hast einen Pool/Storage mit dem OS und ein Pool/Storage für die VMs, dann sollten die eigentlich beide immer laufen und in deinem Beispiel wird einfach das Dateisystem ROOT bzw. / und /boot von dem 1. auf das 2. Storage rsync (oder send/received bei ZFS).

Danach kannst du das packen oder sonstwas und in dein "normales" Backup des Systems integrieren (das off-site gespeichert wird).

 

[whiterabbit]

Jein, das OS ist hier kein Pool sondern eine einzelne Platte (dass das auch besser/eleganter/sicherer geht ist klar).
Aber mit ZFS kann man sich in diesem Fall tatsächlich mal auseinandersetzen .... (wenn das nicht so speicherhungrig wäre!? Wir haben nur einen kleinen Server mit 32 GB RAM hier laufen...)

 

[LnxBil]

Muss ja kein ZFS sein, daher das Pool/Storage.
Aber in meinen Augen macht es überhaupt keinen Sinn eine einzige Platte (ohne RAID) für das OS zu verwenden und dann ein RAID für die VMs. Warum macht ihr das? Entweder über alles ein RAID legen (mehr Spindeln ist immer besser) oder die Platte rausnehmen und alles übers RAID machen.

 

[whiterabbit]

Das haben wir aus zwei Gründen damals umgestellt: Wenn das RAID defekt ist, kann man schnell ein laufendes System wiederherstellen (wir haben einen zweiten, identischen Controller hier). Zudem kam eins der älteren dist-Upgrades irgendwie nicht richtig klar (ich meine, dass es Schwierigkeiten von 3.x --> 4.x gab?) ... daher mussten wir irgendwie alle VMs auf einen anderen Server umziehen lassen. Da machte es durchaus Sinn, dass System und VMs auf getrennten Platten lagen...
Aber die Idee, auch das System per rsync synchron zu halten, finde ich ganz brauchbar. Mal sehen, ob ich noch irgendwo eine schaltbare Steckdose herumfliegen habe. Dann kann man die ja bei Bedarf zuschalten und die Platte anschließend wieder schlafen legen....

 

[Deleted member 34654]

ich hoffe du redest hier vom heim bedarf und nicht im Firmen Umfeld!!

 

[whiterabbit]

Es ist weder noch. Aber du kannst gerne erläutern, wie du es machen würdest...