HDD unabhängig für mehrere bestimmten VMs zur Verfügung zu stellen

[taubers]

Ich bin ein Newbie bei Proxmox und Linux. In Proxmox möchte ich jedoch Folgendes tun:

Im Proxmox-Dashboard habe ich einen Speicher (2 Sata-Festplatten, 12 TB) ins Mirror (ZFS) formatiert. Dies soll rein als unabhängiger Speicherort für sensible Daten bleiben, auf dem keine VMs ausgeführt werden. Es sollte unabhängig von den VMs existieren (es sollten keine VM-Systemdateien darauf installiert werden). Alle VMs werden auf separaten SSD-Festplatten installiert.

Jetzt möchte ich diesen Datenspeicher für mehrere bestimmten Linux VMs mit gute Lese- / Schreibgeschwindigkeit zur Verfügung zu stellen. Um die normale Geschwindigkeit beizubehalten, möchte ich keine in Kompromisse mit dem Risiko eines Datenverlusts eingehen, indem ich beispielsweise die Synchronisierung von ZFS deaktiviere.

Was wäre der beste Weg, um das zu erreichen?

Ich habe über das "USB-Passthrough" gelesen, aber ich denke, dass es nicht das richtige in diesem Fall wäre.

Ich freue mich auf eine Antwort

 

[0xd149e38e]

Einfach ein ZFS Dataset mit sharenfs/sharesmb freigeben.

Ich habe mir dazu eine eigene Bridge eingerichtet, mit eigener IP range.
Die VMs die NFS brauchen bekommen zusätzlich einen Port an dieser Bridge.
Idealerweise braucht man dann noch LDAP oder AD, auch ein DHCP Server an der Bridge kann sinnvoll sein.

Kompromisse mit dem Risiko eines Datenverlusts

Backup, USV, ECC

Edit:
Ich habe diesen Weg verwendet, weil ich Speicherplatz für Dateien haben möchte.

Es gibt aber auch noch eine andere Mõglichkeit:

Man kann Teile der HDD als virtuelle HDD an die VMs geben. Das geht auch über GUI.

• Datacenter -> Storage -> Add -> ZFS (Disk Image)
• VM -> Hardware -> ADD Hard Disk.

Da muß man dann die Größe angeben die man verwenden will.
Bei ZFS wird ein ZVOL erzeugt.
D.h. in der VM muß man die virtuelle HDD dann formatieren.

 

[taubers]

Einfach ein ZFS Dataset mit sharenfs/sharesmb freigeben.

Ich habe mir dazu eine eigene Bridge eingerichtet, mit eigener IP range.
Die VMs die NFS brauchen bekommen zusätzlich einen Port an dieser Bridge.
Idealerweise braucht man dann noch LDAP oder AD, auch ein DHCP Server an der Bridge kann sinnvoll sein.


Backup, USV, ECC

Edit:
Ich habe diesen Weg verwendet, weil ich Speicherplatz für Dateien haben möchte.

Es gibt aber auch noch eine andere Mõglichkeit:

Man kann Teile der HDD als virtuelle HDD an die VMs geben. Das geht auch über GUI.

• Datacenter -> Storage -> Add -> ZFS (Disk Image)
• VM -> Hardware -> ADD Hard Disk.

Da muß man dann die Größe angeben die man verwenden will.
Bei ZFS wird ein ZVOL erzeugt.
D.h. in der VM muß man die virtuelle HDD dann formatieren.

Vielen Dank! Ich muss es langsam jetzt verkraften, weil vieles genanntes für mich neu ist!
Die zweite Version habe ich schon auch versucht, aber da ich es mir 100% sicher machen will, dass die Daten bleiben und nicht irgendwelchen Formatierungen unterliegen, wollte ich diese HDD sauber getrennt halten.

Aber Danke Dir! Ein dickes Like von mir

 

[0xd149e38e]

Bei Zvols würde ich mir keine Sorgen machen. Wenn de zfs pool läuft, so sieht man direkt die ZVOLs as device:

$ lsblk
zd144                                                                               
├─zd144p1   ext4              7a27ecb4-d971-4f2d-a4a4-673e4353de11                  
├─zd144p2                                                                           
└─zd144p5   swap              505c631e-f834-48cf-a041-2a2f33485e79       

Die kann man direkt im Host mounten, genauso wie in der VM.

