Storage Tiers on a VPS: OS, Data, and Backup Placement

Most VPS performance problems are not about raw disk speed; they are placement problems. The database sharing a filesystem with rotating logs, the nightly backup landing beside the live data it should protect, swap thrashing the same volume as the app. A single High-Speed SSD in a Netbay VM can still behave like three very different tiers if you decide, at mount time, which workload each path carries. This guide names the split, proposes a concrete layout, and gives the commands to implement it on the default Ubuntu image.

The three workloads on one SSD

Almost everything a VPS writes falls into three classes, and each has a different value and a different failure cost:

• OS and packages: a few gigabytes, eminently reproducible, cheap to rebuild. A reinstall reproduces most of this automatically.
• Application data: the database, uploads, indexes, session state. This is the part that cannot be recreated by rerunning an installer, and it is usually where capacity actually goes.
• Backups and exports: dumps, archives, old logs. Small most of the day, suddenly large at 02:00, and worthless if they share a filesystem that fills or a disk that fails.

Mixing the three means a single runaway writer, like a misconfigured log stream or a leaking upload directory, fills one volume and takes the database down with it, while also consuming the backup that would have rescued you. Separate filesystems make each problem visible, repairable, and stoppable in isolation, and each mount can then be sized, snapshot, and alerted on its own terms.

A concrete layout for a single VM

• / — the root filesystem holds the OS and packages. Size it for the distribution plus headroom, and keep it boring.
• /var/lib/postgresql (or mysql, redis, whatever runs) — the database home on its own logical volume so it can grow, snapshot, and be monitored without touching anything else.
• /srv/backups — the dump target. This must never share a filesystem with the data it protects.

Netbay provisions every VM on enterprise High-Speed SSD, so the physical media are already fast. The win here is logical separation: an out-of-space event on /srv/backups, or a botched restore interrupted half-way, must never be able to stop the production database. The bills you pay for keeping these apart are one extra volume and one cron line; the alternative is discovering the coupling at 3 a.m.

Size it before you place it

Measurement comes before layout. On a fresh box these three commands tell you what a migration will cost, and they work on any distribution, because they only use tools every base install ships with:

df -h /
du -xsh /var/lib/postgresql/* 2>/dev/null | sort -h | tail -n 5
du -xsh /var/log

Take the largest lines of the du output as the sizing floor for the data volume, add 25 percent headroom, and remember that databases grow with users, not with your predictions. Budget the backup volume as roughly one compressed full dump per day multiplied by your retention window in days; for a modest PostgreSQL box that lands between 100 and 250 GB per month, which is cheap insurance on any Netbay plan.

Wiring it up with LVM

Ubuntu and Debian installers enable LVM by default, so carving a new data volume is three commands. The example assumes the volume group is vg0 and the underlying disk still has free space:

lvcreate -L 20G -n data vg0
mkfs.ext4 /dev/vg0/data
mkdir -p /srv/backups
echo '/dev/vg0/data /srv/backups ext4 defaults 0 2' >> /etc/fstab
mountpoint -q /srv/backups || mount /srv/backups

ext4 is a correct, boring default for general VPS work; the filesystem comparison post in this series covers when XFS, btrfs, or ZFS deserve a look. The important habit is that the mount exists and is in fstab before any cron job points at it, because a backup that fails at mount time is a backup you never had.

Keep the seams visible

A separate filesystem pays for itself the first time it fills. Check each mount individually and watch the tightest number rather than one combined total:

df -h --output=source,size,pcent / /srv/backups
df -P /srv/backups | awk 'NR>1 && $5+0 >= 85 { print "WARN " $6 " at " $5 }'

Put that awk line in a cron job that mails its output, or point an existing monitoring agent at each mount point. When the backup volume crosses 85 percent, the fix is local and safe: extend the logical volume with the LVM playbook, prune retention, or move dumps to an off-box target. None of it requires touching the running database.

Takeaway

Tier by placement, not by price: the OS on root, the data on its own volume, backups on a third, each sized and alerted on its own. Netbay's High-Speed SSD keeps every tier fast; your job is keeping them separate. Spin up an Ubuntu instance at netbayhosts.in and lay this out from the first boot.