FHEM auf welcher Hardware

[Damian]

Bis auf das Anlegen der separaten Partition, die vollständig ein Thin-LVM darstellt, konnte ich über die Definition der VMs und in den jeweiligen VMs selbst innerhalb der Thin-LVM-Platte bleiben. Irgendwelche systemnahen manuellen mount-Vorgänge über die Shell waren dazu nicht erforderlich. Das war mir auch wichtig, sonst wird das gesamte System nicht wartbar. Im schlimmsten Fall möchte ich ein Backup einer VM zurückspielen, ohne irgendwelche Kunststücke händisch vorzunehmen.

So sieht bei mir die Aufteilung der NVMe-Platte aus:

Code Auswählen Erweitern

root@pve:~# lsblk
NAME                               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1                            259:0    0  1.8T  0 disk
├─nvme0n1p1                        259:1    0 1007K  0 part
├─nvme0n1p2                        259:2    0    1G  0 part /boot/efi
├─nvme0n1p3                        259:3    0   99G  0 part
│ ├─pve-swap                       252:0    0    8G  0 lvm  [SWAP]
│ └─pve-root                       252:1    0   91G  0 lvm  /
└─nvme0n1p4                        259:4    0  1.7T  0 part
  ├─local--vm-local--vm_tmeta      252:2    0 15.9G  0 lvm 
  │ └─local--vm-local--vm-tpool    252:4    0  1.7T  0 lvm 
  │   ├─local--vm-local--vm        252:5    0  1.7T  1 lvm 
  │   ├─local--vm-vm--100--disk--0 252:6    0    4M  0 lvm 
  │   ├─local--vm-vm--100--disk--1 252:7    0  200G  0 lvm 
  │   ├─local--vm-vm--100--disk--2 252:8    0    4M  0 lvm 
  │   ├─local--vm-vm--102--disk--0 252:9    0   10G  0 lvm 
  │   ├─local--vm-vm--102--disk--1 252:10   0 1000G  0 lvm 
  │   ├─local--vm-vm--105--disk--0 252:11   0   32G  0 lvm 
  │   ├─local--vm-vm--106--disk--0 252:12   0    4M  0 lvm 
  │   ├─local--vm-vm--106--disk--1 252:13   0   32G  0 lvm 
  │   ├─local--vm-vm--110--disk--0 252:14   0   32G  0 lvm 
  │   ├─local--vm-vm--110--disk--1 252:15   0    2T  0 lvm 
  │   ├─local--vm-vm--114--disk--0 252:16   0   32G  0 lvm 
  │   ├─local--vm-vm--113--disk--0 252:17   0   32G  0 lvm 
  │   ├─local--vm-vm--120--disk--0 252:18   0   32G  0 lvm 
  │   ├─local--vm-vm--101--disk--0 252:19   0   32G  0 lvm 
  │   └─local--vm-vm--107--disk--1 252:20   0   30G  0 lvm 
  └─local--vm-local--vm_tdata      252:3    0  1.7T  0 lvm 
    └─local--vm-local--vm-tpool    252:4    0  1.7T  0 lvm 
      ├─local--vm-local--vm        252:5    0  1.7T  1 lvm 
      ├─local--vm-vm--100--disk--0 252:6    0    4M  0 lvm 
      ├─local--vm-vm--100--disk--1 252:7    0  200G  0 lvm 
      ├─local--vm-vm--100--disk--2 252:8    0    4M  0 lvm 
      ├─local--vm-vm--102--disk--0 252:9    0   10G  0 lvm 
      ├─local--vm-vm--102--disk--1 252:10   0 1000G  0 lvm 
      ├─local--vm-vm--105--disk--0 252:11   0   32G  0 lvm 
      ├─local--vm-vm--106--disk--0 252:12   0    4M  0 lvm 
      ├─local--vm-vm--106--disk--1 252:13   0   32G  0 lvm 
      ├─local--vm-vm--110--disk--0 252:14   0   32G  0 lvm 
      ├─local--vm-vm--110--disk--1 252:15   0    2T  0 lvm 
      ├─local--vm-vm--114--disk--0 252:16   0   32G  0 lvm 
      ├─local--vm-vm--113--disk--0 252:17   0   32G  0 lvm 
      ├─local--vm-vm--120--disk--0 252:18   0   32G  0 lvm 
      ├─local--vm-vm--101--disk--0 252:19   0   32G  0 lvm 
      └─local--vm-vm--107--disk--1 252:20   0   30G  0 lvm 

[Damian]

Hier noch mal eine Übersicht von Thin LVM, da offenbar viele alte Unix-Hasen da noch Berührungsängste haben (ich hatte auch mal vor über 30 Jahren beruflich Software unter Unix entwickelt und da gab es viele moderne Dinge noch nicht )

Thin LVM (Thin Provisioning mit LVM) bietet einige Vorteile gegenüber klassischem LVM. Hier die wichtigsten Punkte:

✅ Vorteile von Thin LVM