Wenn es keine VM sein muß, so kann man in lxc auch ein Verzeichnis der HDD direkt mounten.

 

[Dunuin]

So richtig verstehe ich dein Sicherheitskonzept aber auch nicht. Du kannst da machen was du willst, solange eine VM/LXC irgendwie Schreibzugriff auf eine HDD hat kann dir die VM auch die Daten auf den HDDs zerschießen (z.B. Ransomware Infektion in einer VM).
Da hilft höchstens ein ordentliches offline Backup und kein Mirror/Raid1. Oder wenn Raid1 dann wenigstens mit automatischen Snapshots die man super lange behält, damit man zur Not zurückrollen kann.
Und wie 0xd149e38e schon sagte, Raid ersetzt nie ein ordentliches Backup und wenn du Schutz vor schleichendem Dateiverfall (Bit Rot) willst sollte ECC RAM benutzt werden. Und der Kauf von einer USV würde vor Datenverlust durch Stromausfälle schützen, wo dann alle Daten weg wären die sich noch im Schreibcache befunden haben.

Da kann man z.B. noch eine dritte 12TB USB-HDD kaufen und die einmal im Monat an den Server hängen und dann eine Replikation starten, dass da alles von dem Mirror noch einmal extern offline gespeichert wird. Und die USB-HDD dann gut wegpacken. Sollte dann etwas mit den Daten im Server passieren, dann hättest du wenigstens noch ein Backup was du zur Not zurückspielen kannst.

Mal vom Sicherheitsaspekt abgesehen würde ich aber VMs auch nicht auf den HDDs laufenlassen wollen. Da wären die HDDs dann ziemlich schnell wegen den IOPS überfordert und eine SSD erledigt das einfach besser. Daten von VMs trennen macht daher schon Sinn.

 

[taubers]

Dunuin,
ich habe es 3 Mal durchgelesen und Google dabei zur Hilfe genommen! Hammer! Habe was wertvolles dazugelernt. Du hast den Sicherheitsaspekt wirklich im Griff genommen. Ja, so muss ich auch machen, dass ich auf eine offline Festplatte die Sachen abspeichern sollte. Meinst Du ich soll mit rsync arbeiten, damit die Daten auf dem Offlinespeicher jedes Mal gespeichert werden (und so die offline Festplatte durch die IOPS nicht langfristig überfordert wird) oder gibt es noch was zuverlässigeres?

Über ECC, Bit Rot, IOPS habe ich noch nie gehört, aber verstehe jetzt, was Du meinst.

Eine von meinen (wahrscheinlich zu naiven) Vermutungen zum Thema Sicherheit war, dass ich irgendwie duch das zentralisierte Speichersystem die Formattierungmöglichkeiten der HDD (die irgendwann aus irgendwelchen Grund blöderweise passieren könnten) durch die VMs komplett abschalten kann. Meinst Du, dass sobald jemand "write" permission auf VM hat, so hat er auch die "Format" permission automatisch und man kann es nicht noch detailierter in OS regeln?

Die Daten muss ich sowieso zentralisiert speichern, damit diese an verschiedenen VMs schon synchronisiert weitergegeben werden.

Ich werde alle 3 Varianten von 0xd149e38e ausprobieren und dann entscheiden, was am optimalsten für mein Speicher-Sharing wäre.

Nochmals - Dunuin und 0xd149e38e, vielen Dank für den erleuchtenden Input!

So richtig verstehe ich dein Sicherheitskonzept aber auch nicht. Du kannst da machen was du willst, solange eine VM/LXC irgendwie Schreibzugriff auf eine HDD hat kann dir die VM auch die Daten auf den HDDs zerschießen (z.B. Ransomware Infektion in einer VM).
Da hilft höchstens ein ordentliches offline Backup und kein Mirror/Raid1. Oder wenn Raid1 dann wenigstens mit automatischen Snapshots die man super lange behält, damit man zur Not zurückrollen kann.
Und wie 0xd149e38e schon sagte, Raid ersetzt nie ein ordentliches Backup und wenn du Schutz vor schleichendem Dateiverfall (Bit Rot) willst sollte ECC RAM benutzt werden. Und der Kauf von einer USV würde vor Datenverlust durch Stromausfälle schützen, wo dann alle Daten weg wären die sich noch im Schreibcache befunden haben.

Da kann man z.B. noch eine dritte 12TB USB-HDD kaufen und die einmal im Monat an den Server hängen und dann eine Replikation starten, dass da alles von dem Mirror noch einmal extern offline gespeichert wird. Und die USB-HDD dann gut wegpacken. Sollte dann etwas mit den Daten im Server passieren, dann hättest du wenigstens noch ein Backup was du zur Not zurückspielen kannst.

Mal vom Sicherheitsaspekt abgesehen würde ich aber VMs auch nicht auf den HDDs laufenlassen wollen. Da wären die HDDs dann ziemlich schnell wegen den IOPS überfordert und eine SSD erledigt das einfach besser. Daten von VMs trennen macht daher schon Sinn.

 

[pakuzaz]

@tom wir warten auf den tape Support damit wäre das Thema auch leichter zu lösen

 

[Dunuin]

Meinst Du ich soll mit rsync arbeiten, damit die Daten auf dem Offlinespeicher jedes Mal gespeichert werden (und so die offline Festplatte durch die IOPS nicht langfristig überfordert wird) oder gibt es noch was zuverlässigeres?

Wenn du auf beiden HDDs ZFS benutzt würde ich Replikation nehmen. Dann wird alles auf Blockebene 1-zu-1 von deinem ZFS Mirror im Server auf die externe USB-HDD gespiegelt. Proxmox hat da auch zsync und pvesr als Tools welche ZFS Replikation nutzen. Bin nur nicht sicher wie gut die für deinen Anwendungsfall passen, weil du ja nicht zwischen 2 Servern replizieren willst und keine VMs sondern einfach nur Datasets mit Daten repliziert werden sollen. Ich hab sowas immer direkt mit Befehlen wie "zfs send -i -r MeinPool/RootDataset@LetzterSnapshot| zfs receive BackupPool/RootDataset" gemacht.
Aber ja, rsync (ober besser noch rdiff zum Schutz vor versehentlichen Löschungen) würde sonst auch gehen.

Eine von meinen (wahrscheinlich zu naiven) Vermutungen zum Thema Sicherheit war, dass ich irgendwie duch das zentralisierte Speichersystem die Formattierungmöglichkeiten der HDD (die irgendwann aus irgendwelchen Grund blöderweise passieren könnten) durch die VMs komplett abschalten kann. Meinst Du, dass sobald jemand "write" permission auf VM hat, so hat er auch die "Format" permission automatisch und man kann es nicht noch detailierter in OS regeln?

Was du machen kannst ist einzugrenzen, welche VM auf welche Daten zugreifen darf. Das jede VM wirklich nur an die Daten kommt, welche sie wirklich braucht. So kannst du den Schaden dann etwas in Grenzen halten. Aber wirklich verhindern, dass da eine VM alle Daten löscht, auf welche sie Zugriff hat, kannst du eigentlich nicht. Wenn dir da wirklich wer schaden will, dann findet man da auch immer Wege. Und wenn man nur ein Script startet was alle Dateien öffnet und mit Nullen überschreibt oder wie im Falle einer Ransomware einfach alle Dateien verschlüsselt und das Passwort wegwirft, dass da niemand mehr ohne Lösegeld an die Daten kommt. Für sowas sind dann Snapshots sehr nett, wenn du das rechtzeitig bemerkst, dass du dann im Nachhinein die boshaften Löschungen/Änderungen zückgängig machen kannst.

 

[taubers]

Danke für die Hinweise, Dunuin!

"zfs send -i -r MeinPool/RootDataset@LetzterSnapshot| zfs receive BackupPool/RootDataset"

Meinst Du wirklich einen Snapshot der VM mit "LetzterSnapshot"? Oder meinst Du ich soll also kurz vor einem offlline Datenbackup einen Snapshot des ZFS Datenlaufwerks erstellen? (In GUI von Proxmox sehe ich nur Snapshots bei VMs als Feature)

Wo wird es normalerweise dann gespeichert?

Und - was wird am Ende dann an die externe HDD gesendet - die einzelnen Dateinen (nur die neusten) oder irgendeine Snapshot-Datei?

 

[Dunuin]

Danke für die Hinweise, Dunuin!


Meinst Du wirklich einen Snapshot der VM mit "LetzterSnapshot"? Oder meinst Du ich soll also kurz vor einem offlline Datenbackup einen Snapshot des ZFS Datenlaufwerks erstellen? (In GUI von Proxmox sehe ich nur Snapshots bei VMs als Feature)

