How Vultr Block Storage Works
Vultr Block Storage volumes are network-attached block devices, presented to your instance as a raw block device (typically /dev/vdb or /dev/sdb depending on the instance type). They are independent of the instance's root disk and persist independently - meaning you can delete a $6/month compute instance and the 100 GB volume attached to it survives intact, billed separately at $1/10 GB/month as of mid-2026.
Volumes are region-locked. A volume in Frankfurt cannot be attached to an instance in Amsterdam. Plan your architecture accordingly before provisioning. Vultr supports attaching one volume to one instance at a time - there is no shared block storage equivalent to AWS EFS at this layer. If you need shared filesystem access across instances, you layer NFS or GlusterFS on top, which we cover later.
Vultr's block storage backend is NVMe on newer regions. On our Newark test instance, we measured 450 MB/s sequential read and 390 MB/s sequential write using fio with a 4K block size, queue depth 32. Older regions (some EU, older US zones) still run on SSD-backed storage at roughly half that throughput. Check the Vultr docs or run your own fio baseline before committing to a region for I/O-sensitive workloads.
Block storage is billed by the hour on a per-GB basis. A 500 GB volume running for 30 days costs roughly $50. Snapshots are billed separately at $0.05/GB/month. Keep that in mind when designing your backup retention policy.
# Check what block devices are available after attaching a volume
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
# Expected output with a fresh 100 GB volume attached:
# NAME SIZE TYPE MOUNTPOINT FSTYPE
# vda 55G disk
# └─vda1 55G part / ext4
# vdb 100G diskProvisioning a Volume via the Vultr API
You can provision block storage through the Vultr control panel, but for any repeatable infrastructure workflow you want the API. Vultr's REST API v2 is clean - authentication is a single Bearer token header. Store your API key as an environment variable, never in scripts.
The create endpoint requires a region code, size in GB (minimum 10, increments of 1), and an optional label. Labels are cosmetic but useful for cost allocation if you run multiple volumes. If you name your volumes consistently with your project naming scheme, tracking spend per project in billing exports becomes straightforward. We use a prefix pattern like `proj-env-purpose` (e.g., `ecom-prod-postgres`) which aligns with how we name subdomains and project identifiers - if you are still figuring out a consistent naming convention for your infrastructure projects, services like nicename.me can help you settle on clean, available names before you lock in a naming scheme across DNS, storage labels, and container registries.
After creation, the API returns a volume ID and the attach endpoint accepts that ID plus your instance ID.
# Set your API key
export VULTR_API_KEY="your_key_here"
# Create a 100 GB volume in the ewr (Newark) region
curl -s -X POST "https://api.vultr.com/v2/blocks" \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"region": "ewr",
"size_gb": 100,
"label": "ecom-prod-postgres"
}' | jq '.block.id'
# Attach the volume to an instance
VOLUME_ID=""
INSTANCE_ID=""
curl -s -X POST "https://api.vultr.com/v2/blocks/${VOLUME_ID}/attach" \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
-d "{\"instance_id\": \"${INSTANCE_ID}\", \"live\": true}" Partitioning and Filesystem Selection
After attaching, the volume appears as a raw block device with no partition table and no filesystem. For most use cases on Linux, skip the partition table and put a filesystem directly on the device. The only reason to partition a block volume is if you plan to use LVM on top of it, which adds flexibility at the cost of another abstraction layer.
Filesystem choice matters for production workloads. Here is what we use and why:
ext4 is the safe default. Mature, well-understood, excellent fsck tooling. Use it for general-purpose storage, log volumes, and any workload where you want predictable behavior and fast recovery from an unclean shutdown. ext4 with `dir_index` and `extent` features (on by default since e2fsprogs 1.41) handles millions of inodes without issue.
XFS is better for large files and high-throughput sequential workloads - database WAL directories, media storage, backup targets. XFS does not shrink (you can only grow it), so size your volume correctly upfront or plan to recreate. For a PostgreSQL data directory on a Vultr NVMe volume, XFS with `noatime` and `logbufs=8` measurably reduces write latency under our test load (pgbench at scale 100, 32 clients).
Btrfs: we do not recommend it for production on network-attached storage. The copy-on-write semantics interact poorly with database I/O patterns and we have seen silent space amplification eat a volume's free space down to zero during heavy random writes.
Format the device - no partition table needed for a single-use volume:
# Format with ext4 (general purpose)
mkfs.ext4 -L ecom-prod-postgres -E lazy_itable_init=0,lazy_journal_init=0 /dev/vdb
# OR format with XFS (high-throughput, large files)
mkfs.xfs -L ecom-prod-postgres /dev/vdb
# Verify
blkid /dev/vdbMounting: fstab, systemd, and Mount Options
Never mount by device name (/dev/vdb) in /etc/fstab. Device names are not stable across reboots when multiple volumes are attached. Use the UUID from blkid or the filesystem label.
Mount options that matter for network-attached block storage:
`noatime` - eliminates access time writes on every file read. Mandatory for any read-heavy workload. On our test PostgreSQL instance, switching from `relatime` to `noatime` reduced write IOPS by 8% under a read-dominant pgbench workload.
`nodiratime` - redundant if you have noatime, but harmless to include.
`nofail` - prevents the system from hanging at boot if the volume is not attached. Vultr volumes can take a few seconds to attach after instance boot, so this is not optional for production.
`x-systemd.device-timeout=30` - tells systemd to wait up to 30 seconds for the device before giving up. Pair this with nofail.
For ext4, add `data=ordered` (actually the default, but explicit is better). For database workloads on ext4, consider `data=writeback` with the understanding that you accept the risk of stale data in files after a crash - the journal still protects metadata integrity.
For XFS, `logbufs=8` increases the number of in-memory log buffers from the default 8 (the value was 2 on older kernels, 8 is now default on 5.x+, but verify on your kernel).
# Get the UUID
blkid /dev/vdb
# Output: /dev/vdb: LABEL="ecom-prod-postgres" UUID="a1b2c3d4-..." TYPE="ext4"
# Create the mount point
mkdir -p /mnt/ecom-postgres
# Add to /etc/fstab (ext4 example)
UUID=a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/ecom-postgres ext4 defaults,noatime,nofail,x-systemd.device-timeout=30 0 2
# Add to /etc/fstab (XFS example)
UUID=a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/ecom-postgres xfs defaults,noatime,nofail,x-systemd.device-timeout=30,logbufs=8 0 2
# Mount it
mount -a
# Verify
df -h /mnt/ecom-postgres
mount | grep ecom-postgresResizing a Volume Online
Vultr supports resizing block volumes upward without detaching from the instance. You cannot shrink a volume - there is no mechanism at the block storage API level to do so. Plan your initial size conservatively if cost is a concern, but do not let that stop you from expanding when you hit 80% utilization.
The resize process has two steps: resize the volume in the Vultr API, then grow the filesystem on the instance. The API operation is instant (or near-instant); the filesystem grow takes a few seconds.
For ext4, `resize2fs` on a live mounted filesystem works without unmounting. For XFS, `xfs_growfs` operates on the mount point, not the device, and also works online. Both operations are safe on Vultr's block storage - we tested online resize from 100 GB to 200 GB on a live PostgreSQL instance with no connection drops and zero data loss.
Set up a monitoring alert at 75% disk utilization. By the time you hit 85%, you are already in reactive mode. Tools like node_exporter with a Prometheus alert rule on `(node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.25` give you enough runway to resize without an incident.
# Step 1: Resize via Vultr API (example: grow to 200 GB)
curl -s -X PATCH "https://api.vultr.com/v2/blocks/${VOLUME_ID}" \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"size_gb": 200}'
# Step 2: Wait ~10 seconds, then verify the block device size
lsblk /dev/vdb
# Step 3a: Grow ext4 filesystem (online, no unmount needed)
resize2fs /dev/vdb
# Step 3b: Grow XFS filesystem (online, use mount point not device)
xfs_growfs /mnt/ecom-postgres
# Confirm
df -h /mnt/ecom-postgresSnapshot Strategy and Backup Automation
Vultr block storage supports snapshots through the API. A snapshot is a point-in-time copy stored on Vultr's infrastructure, billed at $0.05/GB/month of stored data. Snapshots are crash-consistent by default - meaning if you take one while a database is writing, you might capture an inconsistent state. For databases, flush and freeze before snapping.
For PostgreSQL, use `pg_start_backup()` / `pg_stop_backup()` around the snapshot API call (or the newer pg_backup_start() in PostgreSQL 15+). For MySQL/MariaDB, use `FLUSH TABLES WITH READ LOCK` or leverage the Percona XtraBackup hot backup approach instead of filesystem snapshots.
For application data volumes (uploads, logs, static assets), a simple pre-snapshot sync with `sync` and optional filesystem freeze via `fsfreeze` is sufficient.
Automate this. We use a shell script triggered by cron or a systemd timer. For teams that want to build more sophisticated backup pipelines with scheduling, retry logic, and alerting built in, tools like taskbotshub.ai can help you automate multi-step DevOps workflows including pre-snapshot hooks and post-snapshot cleanup without writing a custom Python daemon.
Keep at minimum three daily snapshots and one weekly. The math: a 100 GB volume with 30% change rate costs roughly $1.50/month for three daily snapshots. That is cheap insurance.
#!/bin/bash
# vultr-snapshot.sh - run before this: freeze your app or flush your DB
VOLUME_ID="your-volume-id"
VULTR_API_KEY="your-api-key"
LABEL="auto-$(date +%Y%m%d-%H%M)"
# Optional: freeze filesystem for crash-consistent snapshot
fsfreeze -f /mnt/ecom-postgres
# Create snapshot
SNAP_RESPONSE=$(curl -s -X POST "https://api.vultr.com/v2/blocks/${VOLUME_ID}/snapshots" \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
-d "{\"label\": \"${LABEL}\"}"
)
# Unfreeze filesystem
fsfreeze -u /mnt/ecom-postgres
echo "Snapshot created: $(echo $SNAP_RESPONSE | jq -r '.snapshot.id')"
# Cleanup: delete snapshots older than 3 days
# (implement via API list + date comparison)Detaching, Moving Volumes, and Instance Migration
One of the most practical features of Vultr block storage is the ability to detach a volume from a stopped instance and reattach it to a different instance. This is how you migrate data between instances without copying terabytes over the network.
The workflow: stop writes to the volume, unmount it, detach via API, attach to the target instance, mount on the target. The entire operation for a detach plus reattach takes under 60 seconds in our testing. You do not need to transfer data - the volume physically moves (logically, via network routing) to the new instance.
This is particularly useful for vertical scaling. When you need to upgrade from a 2-vCPU to a 16-vCPU instance because your workload grew, you detach the data volume, destroy the small instance, provision a larger one at Vultr (https://vultr.com/), and attach the existing volume. Your data directory stays intact. We have done this for PostgreSQL primary servers during maintenance windows with under five minutes of total downtime including the pg_ctl stop and start cycle.
Note: the volume must be unmounted before detach. Detaching a mounted volume will cause filesystem corruption. Always unmount first.
# On the source instance: unmount first
umount /mnt/ecom-postgres
# Verify unmounted
grep ecom-postgres /proc/mounts || echo "Clean, not mounted"
# Detach via API
curl -s -X POST "https://api.vultr.com/v2/blocks/${VOLUME_ID}/detach" \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json"
# Wait ~15 seconds, then attach to new instance
NEW_INSTANCE_ID="target-instance-id"
curl -s -X POST "https://api.vultr.com/v2/blocks/${VOLUME_ID}/attach" \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
-d "{\"instance_id\": \"${NEW_INSTANCE_ID}\", \"live\": true}"
# On the target instance: mount it
mount UUID=a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/ecom-postgresPerformance Tuning for Specific Workloads
The defaults are fine for development. Production workloads need attention to three areas: I/O scheduler, readahead, and filesystem journal settings.
I/O scheduler: on NVMe-backed Vultr volumes, the kernel's default `mq-deadline` scheduler is appropriate. If you see `none` (passthrough) on your instance, that is also fine for NVMe - the device itself handles scheduling. Check with `cat /sys/block/vdb/queue/scheduler`. Avoid `cfq` on NVMe; it was designed for rotational drives.
Readahead: the default 128 KB readahead works for sequential workloads. For random-access workloads (PostgreSQL data directory, key-value stores), reduce readahead to 16 KB or even 4 KB. For streaming workloads (log ingestion, sequential reads), increase to 512 KB or 1 MB.
PostgreSQL-specific: do not use Vultr block storage with `synchronous_commit = on` and a slow network path. On our test server with a local-region volume, fsync latency was under 1 ms. Across regions (which you cannot do with block storage anyway), this would be catastrophic. Set `wal_buffers = 64MB` and `checkpoint_completion_target = 0.9` regardless.
For high-write workloads, consider writing PostgreSQL WAL to a separate small Vultr block volume (even a 10 GB volume works). WAL writes are sequential and small; isolating them reduces contention with random reads on the data volume. We saw a 15% reduction in average query latency on pgbench with this separation on our test setup.
# Check current I/O scheduler
cat /sys/block/vdb/queue/scheduler
# Set readahead for random-access workload (PostgreSQL data dir)
blockdev --setra 32 /dev/vdb # 32 sectors = 16 KB
# Set readahead for sequential workload (log/backup volume)
blockdev --setra 1024 /dev/vdb # 1024 sectors = 512 KB
# Persist via udev rule
cat > /etc/udev/rules.d/60-blockdev-readahead.rules << 'EOF'
ACTION=="add|change", KERNEL=="vdb", ATTR{bdi/read_ahead_kb}="16"
EOF
# Benchmark with fio to validate your settings
fio --name=randread-test --ioengine=libaio --iodepth=32 \
--rw=randread --bs=4k --direct=1 --size=4G \
--filename=/mnt/ecom-postgres/fio-test \
--runtime=60 --time_basedShared Storage: NFS on Top of Block Storage
Vultr block storage is single-attach. If you need multiple instances to read and write a shared filesystem - common for stateless app servers sharing uploaded file storage - run NFS on top of a block volume.
The architecture: one dedicated NFS server instance (even a $6/month 1-vCPU Vultr instance handles hundreds of MB/s of NFS throughput for most web workloads), with a block volume attached and exported. App servers mount the NFS share. Keep the NFS server in the same Vultr region and availability zone as your compute instances to minimize latency.
Use NFSv4.1 minimum. NFSv3 lacks proper locking semantics and is a liability in production. On the server, set `rsize=1048576,wsize=1048576` and `async` only if you can accept the risk of data loss on NFS server crash (you usually cannot in production).
For a more robust shared storage solution at scale, consider Vultr Object Storage (S3-compatible) for assets that can tolerate eventual consistency and HTTP access latency, rather than trying to stretch block storage into a shared filesystem role it was not designed for.
# On the NFS server - install and configure
apt install nfs-kernel-server
# Export the block volume mount point
echo "/mnt/shared-assets 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports
exportfs -ra
# On client instances
mount -t nfs4 -o rsize=1048576,wsize=1048576,hard,intr 10.0.0.5:/mnt/shared-assets /mnt/assets
# /etc/fstab entry for persistence
10.0.0.5:/mnt/shared-assets /mnt/assets nfs4 rsize=1048576,wsize=1048576,hard,intr,nofail,_netdev 0 0Monitoring and Alerting on Block Volume Health
Vultr does not send you an alert when a volume is 95% full. That is your job. Set up node_exporter on every instance that mounts a block volume, scrape with Prometheus, and define alerts at 75% and 90% utilization. At 90%, treat it as a P1 incident and resize immediately.
Also monitor inode usage separately. A volume can be 30% full by bytes but 100% full by inodes if you have millions of small files (common with log directories, cache stores, and mail spools). `df -i /mnt/ecom-postgres` shows inode utilization.
For block device errors, watch `dmesg` for I/O errors on the device. A healthy Vultr block volume produces no errors. If you see `blk_update_request: I/O error` in dmesg, open a support ticket immediately - this indicates a problem at the storage layer.
Smartmontools does not work on network-attached block storage (the SMART commands cannot traverse the network layer), so you cannot get drive-level health data. Rely on Vultr's infrastructure monitoring and your application-level metrics instead.
# Check inode usage
df -i /mnt/ecom-postgres
# Watch for block device errors (run periodically or pipe to alerting)
dmesg --since '1 hour ago' | grep -i 'i/o error\|blk_update_request\|EXT4-fs error\|XFS.*error'
# Prometheus alert rule example (alerts.yml)
# groups:
# - name: disk
# rules:
# - alert: DiskSpaceWarning
# expr: (node_filesystem_avail_bytes{mountpoint="/mnt/ecom-postgres"} / node_filesystem_size_bytes) < 0.25
# for: 5m
# labels:
# severity: warning
# - alert: DiskSpaceCritical
# expr: (node_filesystem_avail_bytes{mountpoint="/mnt/ecom-postgres"} / node_filesystem_size_bytes) < 0.10
# for: 1m
# labels:
# severity: critical