• Effiziente Speichernutzung (Over-Provisioning)
• Virtuelle Volumes (LVs) können größer angelegt werden, als physisch Speicher vorhanden ist.
• Speicher wird erst dann wirklich verbraucht, wenn Daten geschrieben werden.
• Snapshots (schnell & platzsparend)
• Snapshots in Thin LVM sind wesentlich effizienter als klassische LVM-Snapshots, da sie Copy-on-Write auf Blockebene nutzen.
• Sie sind schneller anzulegen, brauchen anfänglich kaum Speicherplatz und wachsen nur mit Änderungen.
• Flexible Volumengrößen
• Volumes können bei Bedarf einfach nachträglich vergrößert werden.
• Nutzer/VMs können ,,virtuell" große Disks haben, ohne sofort physischen Speicher zu belegen.
• Geringere Fragmentierung / bessere Performance
• Im Vergleich zu alten LVM-Snapshots bleibt die Performance länger stabil, auch bei vielen Snapshots.
• Kombination mit anderen LVM-Features
• Thin Pools können mit RAID, Verschlüsselung oder LVM-Caching kombiniert werden.
• Einfachere Verwaltung in Virtualisierungs- und Container-Umgebungen
• Besonders nützlich in Cloud-, VM- und Docker-Umgebungen, wo Speicherplatz flexibel und effizient verwaltet werden m

uss.

⚠️ Nachteile / Einschränkungen (der Vollständigkeit halber):

• Komplexer als klassisches LVM, benötigt mehr Monitoring.
• Risiko: Bei Over-Provisioning kann der Speicher ,,überbucht" werden – wenn der Pool voll ist, schlagen Schreibvorgänge fehl.
• Verwaltung benötigt aktuelle Tools und Kernel-Support.

👉 Kurz gesagt: Thin LVM lohnt sich, wenn du flexible, platzsparende Volumes und viele Snapshots brauchst, besonders in Virtualisierung/Cloud-Setups.

[passibe]

Allerdings nutzen viele Homelab-User günstige Rechner, die meistens nur eine Nvme unterstützen. Dann muss man seine VMs auf eine langsame SATA-Platte auslagern oder man installiert die VMs auf der Proxmox-Platte, die bei einem Crash erst mal weg sind

Dazu: Spräche eigentlich – bis auf die SATA-bedingten Geschwindigkeitseinbußen – irgendetwas dagegen bei so einer Hardware die NVMe-Platte und die SATA-Platte gleich groß zu wählen und in ein RAIDz1 zu packen?

Benutze aktuell kein Proxmox aber spiele mit dem Gedanken ein System, das aktuell noch auf einem Pi läuft, auf so eine N100 oder N150 Box mit Proxmox und RAIDz1 umzuziehen.

(Natürlich ist das RAIDz1 kein Backup, aber so würde mich wenigstens davor schützen, dass wegen einem Festplattenausfall gar nichts mehr geht.)

[Bartimaus]

Ich würde mir eher Gedanken um ein gescheites Backup machen.
Eine SD-Karte im Raspi ist deutlich schneller abgeraucht als ne gute NVWM-SSD im Proxmox

[Damian]

Ich würde mir eher Gedanken um ein gescheites Backup machen.
Eine SD-Karte im Raspi ist deutlich schneller abgeraucht als ne gute NVWM-SSD im Proxmox

Würde ich auch so sehen. Wir reden hier von einem Homelab und nicht einem Hochverfügbarkeit-Server. Die Wahrscheinlichkeit sich sein System durch ein Update, eine Fehlkonfiguration oder allgemein durch einen Bedienfehler zu zerschießen, dürfte wesentlich höher liegen, als dass dir eine Marken-NVMe abraucht.

Es könnte durchaus Sinn machen, Proxmox auf einer kleinen SATA zu installieren und eine große NVMe nur für VMs und eine größere USB-HDD oder USB-SSD für Backups zu nehmen

Dann hast du folgende Vorteile:

Wenn sich das Proxmox durch ein Update oder sonst etwas verabschiedet, dann installierst du es einfach neu und spielst deine gesicherten /etc/pve-Konfigurationsdateien ein und schon läuft die Sache.

Wenn die VMs auf einer schnellen NVMe statt auf einer SATA liegen, dann laufen inkrementelle Backups wesentlich schneller durch, weil Proxmox ein mal durch die VM-Disks muss. Die Menge der täglich zu sichernden Differenzdaten ist dagegen gering, so dass eine relativ langsame USB-Platte nicht so schlimm ist.

Da ich bereits eine große 4TB SATA-SSD und eine 2TB NVMe hatte, war diese Konstellation bei mir nicht sinnvoll, daher der Kunstgriff mit den getrennten Partitionen auf der NVMe.

Bei mir läuft z. B. ein nächtliches Backup einer Nextcloud mit 2 TB-VM-Disk auf der NVMe, bei der ca. 600 GB Nutzdaten vorhanden sind, in ca. 16 Minuten durch - mach das mal mit einer SATA Platte (ich habe da bereits meine Erfahrungen gemacht).

Code Auswählen Erweitern