Wo wird es normalerweise dann gespeichert?

Und - was wird am Ende dann an die externe HDD gesendet - die einzelnen Dateinen (nur die neusten) oder irgendeine Snapshot-Datei?

ZFS ist ja ein Copy-On-Write Dateisystem. Da hast du keine Dateien an festen Orten die sich wirklich überschreiben lassen, sondern alles an Daten ist wie in einem Logbuch, wo man nichts bereits geschriebenes verändern kann, sondern einfach am Ende des Buchen immer weiter auf leere Seiten schreibt. Wenn man diesen Logbuch-Vergleich nimmt, dann sagt man mit Snapshots dem Logbuch, dass da alles was nach der aktuellen Seite geschrieben wird nicht mehr gelöscht/geändert werden darf. Da das Logbuch alles schön chronologisch protokolliert kann man dann alles was getan wurde nochmal rückwärts abgehen und erhält dann so wieder den Stand zu dem Zeitpunkt, wo man den Snapshot erstellt hat.
D.H. dann aber auch, dass da deine Daten je mehr Platz wegnehmen, desto älter die Snapshots sind. Die Snapshots sollte man also irgendwann auch wieder löschen, damit ZFS das Aufräumen erlaubt wird und es Dinge die längst hätten gelöscht sein sollen auch zum endgültigen Löschen freigibt.
Eben weil das ganze Dateisystem wie ein riesiges Logbuch ist, hast du da in dem Sinne auch keine richtigen eigenständigen Snapshot-Dateien die man irgendwo anders speichern könnte. Snapshots sind also immer auf dem gleichen Pool von dem du auch das Snapshot erstellst.
Mit Replikation ist das quasi so, als wenn du 2 Logbücher führst die immer das selbe enthalten sollen. Auf deinem Haupt-Pool machst du ein Snapshot und mit "zfs send | zfs recieve" sendest du dann den Snapshot an den Backup-Pool. Damit werden dann quasi alle neuen "Seiten", die seit dem letzten gesendeten Snapshot geschrieben wurden, von dem Logbuches vom Haupt-Pool in den Backup-Pool abgeschrieben.

Deine Daten solltest du ja in Datasets speichern. Jedes Dateset ist ein eigenständigen Dateisystem. Dann machst du z.B. ein Dataset für jede VM wo die VM dann ihre Daten ablegen darf. VMs können sich über Netzwerkfreigaben dann auch ein Datasets teilen, aber halt daran denken, da nicht mehr als nötig freizugeben, damit echt nur jede VM da rankommt, was sie wirklich braucht.

Snapshots von Datasets kannst du z.B. mit dem Befehl "zfs snapshot MeinPool/EinDataset/EinVerschachteltesDataset@MeinSnapshotName" erstellen. Geht auch rekursiv wenn du "-r" benutzt. zfs snapshot -r MeinPool/EinDataset@MeinSnapshotName würde dann z.B. Snapshots von allen Datasets erstellen die unterhalb von "MeinPool/EinDataset" verschachtelt sind.

Wichtig dabei ist noch, dass da "zfs send" mit dem Parameter "-i" auch inkrementell senden kann. Dann muss nicht immer alles komplett neu gesendet werden, sondern nur die Änderungen seit dem letzten gesendeten Snapshot. Damit das klappt musst du aber sicherstellen, dass da keine Snapshots gelöscht werden, bevor diese auch an den Backup-Pool gesendet wurden. Sonst fehlen da "Seiten" im Logbuch und es muss das ganze Logbuch komplett neu abgeschrieben werden.

Hier wäre z.B. ein Script was "zfs send" und snapshots nutzt um Datasets auf eine externe HDD zu sichern.

 

[taubers]

uuups, jetzt hast Du wirklich mir die Augen aufgemacht, dass ich eingentlich mit falsche Vermutung gelebt habe, dass ZFS etwas sehr ähnliches wie die anderen Dateisystemen ist, aber das ist komplett anders aufgebaut. Heißt es also, dass ein Snapshot von ZFS ist mit dem standarten "Snapshot"-Konzept von VMs überhapt nicht zu vergleichen? Bei ZFS spricht man über Konzept wie "alles, was noch (nach dem eingelegten Lesezeihen im Buch bzw. Snapshot) geschrieben wird, soll ab jetzt für späteren Datentransfer auf z.B. andere Festplatte abgelagert werden", aber bei Snapshots von VMs geht es um "alles, was bisher geschrieben wurde, soll jetzt in eine Datei gespeichert werden"?

