[SOLVED] NFS Einbindung (Sicherung Image)

[trevon]

Hallo und frohes neues Jahr!

Ich bin neu hier und Arbeite mich langsam in das Thema Proxmox ein.
Jetzt hoffe ich das ich nicht eine Frage stelle die schon zu 1000den beantwortet wurde.

Verständnisfrage zu NFS:

Folgende Situation:

Ich habe ein Laufwerk in einem LXC Container per NFS gemoutet. (40GB)
Das Laufwerk bzw. das Image liegt auf einer Synology.

Docker schreibt nun die Daten in dieses Laufwerk -> funktioniert alles ohne Probleme.

Nun kann ich von dieses Image ganz einfach ein Backup erstellen.

Doch wie würde ich bei einem komplett Ausfall wieder an meine Daten im Image kommen?
Kann Proxmox dies ohne weiteres wieder Mouten?
Könnte ich das Image entpacken?
Gibt es die Möglichkeit ein Laufwerk zu erstellen das nicht als Image abgespeichert wird?

Ich danke euch und muss sagen -> Proxmox macht einfach nur Spass!

 

[Dunuin]

Hallo und frohes neues Jahr!

Ich bin neu hier und Arbeite mich langsam in das Thema Proxmox ein.
Jetzt hoffe ich das ich nicht eine Frage stelle die schon zu 1000den beantwortet wurde.

Verständnisfrage zu NFS:

Folgende Situation:

Ich habe ein Laufwerk in einem LXC Container per NFS gemoutet. (40GB)
Das Laufwerk bzw. das Image liegt auf einer Synology.

Das heißt du nutzt kein NFS Share im LXC, sondern hast dein NFS im PVE host als VM/LXC storage gemountet und auf diesem dann eine virtuelle Disk für den LXC angelegt?

Doch wie würde ich bei einem komplett Ausfall wieder an meine Daten im Image kommen?
Kann Proxmox dies ohne weiteres wieder Mouten?
Könnte ich das Image entpacken?
Gibt es die Möglichkeit ein Laufwerk zu erstellen das nicht als Image abgespeichert wird?

Am besten du testest einfach mal ein Restore eines Backups. Das sollte man ja eh immer tun, damit man im Ernstfall dann nicht ohne lauffähiges Backup dasteht, weil doch etwas nicht klappte, man es aber nie vorher getestet hat.
Wichtig dabei ist zu wissen das PVE beim Restore immer eine neue VM/LXC anlegt, basierend auf den Configs und virtuellen Disks aus dem Backup. Beim Restore kannst du dann den Storage angeben, wo die neue VM/LXC gespeichert werden soll, sowie eine VMID die genutzt werden soll. Wählst du die gleiche VMID wie vorher wird dein alter LXC gelöscht und durch einen neuen aus dem Backup ersetzt. Wählst du eine andere VMID erhältst du quasi eine Kopie und hast dann zwei LXCs.
Also um dann später wieder an die Daten zu kommen am besten den kompletten LXC restoren. Dann hast du ja deinen lauffähigen LXC und kannst den nutzen um an die Daten zu kommen. Ansonsten könnte man das vma-Backup-Archiv auch noch manuell entpacken (wie z.B. hier) aber das wird dann deutlich komplizierter.

 

[trevon]

Hallo,
Danke für deine Antwort.

Das heißt du nutzt kein NFS Share im LXC, sondern hast dein NFS im PVE host als VM/LXC storage gemountet und auf diesem dann eine virtuelle Disk für den LXC angelegt?

Genau, oder ist das weniger gut? Gibt's eine bessere Möglichkeit? Können die VM's/LXC auch ohne mouten auf die NFS zugreiffen?

Also um dann später wieder an die Daten zu kommen am besten den kompletten LXC restoren. Dann hast du ja deinen lauffähigen LXC und kannst den nutzen um an die Daten zu kommen.

Habe nun ein komplettes Backup auf das NFS Laufwerk gezogen (nachdem ich 3h brauchte um LXC "backupfähig" zu machen... (Lösung /tmp, schreibrechte)...

Gut, ich werde mal versuchen die Backups wieder einzuspielen. (Learning by doing) ist immernoch der beste weg

Einen schönen Sonntag.

 

[Dunuin]

Genau, oder ist das weniger gut? Gibt's eine bessere Möglichkeit? Können die VM's/LXC auch ohne mouten auf die NFS zugreiffen?

Ja, das geht auch anders:
1.) NFS Share direkt im privilegierten LXC mounten (aber privilegierte LXCs sind unschön weil wenig sicher)
2.) NFS Share auf dem Host mounten und dann per bind-mount in einen unprivilegierten LXC bringen (is taber nervig wegen dem User Remapping)

