Welche NVMe trägt die Gastplatte, und welche das Backup?

Standard sind 2 × 1TB NVMe, jede direkt angebunden, ohne Hardware-RAID. Nutzbar ist die Summe, etwa 2TB, nicht das 1TB nach einem Spiegel. Proxmox legt System und Gastplatten auf eine der Platten. Ein Backup im Standardverzeichnis teilt sich dieselbe NVMe. Erst die andere Platte hält eine einzelne Plattenstörung vom Backup fern.

Zuerst die Systemplatte benennen

Bei der Bestellung Proxmox VE 8 oder Proxmox VE 9 wählen. Beide liegen im Image. Nach der Übergabe per SSH einsteigen. Die zweite Platte erscheint nicht durch eine USB-Neuinstallation, und das Image faltet die beiden Platten nicht zu einem Hardware-Array. Im Gehäuse sitzt keine Array-Karte.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL ausführen, dann findmnt / und pvesm status. Zwei NVMe von etwa 1TB erscheinen als Typ disk. Die mit dem Root-Dateisystem ist die Systemplatte. Die andere hat eine leere Mount-Spalte und ist die ungenutzte zweite Platte. Den stabilen Namen unter /dev/disk/by-id/ und die Seriennummer notieren. Nach einem Neustart können nvme0n1 und nvme1n1 tauschen. Partition und Format über den by-id-Namen, nicht über die Nummer dieser Sitzung.

2 × 1TBStandard-NVMe, direkt
Etwa 2TBAls zwei Speicher
Die anderePlatte für Backups
Vor jedem Format den Mount noch einmal abgleichen. Die Platte mit Root und local-lvm ist kein Ziel für mkfs. Die leere Platte hat ein leeres MOUNTPOINT, etwa 1TB, und ist nicht die Quelle in findmnt /.

Gastplatten liegen standardmäßig auf der System-NVMe

Installiert das Image Proxmox auf eine NVMe, trägt diese Platte meist zwei Speicher. local ist ein Verzeichnis auf dem Root-Dateisystem unter /var/lib/vz. Dort liegen ISOs, Snippets und vzdump-Backups. local-lvm ist LVM-Thin auf derselben Platte. Gast- und Containerplatten werden dorthin geschrieben. Die Namen unterscheiden sich. Das Gerät ist dieselbe NVMe.

Ein neuer Gast mit Plattenspeicher local-lvm speichert die Platte also auf der Systemplatte. Ein Backup-Job, der weiter auf local zeigt, schreibt nach /var/lib/vz/dump, wieder die Systemplatte. Fällt diese Platte aus, fallen Gastplatte und dieses Backup zusammen aus. Zwei Speichernamen in der Oberfläche bedeuten nicht, dass die zweite NVMe in Gebrauch ist.

Mit lsblk sehen, welche NVMe die Volume-Gruppe hinter local-lvm trägt. Es soll dieselbe Platte wie Root sein. Die zweite Platte, etwa 1TB, hat noch keine Partition und ist kein Mitglied dieser Gruppe. Das ist die direkt angebundene Übergabe, kein fehlendes Array.

Backups auf die andere NVMe zeigen

Die zweite Platte allein partitionieren, ein Dateisystem anlegen und unter einem neuen Verzeichnis wie /mnt/backup-nvme einhängen. GPT und eine Partition genügen. ext4 genügt für Backup-Dateien. /etc/fstab speichert die UUID, nicht einen Namen wie /dev/nvme0n1p1, der sich ändern kann. Nach mount -a muss findmnt /mnt/backup-nvme die by-id der zweiten Platte als Quelle zeigen, nicht die Systemplatte.

In Proxmox einen Verzeichnis-Speicher hinzufügen. Im Datacenter Storage, Hinzufügen, Verzeichnis. Der Pfad ist dieser Mount. Inhalt nur VZDump-Backup. Der passende Befehl ist pvesm add dir backup-nvme --path /mnt/backup-nvme --content backup. Eine Storage-ID wählen, die nicht mit local kollidiert. In pvesm status soll die Zeile active sein, der freie Platz nahe an der zweiten Platte, nicht am Rest auf Root.

