Storage Architecture

Purpose

This page documents the physical disks, Proxmox storage pools, logical-volume layout, filesystem mounts, and intended storage roles within the Bytek homelab.

The storage architecture separates:

The main design goal is to prevent application data, operating-system disks, and backups from competing for the same physical storage role.

Storage Overview

Physical Disk Inventory

Linux device names such as /dev/sda can change between boots or hardware changes.

Permanent references should use:

System NVMe

Physical Device

Partition Layout

Logical Volumes

Proxmox Storage

The pve-data thin pool appears in Proxmox as:

Intended Use

The system NVMe stores:

Current Workloads

The system NVMe currently stores operating-system disks for services such as:

Storage Policy

Use local-lvm for:

Avoid using local-lvm for:

User-Data NVMe

Physical Device

LVM-Thin Layout

The user-data NVMe contains:

These components represent:

Proxmox Storage

The thin pool appears in Proxmox as:

Intended Use

The user-data NVMe stores:

Current Major Workload

Nextcloud has a separate virtual data disk on user-data.

The Nextcloud operating system remains on local-lvm, while user files remain on user-data.

This separation makes it easier to:

Thin Provisioning

The local-lvm and user-data storage pools use LVM-thin provisioning.

A thin-provisioned virtual disk does not immediately consume its full nominal capacity.

For example, a 500 GB virtual disk initially consumes only the physical blocks that have actually been written.

Important Consequence

The sum of all nominal virtual-disk sizes may exceed the physical capacity of the thin pool.

This is safe only when actual usage is monitored.

If the thin pool reaches full physical allocation, affected VMs may experience:

Thin-Pool Monitoring

Review Proxmox storage usage using:

pvesm status

Review LVM-thin usage using:

lvs -a -o vg_name,lv_name,segtype,lv_attr,lv_size,data_percent,metadata_percent

Monitor both:

Suggested operational thresholds:

These thresholds are operational recommendations and should be adjusted based on growth rate and workload importance.

Backup HDD

Physical Device

Permanent Mount

The filesystem UUID is used instead of /dev/sda1 because Linux device letters can change.

Mount Options

The backup filesystem uses:

Mount-Point Protection

The Proxmox storage uses mount-point validation.

This prevents Proxmox from treating the empty directory /mnt/pve/pve-backup as valid storage when the HDD is not mounted.

Without this protection, a failed HDD mount could cause backups to be written to the Proxmox root filesystem.

That could fill the root filesystem and disrupt the hypervisor.

Backup-HDD Intended Use

The backup HDD stores:

The backup HDD must remain dedicated to backups.

Prohibited Backup-HDD Uses

Do not use the backup HDD for:

Mixing active workloads with backups would:

Storage Placement Rules

Future Plex Storage

The RTX 2060 Plex VM should not use the backup HDD for media.

Recommended placement:

A temporary media disk may be created on user-data for initial testing.

Long-term media storage should ideally use:

Media capacity planning must account for continued Nextcloud growth on user-data.

Future Game-Server Storage

A dedicated game-server VM should use:

Steam-installed server binaries can usually be downloaded again.

Unique game-world data, configuration files, allowlists, bans, and mods require backup.

Storage Expansion Principles

Before adding physical storage, decide whether the new disk is intended for:

Avoid adding unrelated physical disks into an existing unmirrored LVM volume group merely to increase capacity.

Safer future expansion patterns include:

Failure-Domain Considerations

System NVMe Failure

Expected impact:

Recovery would require:

User-Data NVMe Failure

Expected impact:

Backup HDD Failure

Expected impact:

Complete Host Failure

Expected impact:

This is the primary reason a future offsite or separate-host backup is required.

Snapshot Policy

Proxmox snapshots are used as short-term rollback points.

Recommended snapshot use cases:

Snapshots are not backups because:

Delete unnecessary snapshots after the associated change has been validated.

Avoid snapshots with RAM unless restoring the exact running state is required.

Storage Validation

Confirm Proxmox Storage

Use:

pvesm status

Expected storage IDs include:

Confirm Backup Mount

Use:

findmnt /mnt/pve/pve-backup

The source should be /dev/sda1.

Confirm Backup Capacity

Use:

df -h /mnt/pve/pve-backup

Confirm Physical Devices

Use:

lsblk -e7 -o NAME,PATH,SIZE,TYPE,FSTYPE,PTTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN

Confirm Thin-Pool Utilization

Use:

lvs -a -o vg_name,lv_name,segtype,lv_attr,lv_size,data_percent,metadata_percent

Confirm Storage Configuration

Use:

cat /etc/pve/storage.cfg

Do not store credentials or secrets in the documentation when recording command output.

Disk-Health Monitoring

The backup HDD should be monitored using SMART.

Stable backup-HDD identifier:

/dev/disk/by-id/wwn-0x5000cca097c44d7e

Useful checks:

Important attributes include:

Pending or uncorrectable sectors require immediate review.

NVMe health should also be reviewed periodically using the appropriate NVMe SMART tools.

Capacity Review Checklist

Perform a storage review when:

Review:

Current Limitations

The current storage architecture does not provide disk redundancy.

The system NVMe, user-data NVMe, and backup HDD are independent single devices.

The architecture protects against some logical failures through backups, but does not provide uninterrupted operation after a physical disk failure.

The local backup HDD is in the same:

Future priorities include:

Document Control