Habe nun ein komplettes Backup auf das NFS Laufwerk gezogen (nachdem ich 3h brauchte um LXC "backupfähig" zu machen... (Lösung /tmp, schreibrechte)...

Nicht vergessen nicht das selbe NAS für Backups zu benutzen, wo auch schon die virtuellen Disks deiner Gäste drauf liegen. Geht dann dein NAS kaputt sind mit dem NFS share dann nicht nur deine LXCs sondern auch die Backups weg...

 

[trevon]

2.) NFS Share auf dem Host mounten und dann per bind-mount in einen unprivilegierten LXC bringen (is taber nervig wegen dem User Remapping)

Wenn dann würde nur Option 2 in frage kommen...

Dann versuche ich mal einen unprivlegierte LXC einen Mountpoint zu erstellen. So sollte ich dann die einzelnen Dateien sehen und keine *.RAW mehr haben.
Mal schauen wie das mit der rechte Verwaltung NAS/Proxmox funktioniert.

Danke für die Richtungs-Lenkung und die schnelle Antwort

 

[Dunuin]

Dann versuche ich mal einen unprivlegierte LXC einen Mountpoint zu erstellen.

Wie gesagt, das geht nicht im LXC selbst sondern nur auf deinem PVE Host. Den NFS Share muss man sich dann z.B. per fstab auf dem PVE host mounten (was unschön ist, da man sich dann wieder Abhängigkeiten zum Host einfängt und ein LXC aus einem Restore auf einem neuen Server nicht mehr läuft, außer man richtet den neuen Host auch wieder passend mit den NFS Shares ein). Danach kann man dann den NFS Mountpoint vom Host per Bind-Mount in den LXC durchreichen.

Mal schauen wie das mit der rechte Verwaltung NAS/Proxmox funktioniert.

Ja, das mit den Rechten ist nicht einfach. Da muss man dann schon das Remapping manuell editieren wie hier unter "Using local directory bind mount points" beschrieben.

 

[trevon]

Ok, verstehe.

Die Diskussion hier hat mich noch auf einen anderen Weg gebracht.

Docker soll per NFS die Daten direkt auf die Synology schreiben, ohne Umweg via Proxmox.


Anyway, Danke!

 

[Dunuin]

Docker sollte man wegen Sicherheit und für weniger Probleme eigentlich eh in einer VM laufen lassen und nicht in einem LXC. In einer VM würden sich dann auch NFS Shares deutlich einfacher und direkt einbinden lassen.

Nicht vergessen, dass du da vermutlich Docker Container laufen lassen willst die wer anderes erstellt hat. Kann man immer haben, dass da der Ersteller eines Docker-Containers einfach nur unfähig ist und Sicherheitslücken offen lasst, der Ersteller was böses im Schilde führt und Spyware oder ähnliches in den Container einbaut oder auch einfach nur jemand dessen Account hackt und dann einen neuen Container bereitstellt, welcher gezielt Schadsoftware enthält um dann z.B. andere Rechner im Heimnetz mit Ransomware oder ähnliches anzugreifen. Alles schon passiert. Wenn man nicht genau weiß, was für Software man da ausführt, weil man die Software nicht selbst installiert und eingerichtet hat, dann sollte man schon so gut wie möglich auf Isolation achten. Also am besten eine VM nehmen und diese in eine DMZ stecken, damit der Schaden dann wenistens in der VM bleibt und nicht der ganze Server oder andere Rechner im Netz betroffen sein können.

Und bezüglich weniger Problemen...LXC ist schon ein Container und läuft daher nur mit sehr eingeschränkten Features und fehlenden Berechtigungen. Lässt du einen Docker Container in einem LXC laufen, dann hast du halt Container im Container und das kann manchmal Probleme machen. Docker in einer VM wäre fast wie Docker auf einem bare metal Server und damit deutlich berechnenbarer.

 

[trevon]

Danke für deine Ausführlichen Tipps.

Docker habe ich eigentlich nur weil ich gerne PaperlessNG nutzen würde und um Docker zu testen, weil es ja einfach sein "soll".

Ressourcen für eine VM habe ich genug, kann ich also locker machen.
Vielleicht habe ich mit den Container als "Ressourcenschonend" einen falschen Ansatz gewählt.

Evt. könnte ich PaperlessNG in einem Container ohne Docker laufen lassen, nur das Problem mit denn Dateien auf die NAS sichern bleibt bestehen

Also sehen meine weiteren schritte wohl so aus:
VM erstellen.
Docker installieren
PaperlessNG
und NFS Laufwerk erstellen für die Dateien die von Paperless kommen.

VM nur für Paperless, wäre wohl ein bisschen zu heftig

Einen schönen Sonntag.