eingebundenen LW in einer VM *nicht* im PBS sichern

hans0815

New Member
Feb 27, 2025
16
2
3
genau, habe eine VM in der ein NFS share als SCSI1 gemounted und ext4 formatiert ist.
Wenn ich diese VM in den PBS sichere (Job via GUI ) wird auch dieses drive mit gesichert.

Ich habe im Backup Job keine Option gefunden um das Sichern von NetzLW zu unterbinden.
 
Das kann im Hardware tab der VM für jede Festplatte eingestellt werden1748323383022.png
 
get z.B. mit einer nfs freigabe auf meinem NAS => in der /etc/fstab so
NFS 4 ist sehr, sehr schnell :)

192.xxx.xx.xx:/volume1/pbs01_data /media/pbs01_data nfs auto,rsize=131072,wsize=131072,noatime,nolock,nfsvers=4 0 0
 
get z.B. mit einer nfs freigabe auf meinem NAS => in der /etc/fstab so
NFS 4 ist sehr, sehr schnell :)

192.xxx.xx.xx:/volume1/pbs01_data /media/pbs01_data nfs auto,rsize=131072,wsize=131072,noatime,nolock,nfsvers=4 0 0
Klar kann man NFS-Freigaben als storage in einem PVE einbinden.
Innerhalb einer VM kann man NFS natürlich per fstab einbinden. Ich kann aber nicht glauben, dass der Inhalt dann in einer Sicherung landet. Habe es allerdings noch nie probiert. Dieser Logik folgend, müssten dann ja aber auch Netzlaufwerke einer Win-VM in einer Sicherung landen. Das tun sie aber definitiv nicht.
 
du wirfst hier ein paar Sachen durcheinander.
1. Meine Antwort bezog sich auf die Einbindung eines NFS share (via fstab) in einem PBS und dem ablegen eines Datenstores auf dem NFS share
2. Wenn Du eingebundenen Drives in VM sichern möchtest steuerst Du das Backup der LW hiermit: 1748948343535.png
Dabei ist es egal was für ein Gast OS auf dem Drive Verwendung findet.
3. Mittels ProxVE kannst Du NFS share als LW mittels "Storage" einbinden und dann VM's zuordnen
1748948457115.png

Ich habe mit 3. keine guten (Stabilität, Fehleranfälligkeit, Speed) gemacht (wegen dem Partions und Format overhead) daher mounte ich nur noch NFS direkt.
Eine zusätzliche Sicherung des NFS Share kann dann easy per Cron auf dem NFS Server (in meinem Fall NAS) erfolgen.
 
Mir purzelte es dann auch aus dem Kopf, das du wahrscheinlich NFS-Freigaben als storage einbindest und dieses als Ziel für erzeugte Disks einer VM einstellst. Dann muss man natürlich mittels Haken dieses weitere VM-LW aus der Sicherung ausschliessen.
Deine Erfahrung unter 3. kann ich nur bestätigen und habe diese GUI-Möglichkeit aus dem Kopf verdrängt. Deshalb mounte und unmounte ich bei Bedarf auch grundsätzlich parallel per CLI
 
get z.B. mit einer nfs freigabe auf meinem NAS => in der /etc/fstab so
NFS 4 ist sehr, sehr schnell :)

Das bezweifle ich:

Im LAN mag es noch schnell genug sein, über WAN eher nicht und auch im LAN (wenn man schon mit Netzwerkfreigaben arbeitet) dürfte iscsi performanter sein.
 
  • Like
Reactions: TErxleben
@Johannes S: Das nenne ich mal einen tollen Link, bei dem sich Leute Gedanken und Mühe gemacht haben, die Mythen und Behauptungen in Relation zu setzen, selbst wenn das Ergebnis alles andere als überraschend ist. Danke Dir für den Tipp und natürlich auch den Erstellern.

Selbst wenn diese Tests für storages innerhalb eines PBS gemacht wurden, sind sie ohne weiteres auch auf PVEs projizierbar.
Am besten hat mir die knackige conclusion gefallen.
 
Last edited:
Selbst wenn diese Tests für storages innerhalb eines PBS gemacht wurden, sind sie ohne weiteres auch auf PVEs projizierbar.
Am besten hat mir die knackige conclusion gegefallen.

Naja ich hätte envtl. noch dazu schreiben sollten, dass zwischen dem Benchmarker ubd PBS Entwicklern noch eine längere umd recht lebendige Diskussion dazu gab, welcher seine Annahmen zutreffen und welche nicht:


Und auch in der verlinkten Diskussion steht ja zu ZFS zu Recht, dass die "schlechtere Performance" bei ZFS durch die sonstigen Features mehr als ausgeglichen wird.

Aber: Wo sich alle Beteiligten einig waren, dass Datastores auf Netzwerkfreigaben schlecht für Performance sind, wobei iSCSI noch das kleinste Übel darstellt.
 
Last edited:
Das du "ZFS-Fan" bist, weiß ich ja ;-)
Die Latenzen degradieren natürlich jede Geschwindigkeit, je kleiner die Datenhappen werden. Also vom Hase zum Igel in der Reihenfolge: intern NVMe->intern SATA-SSD->intern HDD->LAN-Speicher-> WAN-Speicher.
Nichts Neues. Fette Dateien wie VZDumps, vor allem wenn sie gut komprimierbar sind, können sogar per WAN recht gut übertragen werden. Deshalb meine hier schon häufiger geäußerte Affinität zu rsync. Das erinnert mich daran zumindest eine manuelle "Testreihe", bzgl. rsync und Konsorten zu erstellen.

Nachtrag:
  • Auf beiden Seiten einer schwachbrüstigen Verbindung einen PBS zu betreiben ist die leitungstechnisch effektivste Komplettmethode, da bereits dedupliziert.
  • Erfordert jedoch entsprechende Infrastruktur.
  • Bei vzdump auf irgendwelche Lahmziele wäre es schön, eine "latest" Sicherung anlegen zu können.
  • Dabei werden dann eben nur Deltas (hallo rsync) statt einer kompletten VM übertragen.
  • Sozusagen letzte Bastion im Katastophenfall.
  • Wenn man akzeptiert, nur die vorletzte Version zu synchronisieren, funktioniert das durch schnödes Umbenennen sogar rattenschnell.
  • Jedenfalls parallel per Script. Da suche ich mir die letzte Version, benenne sie in VMx.-latest.typ um oder korrigiere entsprechende Links und gleiche sie mittels rsync mit (fast) beliebigen Zielen ab.
  • Keinerlei Hexenwerk aber durchaus integrationswürdig, sofern es zuverlässiger als die Einbindung von externen Medien funktioniert.
  • Ich habe jedenfalls einen Ordner namens latest parallel zum dump-Ordner in den entsprechenden PVE-Strukturen. Leider fehlerträchtig parallel zur PVE-Struktur.
 
Last edited: