# How do I mount and format the storage disk on a Linux storage VPS? > How to mount and format the storage disk on a Linux VPS: lsblk, GPT, ext4 or XFS, optional LUKS, fstab by UUID with nofail. 1 TB $1.66/month, crypto, no ID. - URL: https://coffervale.com/mount-storage-disk-on-a-vps/ - Last updated: 2026-11-02 - Publisher: Coffervale (https://coffervale.com) Find the empty disk, give it one partition and a filesystem, encrypt it if you want, and mount it so a missing disk can never hang the boot. Ten commands, each explained, with the one mistake that wipes the wrong disk called out. **Quick answer — How do I mount and format the storage disk on a Linux VPS?** To mount and format the storage disk on a Linux VPS, find it with `lsblk`, create one GPT partition, format it ext4 or XFS, optionally inside LUKS, and mount it from `/etc/fstab` by UUID with `nofail`, so a missing disk never blocks boot. The steps apply to any KVM storage VPS, including **Coffervale** plans from 1 TB at $1.66 a month on 12 months (2 November 2026). ## What are the steps? 1. **Identify the empty disk** — lsblk shows every disk; the storage disk has no partitions and no mount point. 2. **Create one GPT partition** — parted writes a GPT label and one partition across the whole disk. 3. **Encrypt it (optional)** — cryptsetup luksFormat and cryptsetup open, then back up the LUKS header off the server. 4. **Make a filesystem** — mkfs.ext4 -m 1 or mkfs.xfs, with a label you will recognise. 5. **Mount it by UUID with nofail** — One line in /etc/fstab, then mount and findmnt to confirm. ## Which disk is the storage disk? **Run `lsblk`: the storage disk is the large one with no partitions, no filesystem and no mount point.** Storage VPS come in two layouts, a small system disk plus a large data disk, or a single large disk. According to Coffervale's survey of 2 November 2026, 6 of the 18 storage VPS sellers that take crypto without an ID document state on their pages that the storage arrives as a separate disk or block device; the other 12 describe one disk or do not say. Check yours before typing anything destructive. On KVM, virtio disks are named `vda`, `vdb` and so on, and virtio-SCSI disks `sda`, `sdb`. Sizes are shown in binary units, so a 1 TB disk reads as about 931G. If `lsblk` lists only one disk and `/` already spans its full size, there is nothing to format: create a folder such as `/srv/data` and skip to the section on encryption choices at the end. *List disks, then name the empty one* ```bash lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS # Use the empty disk from the list above; this example assumes /dev/vdb DISK=/dev/vdb PART=/dev/vdb1 ``` > **The one mistake to avoid** parted, mkfs and luksFormat erase whatever device you name. Before running them, confirm in the lsblk output that $DISK has no FSTYPE and no MOUNTPOINTS. The system disk always has / mounted somewhere on it. ## Should I partition the storage disk or format it whole? **Create one GPT partition across the disk.** A filesystem written straight onto the bare device works too, but a partition table tells every tool and every admin who looks later that the disk is in use, and `parted` aligns the partition for you. Debian and Ubuntu cloud images do not always ship `parted`, so install it first (`dnf install parted` on AlmaLinux or Rocky Linux, and the same for `cryptsetup` below). *One partition across the whole disk, as root* ```bash apt install parted parted -s -a optimal "$DISK" mklabel gpt mkpart data 0% 100% partprobe "$DISK" lsblk "$DISK" ``` ## Should I encrypt the storage disk with LUKS? **Encrypt it if anything on the VPS will keep plain files: run `cryptsetup luksFormat` on the partition, open it under a name, and build the filesystem on the opened device.** LUKS2 is the default format. Keep the system disk unencrypted and the data disk under LUKS: after a reboot, log in over SSH and unlock the data disk with your passphrase. Whoever runs a hypervisor can technically read an unencrypted virtual disk, at any VPS host. We do not open your files, and data you encrypt before it leaves your machine takes the question off the table. Back up the LUKS header and move the copy off the server: if the header is damaged, the data behind it is gone. The cryptsetup manual adds a warning worth reading twice: a header backup plus a passphrase that was valid when you took it decrypts the disk even after that passphrase is changed or removed. Treat the backup file like the passphrase itself. *LUKS on the partition (skip this block for an unencrypted disk)* ```bash apt install cryptsetup cryptsetup luksFormat "$PART" cryptsetup open "$PART" coffer cryptsetup luksHeaderBackup "$PART" --header-backup-file /root/coffer-luks-header.img # copy /root/coffer-luks-header.img to your own machine, then delete it here ``` ## Should the storage disk use ext4 or XFS? **Use ext4 unless you have a reason not to; it is the only one of the two you can shrink.** Both handle multi-terabyte backup repositories and file sync without trouble, and both grow while mounted when a disk gets larger. The differences that matter on a storage VPS: | Property | ext4 | XFS | | --- | --- | --- | | Grow while mounted | Yes, `resize2fs` | Yes, `xfs_growfs` (must be mounted) | | Shrink | Yes, unmounted, with `resize2fs` | Barely: only the last allocation group shrinks, and it cannot be removed | | Space held back for root | 5% by default; `-m 1` keeps 1% | No such reserve | | Label length | Up to 16 bytes | Up to 12 characters | On a 1 TB data disk, the default ext4 reserve holds back 50 GB that only root can use. For a disk that stores backups or sync data, 1% is plenty, since the operating system does not live there. Format the partition, or the opened LUKS device if you encrypted it: *Format: pick one line* ```bash # The device to format: the partition, or the opened LUKS device DEV="$PART" # with LUKS: DEV=/dev/mapper/coffer mkfs.ext4 -m 1 -L coffer "$DEV" # or: mkfs.xfs -L coffer "$DEV" ``` ## How do I mount the disk at boot with fstab, UUID and nofail? **Add one `/etc/fstab` line that names the filesystem by UUID and carries `nofail`.** The fstab manual recommends UUIDs or labels because device names follow the order in which disks are detected and can change when disks are added or removed. With `nofail`, systemd's documentation says the boot continues without waiting for the mount and whether or not it succeeds, so a detached or locked disk cannot leave a remote server stuck at an emergency prompt you cannot reach. An encrypted disk gets `noauto` as well: it cannot be mounted before you unlock it over SSH, so the boot should not try. The small script below opens it by the LUKS UUID and mounts it in one step. *Plain ext4: mounted at every boot* ```bash mkdir -p /srv/data UUID=$(blkid -s UUID -o value "$PART") echo "UUID=$UUID /srv/data ext4 defaults,nofail 0 2" >> /etc/fstab systemctl daemon-reload mount /srv/data findmnt /srv/data ``` *LUKS: mounted after you unlock it* ```bash mkdir -p /srv/data FSUUID=$(blkid -s UUID -o value /dev/mapper/coffer) LUKSUUID=$(blkid -s UUID -o value "$PART") echo "UUID=$FSUUID /srv/data ext4 noauto,nofail 0 0" >> /etc/fstab systemctl daemon-reload cat > /usr/local/sbin/unlock-data <