Which NVMe holds the guest disk, and which holds the backup?

Name the system disk before touching the other one

Select Proxmox VE 8 or Proxmox VE 9 on the order. Both are already in the image list. After delivery, SSH in. A USB reinstall is not how the second disk appears, and the image will not fold the two drives into a hardware array. There is no array card in the chassis.

Run lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL, then findmnt / and pvesm status. Two NVMe devices of about 1TB each show up as type disk. The one that holds the root filesystem is the system disk. The other has an empty mount column and is the unused second drive. Record the stable name under /dev/disk/by-id/ and the serial. After a reboot, nvme0n1 and nvme1n1 can swap. Partition and format by the by-id name, not by the number seen in this session.

Guest disks land on the system NVMe by default

When the image installs Proxmox on one NVMe, that drive usually carries two storages. local is a directory on the root filesystem, under /var/lib/vz. It can hold ISOs, snippets, and vzdump backups. local-lvm is LVM-Thin on the same drive. Guest disks and container disks are written there. The names differ. The physical device is still that one NVMe.

A new guest whose disk storage is local-lvm therefore stores the disk on the system drive. A backup job that still targets local writes into /var/lib/vz/dump, which is the system drive again. If that drive goes offline, the guest disk and that backup go offline together. Two storage names in the interface do not mean the second NVMe is in use.

Use lsblk to see which NVMe holds the volume group behind local-lvm. It should be the same drive as root. The second drive, about 1TB, has no partition yet and is not a member of that volume group. That is the direct-attached delivery, not a missing array.

Point backups at the other NVMe

Partition the second drive by itself, make a filesystem on it, and mount it at a new directory such as /mnt/backup-nvme. GPT and a single partition are enough. ext4 is enough for backup files. /etc/fstab should store the UUID, not a name like /dev/nvme0n1p1 that can change. After mount -a, findmnt /mnt/backup-nvme must show the second drive’s by-id as the source, not the system disk.

Add a directory storage in Proxmox. In the datacenter, open Storage, Add, Directory. The path is that mount. Content is VZDump backup only. The matching command is pvesm add dir backup-nvme --path /mnt/backup-nvme --content backup. Choose a storage ID that does not collide with local. In pvesm status the row should be active, and the free space should be close to the second drive, not the leftover space on root.

Existing backup jobs have to move to this storage. Adding the directory while the job still says local keeps new backups on the system disk. With no guest yet, confirm the mount and the storage status first, then create the guest. With a guest, run one backup and pass the new storage ID as --storage to vzdump. Snapshot mode needs a disk storage that supports snapshots. local-lvm does. The backup file appears in the directory on the second drive, and the name starts with vzdump-.

An added 2TB drive is still its own disk

An added 2TB NVMe is $84 a month, two drives at most, direct-attached, and outside any hardware array. In lsblk it is a new disk row of about 2TB. It does not join the two 1TB drives, and it does not grow local-lvm by itself. Treat it the way the empty 1TB drive was treated: its own partition, its own mount, its own storage entry.

When the second 1TB drive already holds backups, the 2TB drive is the place for more guest disks. Add a directory storage on the new mount, set the content to disk image, and select that storage when creating a large guest disk, instead of writing it into the thin pool on the system drive. When backups are the thing that does not fit, point the backup job at the 2TB drive and keep the second 1TB for disk images. Either way, disks and the only backup stay on different drives. Do not write both onto one NVMe.

Do not vgextend the 2TB drive into the system disk’s volume group. Once the group spans two NVMe devices of different sizes, guest-disk extents can land on either drive, and a backup that still lives on root shares that failure. This is not a hardware array. Why an added drive stays outside an array is covered in an added disk stays outside the array. Mirroring the two default 1TB drives drops usable space to about 1TB, and the split in this note no longer exists. That layout is in redundancy without a hardware array.

Capacity is the sum, not the space left after a mirror

Used as two filesystems, the two 1TB drives provide about 2TB, minus the partition table, the filesystem, and the system files already on root. Reading them as RAID 1, with 1TB left, does not match the two disk rows in lsblk, and it leaves no second drive for the backup directory.

A guest disk and its backup each consume space. A guest disk allocated at 400GB needs room in the thin pool for what was actually written, and the second drive needs room for one backup. The 400GB is not subtracted once from a 2TB total. Thin provisioning makes the volume look smaller than the allocation. The backup file still depends on the mode and the compression of that run. Plan the data that will be written on each drive. Do not plan from a single total in the storage list.

ext4 reserves a slice of blocks for the root user by default. A backup directory used by vzdump will show less than the labeled size of the drive. That reserve is the filesystem, not a missing disk. After the mount, df -h on that row is the number to use when choosing how many backups to keep.

After one backup, confirm which drive holds the file

1. The second drive is mounted

   findmnt /mnt/backup-nvme names the second NVMe by-id as the source. After one reboot the mount is still there, and root is still there.

2. The storage is not local

   In pvesm status, the backup storage path is the new mount. The backup job’s storage field is that ID. If the job still says local, change it before the next run.

3. Run vzdump once

   Pick a guest that can be snapshotted and send the storage to the new directory. When it finishes, a vzdump- file is in that directory. findmnt -T on the file must name the second drive.

4. The system disk does not fill in step

   Watch df -h / during the backup. Growth under /var/lib/vz/dump means the job still targets local. Stop it, change the storage, and run again.

Retention has to fit the free space on the second drive. Many copies, each close to the whole guest disk, make the next backup fail halfway and leave a partial file. That partial file is not a restorable copy. Remove it, lower the retention to a count the drive can hold, and run one backup that finishes.

Moving a large disk that already lives on local-lvm starts with the guest powered off, then a move to the new directory storage, then a boot check. Do not copy the disk file while the guest is still writing. Backup files are created again on the new storage. Old files left in the system-disk dump directory are not protection for the new drive.

This is the disk layout the machine ships with

Both memory tiers ship with the same disks: 2 × 1TB NVMe, no hardware RAID, each drive direct-attached, usable capacity counted as 2TB. The 128GB machine is $455 a month. The 256GB machine is $612 a month. Memory is DDR4-3200 ECC RDIMM and is not added later. 256GB means that tier. The CPU on both is AMD EPYC 7543P, 32 cores and 64 threads. One added 2TB drive makes the 128GB monthly rent $539. The add-on count is 0, 1, or 2, at $84 each. That amount joins the monthly rent, then the month count applies. Quarterly is three times, with no further discount. There is no setup fee.

The machine is deployed in Tokyo, Japan. SSH to the host uses the address in the console. Changing the disk layout does not change that login address. Proxmox VE 8 and 9 are in the free image list. The second drive and any added drive are mounted in the system. The image does not present them as one hardware volume.

The split is done when the block device of the guest disk and the block device of the backup file are not the same device. The storage name, the storage ID on the backup job, and the source from findmnt -T have to agree. Then the backup has left the system NVMe.