Bestehende Backup-Jobs müssen auf diesen Speicher. Das Verzeichnis hinzuzufügen, während der Job weiter local sagt, lässt neue Backups auf der Systemplatte. Ohne Gast zuerst Mount und Speicherstatus prüfen, dann den Gast anlegen. Mit Gast ein Backup laufen lassen und die neue Storage-ID als --storage an vzdump geben. Der Snapshot-Modus braucht einen Plattenspeicher mit Snapshots. local-lvm kann das. Die Datei erscheint im Verzeichnis der zweiten Platte, der Name beginnt mit vzdump-.

local darf weiter ISOs halten. Sobald Backup-Jobs es nicht mehr wählen, liegen Gastplatten und Backups auf zwei NVMe. Eine Neuinstallation ist für diese Trennung nicht nötig.

Eine zusätzliche 2TB-Platte bleibt eine eigene Platte

Eine zusätzliche 2TB-NVMe kostet $84 im Monat, höchstens zwei Stück, direkt angebunden und außerhalb jedes Hardware-Arrays. In lsblk ist sie eine neue Disk-Zeile von etwa 2TB. Sie tritt den beiden 1TB-Platten nicht bei und vergrößert local-lvm nicht von selbst. Sie wird behandelt wie die leere 1TB-Platte: eigene Partition, eigener Mount, eigener Speichereintrag.

Hält die zweite 1TB-Platte schon Backups, ist die 2TB-Platte der Ort für weitere Gastplatten. Auf dem neuen Mount einen Verzeichnis-Speicher anlegen, Inhalt Disk-Image, und diesen Speicher beim Anlegen einer großen Gastplatte wählen, statt in den Thin-Pool der Systemplatte zu schreiben. Passen die Backups nicht, den Backup-Job auf die 2TB-Platte zeigen und die zweite 1TB für Disk-Images behalten. In beiden Fällen bleiben Platten und das einzige Backup auf verschiedenen Platten.

Die 2TB-Platte nicht per vgextend in die Volume-Gruppe der Systemplatte ziehen. Spannt die Gruppe zwei NVMe unterschiedlicher Größe, können Extents der Gastplatte auf beiden liegen, und ein Backup auf Root teilt diesen Ausfall. Das ist kein Hardware-Array. Warum eine Zusatzplatte außerhalb eines Arrays bleibt, steht in eine Zusatzplatte bleibt außerhalb des Arrays. Ein Spiegel der beiden Standard-1TB senkt den nutzbaren Platz auf etwa 1TB, und die Trennung dieser Notiz gibt es dann nicht mehr. Diese Anordnung steht in Redundanz ohne Hardware-Array.

PlatteWie sie erscheintWas dorthin gehört
Erste 1TBRoot und local-lvmSystem und die Gastplatten, die schon dort liegen
Zweite 1TBLeer, bis sie eingehängt wirdvzdump-Backups
Zusätzliche 2TBEine weitere eigene DiskMehr Disk-Images oder ein größerer Backup-Speicher

Kapazität ist die Summe, nicht der Rest nach einem Spiegel

Als zwei Dateisysteme liefern die beiden 1TB-Platten etwa 2TB, abzüglich Partitionstabelle, Dateisystem und der Systemdateien auf Root. Sie als RAID 1 mit 1TB Rest zu lesen passt nicht zu den zwei Disk-Zeilen in lsblk und lässt keine zweite Platte für das Backup-Verzeichnis.

Eine Gastplatte und ihr Backup verbrauchen je Platz. Eine mit 400GB zugewiesene Gastplatte braucht im Thin-Pool Raum für das tatsächlich Geschriebene, und die zweite Platte braucht Raum für ein Backup. Die 400GB werden nicht einmal von einer Summe von 2TB abgezogen. Thin Provisioning lässt das Volume kleiner aussehen als die Zuweisung. Die Backup-Datei hängt weiter von Modus und Kompression dieses Laufs ab. Den Datenumfang je Platte planen, nicht aus einer einzigen Summe in der Speicherliste.

