Proxmox Storage Upgrade: When SAS RAID10 Beats SSDs

A Proxmox storage upgrade does not always need to start with SSDs. In an older virtualization host, the actual constraint may be usable capacity and budget rather than latency. That was the situation here: the host already delivered acceptable day-to-day performance from six 10K SAS disks in RAID10, but its VM datastore had only about 835 GiB available.

This field note documents the decision process, not a universal hardware recommendation. It compares enterprise SSDs, budget SATA SSDs, and refurbished SAS disks against the workload, controller, risk, and remaining value of an aging server.

The starting point: separate OS and VM arrays

The server used a hardware RAID controller and two independent virtual disks:

2 × 300 GB SAS → RAID1 → Proxmox OS
6 × 300 GB SAS → RAID10 → VM datastore

The six-disk data array exposed roughly 835 GiB of usable space. Keeping the operating system on a separate mirror was operationally important: a future replacement of the six data disks would not require rebuilding the Proxmox node, changing its identity, or reinstalling the cluster configuration.

The datastore was a standard directory-backed filesystem mounted below /mnt/pve/. Proxmox treats directory storage as a file-level backend and can keep the same storage definition when the filesystem behind the mount point is replaced. The current Proxmox VE Administration Guide documents directory storage, pvesm status, and pvesm list for inventory and verification.

Define the real bottleneck before buying disks

The host was compared informally with another virtualization server using SSD storage. For its ordinary infrastructure and application VM mix, the older SAS array did not feel dramatically slower. That observation did not make SAS “as fast as SSD”; it showed that storage latency was not dominating the current workload.

SSDs remain much stronger for high-concurrency random I/O, databases, build workloads, dense container platforms, and snapshot-heavy operations. But purchasing that performance only creates value if the applications are actually waiting for storage.

The planning question therefore changed from:

What is the fastest storage we can install?

to:

What is the least expensive safe way to gain enough usable capacity for the remaining life of this host?

That is the right starting point for any budget-sensitive Proxmox storage upgrade.

Compare three realistic upgrade paths

Three options were considered.

Enterprise SSDs

Enterprise SATA SSDs with appropriate endurance and power-loss protection were technically attractive. They also represented a large investment in a server already more than a decade old. Management was unlikely to approve the cost, especially because the existing array was not a demonstrated performance bottleneck.

Budget consumer SSDs

Consumer SATA SSDs offered much better random I/O at a lower purchase price. The trade-off was equally clear: desktop-oriented models usually lack enterprise power-loss protection and are not specified for sustained server write workloads. They might be reasonable for replaceable development or test workloads with strong backups, but they were harder to justify for mixed VM storage behind an older RAID controller.

Using consumer SSDs would also require a careful review of controller firmware, battery or CacheVault health, write-cache policy, endurance, drive error handling, and the organization’s tolerance for a less conventional configuration.

Refurbished 10K SAS disks

The third option was a matched set of larger refurbished enterprise SAS disks. One concrete offer available during the evaluation was six 900 GB 10K SAS drives at about €35 each when purchased in quantity. The listing price was time-specific and still required validation, but it changed the economics: approximately €210 could nearly triple usable capacity while staying with the media type the server and controller were designed to use.

Do the RAID10 capacity math

RAID10 mirrors pairs and stripes across those mirrors. With six equal-size drives, half of the raw decimal capacity is available before filesystem overhead and the TB-to-TiB conversion.

Configuration	Raw capacity	Approx. RAID10 usable	Change from current
6 × 300 GB SAS	1.8 TB	about 0.82 TiB	baseline
6 × 900 GB SAS	5.4 TB	about 2.45 TiB	almost 3×
6 × 1.2 TB SAS	7.2 TB	about 3.27 TiB	almost 4×
6 × 1 TB SATA SSD	6 TB	about 2.73 TiB	about 3.3× plus lower latency