2025-08-18 02:00:34 INFO: Starting backup: ct/110/2025-08-18T00:00:31Z   
2025-08-18 02:00:34 INFO: Client name: pve   
2025-08-18 02:00:34 INFO: Starting backup protocol: Mon Aug 18 02:00:34 2025   
2025-08-18 02:00:34 INFO: Downloading previous manifest (Sun Aug 17 02:00:30 2025)   
2025-08-18 02:00:34 INFO: Upload config file '/var/tmp/vzdumptmp2010125_110/etc/vzdump/pct.conf' to 'root@pam@192.168.178.84:8007:EVO_4TB' as pct.conf.blob   
2025-08-18 02:00:34 INFO: Upload directory '/mnt/vzsnap0' to 'root@pam@192.168.178.84:8007:EVO_4TB' as root.pxar.didx   
2025-08-18 02:01:34 INFO: processed 44.862 GiB in 1m, uploaded 6.282 MiB
2025-08-18 02:02:34 INFO: processed 85.301 GiB in 2m, uploaded 6.282 MiB
2025-08-18 02:03:34 INFO: processed 132.865 GiB in 3m, uploaded 6.282 MiB
2025-08-18 02:04:34 INFO: processed 177.44 GiB in 4m, uploaded 6.282 MiB
2025-08-18 02:05:34 INFO: processed 221.746 GiB in 5m, uploaded 6.282 MiB
2025-08-18 02:06:34 INFO: processed 258.676 GiB in 6m, uploaded 6.282 MiB
2025-08-18 02:07:34 INFO: processed 305.959 GiB in 7m, uploaded 6.282 MiB
2025-08-18 02:08:34 INFO: processed 351.354 GiB in 8m, uploaded 6.282 MiB
2025-08-18 02:09:34 INFO: processed 395.946 GiB in 9m, uploaded 6.282 MiB
2025-08-18 02:10:34 INFO: processed 436.241 GiB in 10m, uploaded 53.586 MiB
2025-08-18 02:11:34 INFO: processed 481.747 GiB in 11m, uploaded 72.223 MiB
2025-08-18 02:12:34 INFO: processed 520.627 GiB in 12m, uploaded 99.835 MiB
2025-08-18 02:13:34 INFO: processed 548.742 GiB in 13m, uploaded 184.621 MiB
2025-08-18 02:14:34 INFO: processed 577.249 GiB in 14m, uploaded 251.4 MiB
2025-08-18 02:15:34 INFO: processed 597.698 GiB in 15m, uploaded 1.498 GiB
2025-08-18 02:15:35 INFO: root.pxar: had to backup 1.503 GiB of 597.923 GiB (compressed 522.523 MiB) in 900.99 s (average 1.709 MiB/s)
2025-08-18 02:15:35 INFO: root.pxar: backup was done incrementally, reused 596.42 GiB (99.7%)
2025-08-18 02:15:35 INFO: Uploaded backup catalog (17.919 MiB)
2025-08-18 02:16:22 INFO: Duration: 947.98s   
2025-08-18 02:16:22 INFO: End Time: Mon Aug 18 02:16:22 2025   
2025-08-18 02:16:22 INFO: adding notes to backup
2025-08-18 02:16:22 INFO: prune older backups with retention: keep-last=30, keep-monthly=13, keep-yearly=10
2025-08-18 02:16:22 INFO: running 'proxmox-backup-client prune' for 'ct/110'
2025-08-18 02:16:23 INFO: pruned 232 backup(s) not covered by keep-retention policy
2025-08-18 02:16:29 INFO: restarting vm
2025-08-18 02:16:30 INFO: guest is online again after 959 seconds
2025-08-18 02:16:30 INFO: Finished Backup of VM 110 (00:15:59)


[passibe]

Aktuell existiert natürlich ein gescheites Backup bzw. das gäbe es dann auch für Proxmox (würde per NFS aufs NAS gebackupt werden und dann weiter off-site).
Das Problem ist eher, dass das System a) remote ist und b) dort semi-wichtige Dinge laufen. Deshalb wäre es nervig, wenn die Festplatte abraucht und man nicht einigermaßen schnell da ist, um ein Backup einzuspielen.

Wie wahrscheinlich das ist, dass irgendeine Platte abraucht, steht natürlich auf einem völlig anderen Blatt. Und natürlich ist der PC selbst oder dessen Netzteil oder whatever auch ein SPOF.

Mein Gedanke war eher: Wenn das Ding schon Platz für zwei Festplatten bietet und SATA-SSDs billig sind, wieso dann nicht eine gleich große SATA-SSD rein schmeißen und zusammen mit der NVMe als RAIDz1 nutzen.

Das mit der Geschwindigkeit der inkrementellen Backups ist natürlich ein valider Punkt, danke! Solche Hinweise hatte ich mir von der Frage erhofft. Bin mir nur noch nicht ganz sicher, wie relevant das für meinen Anwendungsfall wird, denn da wird es nicht wirklich um große Datenmengen gehen (schätze unter 100GB, wenn überhaupt). Vielleicht probiere ich es auch einfach mal aus und berichte dann bei Interesse. Wird aber sicherlich noch ein paar Monate dauern.

[Damian]

Wird aber sicherlich noch ein paar Monate dauern.

In einigen Monaten holst du dir 'nen Rechner mit 2 NVMes