ext4 reserviert standardmäßig einen Teil der Blöcke für root. Ein Backup-Verzeichnis nur für vzdump zeigt weniger als die beschriftete Größe. Diese Reserve ist das Dateisystem, keine fehlende Platte. Nach dem Mount ist die Zeile in df -h die Zahl für die Aufbewahrung.

Ein Backup auf der zweiten Platte übersteht den Verlust der ersten. Ist die ganze Maschine nicht erreichbar, liegt dieses Backup weiter in derselben Maschine. Daten, die bleiben müssen, brauchen auch eine Kopie außerhalb. Ein Spiegel ist ebenfalls kein Backup.

Nach einem Backup prüfen, welche Platte die Datei hält

  1. Die zweite Platte ist eingehängt

    findmnt /mnt/backup-nvme nennt die zweite NVMe per by-id als Quelle. Nach einem Neustart ist der Mount noch da, und Root ist noch da.

  2. Der Speicher ist nicht local

    In pvesm status ist der Pfad des Backup-Speichers der neue Mount. Das Speicherfeld des Jobs ist diese ID. Steht dort noch local, vor dem nächsten Lauf ändern.

  3. vzdump einmal laufen lassen

    Einen Gast wählen, der einen Snapshot verträgt, und den Speicher auf das neue Verzeichnis setzen. Danach liegt eine vzdump--Datei dort. findmnt -T auf die Datei muss die zweite Platte nennen.

  4. Die Systemplatte füllt sich nicht mit

    Während des Backups df -h / beobachten. Wachstum unter /var/lib/vz/dump heißt, der Job zielt noch auf local. Stoppen, Speicher ändern, erneut laufen lassen.

Die Aufbewahrung muss in den freien Platz der zweiten Platte passen. Viele Kopien, jede nahe an der ganzen Gastplatte, lassen das nächste Backup auf halbem Weg scheitern und eine unvollständige Datei zurück. Diese Datei ist keine wiederherstellbare Kopie. Entfernen, die Zahl auf das senken, was die Platte hält, und ein Backup zu Ende laufen lassen.

Eine große Platte, die schon auf local-lvm liegt, wird bei ausgeschaltetem Gast verschoben, dann auf den neuen Verzeichnis-Speicher, dann ein Start zur Kontrolle. Die Plattendatei nicht kopieren, während der Gast noch schreibt. Backup-Dateien entstehen neu auf dem neuen Speicher. Alte Dateien im Dump-Verzeichnis der Systemplatte schützen die neue Platte nicht.

So werden die Platten dieser Maschine geliefert

Beide Speicherstufen kommen mit denselben Platten: 2 × 1TB NVMe, kein Hardware-RAID, jede Platte direkt angebunden, nutzbare Kapazität als 2TB gezählt. Die 128-GB-Maschine kostet $455 im Monat. Die 256-GB-Maschine kostet $612 im Monat. Der Speicher ist DDR4-3200 ECC RDIMM und wird nicht nachgerüstet. 256 GB ist diese Stufe. Die CPU beider ist AMD EPYC 7543P, 32 Kerne und 64 Threads. Eine zusätzliche 2TB-Platte macht die Monatsmiete der 128-GB-Stufe zu $539. Die Zusatzzahl ist 0, 1 oder 2, je $84. Der Betrag geht in die Monatsmiete, danach gilt die Monatszahl. Ein Quartal ist das Dreifache, ohne weiteren Rabatt. Keine Einrichtungsgebühr.

Die Maschine steht in Tokio, Japan. SSH zum Host nutzt die Adresse in der Konsole. Die Plattenanordnung ändert diese Login-Adresse nicht. Proxmox VE 8 und 9 stehen in der Liste der freien Images. Die zweite Platte und jede Zusatzplatte werden im System eingehängt. Das Image zeigt sie nicht als ein Hardware-Volume.

Die Trennung ist fertig, wenn das Blockgerät der Gastplatte und das Blockgerät der Backup-Datei nicht dasselbe Gerät sind. Speichername, Storage-ID des Backup-Jobs und die Quelle aus findmnt -T müssen übereinstimmen. Dann hat das Backup die System-NVMe verlassen.

Backups auf die andere NVMe legen.

Ab $455 im Monat