These values are planning estimates, not promises from a storage controller. Final capacity depends on drive-reported size, controller metadata, partitioning, and filesystem overhead.

Why SAS remained a credible choice

The proposed 900 GB drives were from an enterprise 10K SAS family using a 6 Gb/s interface and 512-byte sectors. The official Seagate Savvio 10K.6 product manual lists the relevant 900 GB model family and its performance characteristics.

A six-disk RAID10 can also aggregate throughput across three mirrored pairs, while the hardware controller’s protected write cache can improve short bursts. That does not erase rotational latency, but it explains why a lightly to moderately loaded VM host can feel responsive in normal administration even when benchmarks show a major SSD advantage.

The SAS option aligned with four facts from this environment:

1. The urgent requirement was more capacity.
2. The existing array was not producing a clear user-visible performance problem.
3. The server’s remaining economic life did not justify a premium flash investment.
4. Backups and workload placement already reduced the impact of a host-level storage failure.

The decision would change if database latency, CI build time, VM density, or storage queueing became the primary constraint.

Checks before buying used enterprise disks

A low price is not enough. Before buying a used set for a Proxmox storage upgrade, verify:

• Exact model and interface: SAS is not interchangeable with every SATA-only backplane or controller.
• Sector format: all members should use the format supported by the controller, such as 512-byte sectors in this case.
• Consistent capacity: the smallest member limits every RAID10 pair.
• Similar history: closely matched power-on hours and the same model reduce surprises.
• Firmware compatibility: identical firmware is preferable where a full matched set is available.
• Error evidence: do not rely only on a seller’s “100% health” claim; validate drive and controller diagnostics after receipt.
• Spare strategy: consider buying an additional matched disk if the price is low and future availability is uncertain.
• Backup and rollback: keep the original labeled RAID members untouched until the new datastore is built, tested, and repopulated.

Used disks are a risk decision, not only a capacity calculation. A low-cost array makes sense only when the recovery path is strong enough for the workloads it will host.

What the upgrade would change operationally

Because the Proxmox OS lived on a separate RAID1 virtual disk, the six data drives could be treated as one replaceable storage layer. The planned sequence was:

1. Inventory every VM disk, container volume, ISO, backup, template, and snippet on the datastore with pvesm list and guest configuration checks.
2. Migrate guests with local disks to another host where space permits, or create verified backups for restore.
3. Confirm that the datastore contains no required content, then disable and unmount it.
4. Power down only the affected host; do not remove it from the Proxmox cluster.
5. Label and retain the original six disks as a rollback set.
6. Create a new six-disk RAID10 virtual drive, partition it, build the filesystem, and mount it at the same path.
7. Update the filesystem UUID in /etc/fstab, enable the storage, and verify it with findmnt, df, and pvesm status.
8. Return workloads gradually and monitor controller and guest I/O behavior.

Proxmox storage definitions live in /etc/pve/storage.cfg. If the same directory mount point and storage ID are preserved, the logical storage definition can remain unchanged even though the hardware virtual disk underneath it is new.

This is also why failure-domain planning matters. The article on k3s high availability across Proxmox failure domains shows that cluster redundancy can be misleading when multiple workers share one physical storage failure domain. The k3s migration workload-placement rules provide the broader context for deciding which services should depend on this host at all.

The Proxmox storage upgrade decision rule

The outcome was not “SAS is better than SSD.” The useful conclusion was narrower:

When an older Proxmox host is capacity-constrained, its current VM workload is not storage-bound, and premium SSDs cannot be justified, a matched set of larger enterprise SAS disks in RAID10 can deliver the best value for the host’s remaining service life.

If the problem later becomes random I/O latency rather than space, the answer changes. At that point, SSDs, a newer host, or a different storage architecture may be the more honest investment.

A good Proxmox storage upgrade begins with workload evidence, controller compatibility, recovery design, and a realistic budget. Hardware should solve the bottleneck that exists—not the one that produces the most impressive benchmark.