Heisst es, dass ich für jeden einzelnen Dataset einen einzelnen Snapshot erstellen muss, sodass ich am Ende dann auch eine Replikation pro einzelnen Dataset ausführen soll?

 

[Dunuin]

Bei ZFS spricht man über Konzept wie "alles, was noch (nach dem eingelegten Lesezeihen im Buch bzw. Snapshot) geschrieben wird, soll ab jetzt für späteren Datentransfer auf z.B. andere Festplatte abgelagert werden", aber bei Snapshots von VMs geht es um "alles, was bisher geschrieben wurde, soll jetzt in eine Datei gespeichert werden"?

Wenn deine VMs auch auf einem ZFS Pool liegen, dann wird Proxmox genau die gleichen Snapshots von ZFS auch für die VMs nutzen. Wichtig ist dabei halt nur zu verstehen, dass da Snapshots dem ZFS nur sagen, dass da nichts gelöscht/aufgeräumt werden darf, was man später brauchen würde, wenn man alles zu dem Zeitpunkt zurückrollen will, als der Snapshot erstellt wurde.
Dass das nicht wie ein Backup läuft, wo irgendwelche Dateien genommen und woanders hin kopiert werden. Daher kannst ein Snapshot auch deine 12TB innerhalb von nur einer Sekunde sichern, weil halt nichts kopiert werden müsste. Man verbietet halt nur das Aufräumen. Ansonsten würde ZFS im Hintergrund immer irgendwelche Aufräumarbeiten durchführen und nicht mehr benötigte beschriebende Seiten des Logbuchs rausreißen, waschen und dann leer am Ende des Logbuchs wieder einkleben, damit wieder mehr Platz zum Schreiben da ist.

Heisst es, dass ich für jeden einzelnen Dataset einen einzelnen Snapshot erstellen muss, sodass ich am Ende dann auch eine Replikation pro einzelnen Dataset ausführen soll?

Ja, jedes einzelne Dataset braucht ein eigenen Snapshot damit es repliziert werden kann. Aber dafür gibt es ja Rekursion und Verschachtelung.
Am besten legt man die Datasets gleich sinnvoll verschachtelt an. Zum einen damit man die rekursiv snapshotten/replizieren kann und zum anderen weil ZFS Eigenschaften vererbbar sind.

Sagen wir deine Datasets sehen z.B. so aus:

- MeinPool
---> HauptDataset1
-----> SubDataset1
-----> SubDataset2
-----> SubDataset3
---> HauptDataset2

Dann kannst du z.B. mit "zfs set atime=off MeinPool/HauptDataset1" z.B. sagen, dass da das Dataset "HauptDataset1" keine atime mehr speichern soll, was dann die Performance erhöht und IOPS verringert. Weil "SubDataset1", "SubDataset2" und "SubDataset3" aber Kinder von "HauptDataset1" sind, bekommen die automatisch "atime=off" vererbt und werden auch keine atime nutzen.
Und ist dann bei der Replikation und dem Snapshots ähnlich. Wenn du da den Befehlen mit dem "-r" Paramter sagst, dass da rekursiv gearbeitet werden soll und du nur das Dataset "HauptDataset1" angibst, dann werden automatisch auch Snapshots von allen Kindern erstellt bzw die ebenfalls repliziert.
Wenn du das richtig organisierst, dann kannst du da alle Datasets mit nur einem Befehl sichern.

 

[taubers]

Ich fange mal an ohne Daten zu experimentieren und Deine Hinweise werde ich als Handbuch benutzen Ich denke, ich muss das auf meinem Bildschirm sehen, damit ich es auch so wirklich kapiere, was Du meinst, da ich noch nie das alles gemacht habe!

Was sagst Du dazu:
Derzeit läuft der Proxmox root auf "nvme ssd 1tb" als etx4. Mein Plan ist noch eins "nvme ssd 1tb" zu besorgen und dann in Raidz mirror den Root wieder uminstallieren, aber dann auch nur auf eine kleine Partition, wobei auf dem größeren Teil würde ich die VMs laufen lassen.

Wäre es nicht irgendwie viel zu unoptimal die VMs und root auf einem Ort zu setzen, wobei alles sowieso noch auf 'nen externen offline Speicher abgelagert wird (eine Separate Backup-HDD nur für root und VMs)?

 

