How to Add a Second Hard Drive to Proxmox VE 9.2 Safely

Quick answer

For a new or disposable second disk in Proxmox VE 9.2, the simplest beginner option is usually Directory storage created from the node’s Disks section.

The critical step is identifying the correct physical disk. Creating a filesystem destroys existing data on the selected device.

If the disk already contains data you need, stop and use How to Mount an Existing Linux Drive in Proxmox instead.

This procedure is written against the Proxmox VE 9.2 baseline. Minor package updates can change button wording, so match the disk by model, serial and capacity rather than relying only on a screenshot.

---

Choose the storage design first

Situation	Sensible starting point	Why
New empty disk for ISOs, backups or ordinary files	Directory storage	Simple filesystem and visible files
Existing ext4/XFS disk with data to preserve	Mount it by UUID, then add Directory storage	Avoids formatting existing data
Dedicated VM/LXC disk with thin provisioning needs	LVM-thin	Block storage and thin provisioning
Multiple disks needing checksums or ZFS features	Deliberately designed ZFS pool	Different procedure and resource trade-offs
Only local backup destination	Add storage, but create another backup failure domain	Same-host storage is not enough by itself

Read Proxmox Storage Explained before choosing. Directory storage is file-level storage and can hold only the Proxmox content types you enable, such as ISO images, backups, templates or guest images.

Step 1: identify the disk without changing it

Open the node shell and run:

lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
blkid
findmnt

For a candidate such as /dev/sdb, inspect signatures without erasing them:

wipefs -n /dev/sdb

If SMART is available:

smartctl -a /dev/sdb

Replace /dev/sdb only after matching the model, serial number and capacity printed on the physical drive.

Stop if you find:

• an existing filesystem
• an LVM, ZFS or RAID signature
• a mounted partition
• a disk used by a guest
• any data you have not backed up and verified

Step 2: record the maintenance decision

Save this information outside the server:

Item	Record
Model and serial	From lsblk or smartctl
Current device path	For this maintenance session only
Existing signatures	From wipefs -n
Intended purpose	VM disks, backups, ISOs or another role
Filesystem choice	Record the reason
Proxmox storage ID	Use a clear unique name
Backup status	Confirm independently

Device names such as /dev/sdb can change. Persistent mounts should resolve by UUID or another stable identifier.

Step 3: create Directory storage in Proxmox VE 9.2

For an empty disk that you explicitly approve for erasure:

1. Select the Proxmox node.
2. Open Disks and confirm the model, serial and size again.
3. Open Directory under Disks.
4. Choose Create: Directory.
5. Select the intended disk and filesystem.
6. Enter a clear storage name.
7. Select only the content types this disk should hold.
8. Review the destructive warning before confirming.

Do not continue if the selected device differs from your written serial number. Initialising the disk or creating the filesystem removes existing data.

The interface should create the filesystem, mount point and storage definition. Do not manually add a second conflicting mount for the same filesystem.

Step 4: verify the storage definition and mount

After the task completes:

pvesm status
lsblk -f
findmnt
cat /etc/pve/storage.cfg
df -hT

Confirm:

• the storage is active
• its capacity matches the expected drive
• the mount resolves to the expected filesystem and UUID
• only the intended content types are enabled
• no unexpected disk or partition changed

A storage entry can point to an ordinary directory even when the intended disk is not mounted. Always use findmnt or lsblk -f to prove the backing filesystem.

Step 5: test with non-critical content

Before moving an important guest, use a low-risk test supported by the enabled content types:

• upload a disposable ISO
• create a temporary backup of a test guest
• create a small test VM disk

Confirm that the task completes, storage usage changes as expected and the created content appears on the correct filesystem.

Step 6: reboot and prove persistence

A mount that works before reboot is not yet proven.

Before rebooting:

• make sure no important task is running
• confirm local-console access
• record pvesm status and findmnt
• confirm important guests are backed up
• disable automatic starts that depend on the new disk until the test passes

After the controlled reboot:

pveversion -v
pvesm status
findmnt
lsblk -f
systemctl --failed
journalctl -b -p warning --no-pager

Confirm the new storage is active before starting or migrating important guests.

If the storage is inactive after reboot

findmnt
systemctl status mnt-pve-*.mount --no-pager
journalctl -b --no-pager | grep -Ei 'mount|filesystem|storage'
cat /etc/fstab
cat /etc/pve/storage.cfg

Likely causes include a wrong UUID, filesystem errors, disconnected cabling, slow USB initialisation, an incorrect mount point, or a storage definition pointing to an unmounted directory.

Do not let a backup job or guest write into an empty mount-point directory while the real disk is absent.

Moving a guest later

Adding storage does not require immediately moving a production VM or container.

When you are ready:

1. create or verify an independent guest backup
2. confirm the target storage supports the guest content type
3. move one non-critical disk first
4. watch the Proxmox task log
5. boot and test the guest
6. confirm the old volume is handled as intended

Do not combine the first storage test with a Proxmox upgrade or a guest operating-system upgrade.

Common mistakes

• selecting the Proxmox system disk
• relying only on /dev/sdX
• formatting a disk that contains old data
• enabling every content type without a plan
• assuming a storage entry proves the disk is mounted
• moving the only guest copy before testing
• skipping the reboot check
• treating an internal disk as the only backup

Final verification checklist

• Model, serial and capacity were matched.
• Existing signatures were inspected read-only.
• Destructive formatting was explicitly intended.
• pvesm status reports the storage as active.
• findmnt resolves to the correct disk.
• Capacity and content types match the plan.
• A non-critical write test succeeded.
• A controlled reboot succeeded.
• Important data has another recoverable copy.

These are source-verified implementation steps, not a claim that SmallGrid has completed this physical disk change in its own lab.

Next: How to Mount an Existing Linux Drive in Proxmox.

Official references: Proxmox VE storage and pvesm manual.