Selfhosted

It's been a while since I've done it, but there's an option in Clonezilla which lets you clone a smaller drive onto a bigger one, while expanding it to fill up the extra space.

I have a little Proxmox installation running a VM on a 256GB NVMe, which as you can imagine is tight

Not as tight as I was imagining a 256 MB installation to be.

I know nothing about promox, but because it's quiet in here, I imagine cloning the original drive for the original system then expanding it to take over the whole drive is the easier thing to do, it's a fairly standard process and generally nondestructive because you can just put the old drive back in if something breaks.

So, I would probably go e) unless you really want to set everything up again from scratch (which is sometimes nice to do)

Add a second node using the new drive, move all vm to the new node, decommission old node, rebuild the old node with the new drive.

You can get away with a disk clone but in my opinion a vm move is the proper way to go.

Adding a new node you start with a clean install, any quirk you have on the old hw will be finally washed away (or will bite you back and be properly documented), you have a quick way back should anything go sideways (the clone too provides a quick way back, but i like this way much more ^^), you get some hands on multi node experience that will be useful for ha setup.

That depends on what level of HA you want to end up with.

If you want proper HA, you'll want to plan on adding a (small, like a Raspberry Pi) third node for quorum. If you are already taking backups and you just want "I can restore on the second system" then it's slightly simpler, but mostly the same process:

• Setup new node, add to cluster
• Migrate all VMs and LXCs to new node
• Remove and upgrade other node
• Add rebuilt node to cluster

If you're planning on proper HA, I'd strongly advise having the proxmox installation on a second small drive on each node and leaving your 1tb drives as data only.

This article half-explains one option for a two node setup (zfs replication), which is functional but not ideal. If you want to get your feet wet with Ceph then I can give you some pointers.

I like @pgo_lemmy’s answer best, but instead of rebuilding the original system, (assuming you did the default ZFS installation) you can add the bigger device as part of a mirror, let it resilver, install the boot loader, and then detach the smaller device from the mirror. It should automatically grow to the bigger size once the smaller device is removed and the only downtime you’d have is from installing the bigger device. Check the PVE wiki and you should find some details on this method.

I recently had to increase my proxmox storage as well from an old 256 to 1TB. What I did was make a copy of /etc via PVE Host Backup and saved that on my NAS/external storage. Almost everything is in /etc/pve. Then I created backups of all the VMs and stored those on the same external storage. I then installed proxmox as normal and compared configs between backup and new configs then restored VMs from backup. The reason I did it this way is because 1) I had installed proxmox a while ago and new config > old config for stability after adding some necessary PVE scripts (e.g. intel chip, and 2) I've had weird issues before cloning drives and a fresh install was easier than risking some weird edge case troubleshooting. It also let me keep the old SSD as a backup in case something went wrong.

Edit: Also recommend going with zfs mirrored on the new install during the setup: target disks options and zfs mirrored. ZFS offers some benefits vs the default lvm.

This would be a great application of btrfs. Copy over the boot-partition directly via cp /dev/nvme{0,1}n1p1 or similar.
Then, simply add the data partition(s) to btrfs. You can then tell btrfs to migrate all data out of the old partition, and finally remove it. All in a running system.

I have migrated the rootfs on running systems before using this method, it's a super clean approach.

BTRFS also nicely handles the redundancy with its checksums. Usually you can't fix bitrot between two drives, but btrfs can tell which version is correct. Makes scrubbing easier.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

7 acronyms in this thread; the most compressed thread commented on today has 3 acronyms.

[Thread #299 for this comm, first seen 17th May 2026, 14:40] [FAQ] [Full list] [Contact] [Source code]