[Dunuin]

Ich fange mal an ohne Daten zu experimentieren und Deine Hinweise werde ich als Handbuch benutzen Ich denke, ich muss das auf meinem Bildschirm sehen, damit ich es auch so wirklich kapiere, was Du meinst, da ich noch nie das alles gemacht habe!

Was sagst Du dazu:
Derzeit läuft der Proxmox root auf "nvme ssd 1tb" als etx4. Mein Plan ist noch eins "nvme ssd 1tb" zu besorgen und dann in Raidz mirror den Root wieder uminstallieren, aber dann auch nur auf eine kleine Partition, wobei auf dem größeren Teil würde ich die VMs laufen lassen.

Wäre es nicht irgendwie viel zu unoptimal die VMs und root auf einem Ort zu setzen, wobei alles sowieso noch auf 'nen externen offline Speicher abgelagert wird (eine Separate Backup-HDD nur für root und VMs)?

Was genau meinst du mit "root"? Das Dateisystem von Proxmox?

VMs würde ich über die eingebaute Backup-Funktion von Proxmox sichern. Das kann dann als Ziel auch eine externe oder interne eigene HDD dafür sein. Oder ein Netzwerk-Share auf einem NAS. Ich persönlich bevorzuge es meine Backups nicht auf dem selben Rechner zu speichern und speichere die lieber extern auf einem NAS, das wenn da mal was mit dem Server ganz arg schief läuft, ich die Backups getrennt habe.

Die SSD für Proxmox und VMs kannst du mit ZFS spiegeln (ist dann ein "Mirror" (raid1) und kein "raidz" (raid5/raid6)) aber da musst du beachten, dass da ZFS ziemlich schnell die SSDs totschreiben kann, wenn du Consumer SSDs nimmst.

VMs und Proxmox hat man im Idealfall auf verschiedenen Laufwerken, damit eine VM auf 100% Auslastung nicht den ganzen Server bremsen kann. Kann man aber durchaus auch beides auf ein Laufwerk packen...gerade beim Homeserver wo das Budget knapp und die Verfügbarkeit nicht ganz so wichtig sind.

 

[0xd149e38e]

ls etx4. Mein Plan ist noch eins "nvme ssd 1tb" zu besorgen und dann in Raidz mirror den

Sei bitte vorsichtig mit den den Bezeichnungen: raidz ist zfs spezifisch, und hat nichts mit mirror zu tun, ebenso gibt es mirror=Raid1 bei vielen Dateisystemen.

Und so viel partitionieren muß du nicht, das macht alles die Proxmox Installation. Wichtig ist nur wieviel Platz Du für der OS verwenden willst.
Auch Mirror/Raid1 und so richtet dir das Installationsmedum ein.

Wäre es nicht irgendwie viel zu unoptimal die VMs und root auf einem Ort zu setzen, wobei alles sowieso noch auf 'nen externen offline Speicher abgelagert wird (eine Separate Backup-HDD nur für root und VMs)?

Verstehe ich nicht. Ja Backup ist suboptimal?! Normalerweise mache ich kein Backup vom OS, sondern installiere es einfach neu.
ABER die Konfiguration ist wichtig, also mache ich Backup von /etc. Für die VMs kann man einfach über die Proxmox GUI ein Backup einrichten.

Spiele einfach mal ein paar Tage mit Proxmox herum, installiere es, richte Test VMs und Backups ein, mache Teile absichtlich kaputt, spiele ein Backup zurück und wenn Du verstanden hast wie es läuft, machst Du Deine richtige Intallation.

 

[taubers]

Ja, mit root meine ich Proxmox.
Ok - eingebaute Backup-Funktion benutzen. Dafür wird ein kleines NAS dann auch benutzt

Danke Dir nochmals für Deine sehr informative Posts! Jetzt muss ich auch die endlich umsetzen!

 

[taubers]

Spiele einfach mal ein paar Tage mit Proxmox herum, installiere es, richte Test VMs und Backups ein, mache Teile absichtlich kaputt, spiele ein Backup zurück und wenn Du verstanden hast wie es läuft, machst Du Deine richtige Intallation.

Haha - genau! Mach ich gerne was kaputt, damit ich besser lerne Eine neue Welt für mich...aber muss sein, da ich von Big Tech nach 10 Jahre bequemen Nutzung weg will.