A Linux VPS disk becomes usable after you identify the correct device, create or confirm its filesystem, and mount it at a directory. To keep it available after a reboot, add a verified entry to /etc/fstab and test that entry before restarting.
The safe order is important: confirm the provider attached the volume, inspect the Linux device tree and existing data, then decide whether to partition or format. Device names, layouts and provider procedures vary, so do not copy a device name from an example and assume it is yours.
Confirm the provider attached the disk
Start with the VPS provider’s current instructions for attaching block storage. The control panel or command-line procedure is provider-specific, and some providers have additional steps before an attached volume appears in the guest operating system. Do not infer that a disk is ready just because the control panel says it is attached.
After completing the provider’s steps, check what Linux can see. The lsblk command lists block devices and their relationships; requesting explicit columns makes the output easier to interpret:
lsblk -o NAME,SIZE,TYPE,FSTYPE,LABEL,UUID,MOUNTPOINTS
The output should show the device tree, including disks, partitions and mount points. A newly attached volume may not appear immediately. The lsblk manual notes that information supplied through udev can lag behind recently added or changed devices. If the expected volume is missing, follow your distribution’s and provider’s instructions for refreshing device discovery rather than guessing a name or restarting blindly.
If the provider reports a capacity that does not match what Linux shows, pause and resolve that discrepancy first. The same applies if the device appears already mounted, contains a filesystem you did not expect, or has a relationship to the system disk that you cannot explain. A device that is visible is not necessarily empty or safe to format.
Identify the target device safely
Treat device identification as a verification task, not a naming convention. A name such as /dev/sdb may look like a second disk, but enumeration can vary as devices are added or removed. The root filesystem, boot-related devices, swap, existing application storage and newly attached volume may all have plausible-looking names.
Read the TYPE, SIZE and parent-child relationships in lsblk. Trace the device mounted at / to understand which disk or partition backs the operating system. Look for existing mount points and swap use, and compare the candidate’s capacity with the volume you requested. If you cannot confidently distinguish the new data disk from the system disk or another in-use device, stop and consult the provider’s documentation or administrator.
You can also inspect filesystem signatures and identifiers with:
sudo blkid
This provides another view of filesystems and UUIDs. It does not, by itself, prove that a device is disposable: an existing UUID or filesystem can mean the volume already has data worth preserving. Do not run a formatting command as a way to discover what a disk contains.
For a channel operator using a VPS to host a continuous broadcast process, a storage mistake can affect more than the new volume. The guide to choosing a low-cost cloud VM for a prerecorded YouTube stream covers the broader VPS decision; this procedure concerns only the storage Linux has actually been given. Keep separate the question of whether a VPS suits your stream and whether a particular disk is safe to initialise.
Inspect size, filesystem, UUID and mount points
Before making changes, record what the candidate device currently reports. In the lsblk output, inspect SIZE, FSTYPE, LABEL, UUID and MOUNTPOINTS, as well as TYPE and the relationship between a disk and any child partitions. The blkid manual describes identifying block-device content by filesystem type and attributes; use it as supporting evidence alongside the device tree.
An empty-looking filesystem field is not permission to format. It can indicate a blank device, but your decision must also account for provider instructions, expected layout and whether the volume might have been used before. Conversely, a reported filesystem, label, UUID or mount point deserves investigation before you change anything. Confirm whether the volume contains data, whether a filesystem is already present, and whether it is mounted or otherwise in use.
A useful pause point is to write down the candidate’s current device path, capacity, type, filesystem, UUID and mount point. Compare these details with the provider’s volume record and your intended use. If the device is a partition, identify its parent disk; if it is a disk with partitions, identify which child is relevant. This helps prevent confusing a whole-disk target with one of its partitions.
UUIDs are useful later because they identify a filesystem more stably than a kernel name such as /dev/sdX. They are not a substitute for checking the device itself, and copied or cloned filesystems can have duplicate identifiers. If two devices show the same UUID, do not put that identifier into a persistent configuration until you understand why.
Choose a layout and format only after verification
There is no universal requirement to create a partition before using a data disk. For a simple single-purpose volume, an administrator may put a filesystem directly on the whole block device, or create a partition and put the filesystem there. The right choice depends on the observed layout, provider or organisational policy, whether multiple partitions are needed, and any cross-platform requirements. Match the command to the target you have deliberately chosen.
Formatting writes a filesystem to the named device or partition and can destroy existing data. Preserve anything needed and verify the exact target once more immediately before running mkfs. The mkfs manual describes the target as usually a disk partition while allowing a block device; the live device layout, not an example on a web page, determines what to use.
For a newly created partition that you have confirmed should use ext4, the command form is:
sudo mkfs.ext4 /dev/CONFIRMED_PARTITION
Replace the placeholder with the partition you verified. If your deliberate layout uses a filesystem on the whole device, use that confirmed device instead. Do not run either form unchanged, and do not treat /dev/CONFIRMED_PARTITION as a real path. The filesystem-specific mkfs.ext4 utility is preferable to an unqualified generic mkfs command when ext4 is the intended choice.
Ext4 is a general-purpose Linux filesystem and can be a reasonable default for a straightforward Linux-only data volume. It is not automatically the right choice for every workload. Provider requirements, compatibility with other operating systems, existing data, workload and the filesystem your team knows how to administer may all point elsewhere. Check the provider’s current guidance and the distribution’s filesystem documentation before deciding. The ext4 manual describes the filesystem’s scope; it is not a universal recommendation for every VPS volume.
If the device already has a filesystem you intend to keep, do not format it. Identify the existing filesystem type and use the appropriate mounting and recovery guidance. If you are unsure whether the data is needed, stop before any destructive operation and arrange a backup or ask the person responsible for the volume.
Create a mount point
Linux makes a filesystem available by attaching it to a directory in the unified file tree. Choose a path that reflects the volume’s purpose and does not conflict with the application’s existing directories. A common illustrative path is /mnt/data, but the name is yours to choose and does not imply anything about the device.
Create the directory if it does not already exist:
sudo mkdir -p /mnt/data
Check the directory before mounting. If it already contains files, understand why and decide whether those files should remain visible beneath the mounted filesystem. A mount overlays the directory’s view while mounted; it does not merge the directory’s old contents into the new volume. Plan a clean target path or move and back up existing contents deliberately.
Once you have confirmed the intended device or partition and filesystem, mount it for immediate use. The form below uses a placeholder on purpose:
sudo mount /dev/CONFIRMED_DEVICE /mnt/data
findmnt /mnt/data
Replace the device placeholder with the verified filesystem-bearing device. The mount manual explains how a filesystem is attached at a target directory. After mounting, findmnt should report the source and filesystem at the path you selected. If it reports something unexpected or fails, do not proceed to configure boot-time mounting until you have resolved the problem.
Check available space and confirm the application can access the intended path before putting data there. For example, if the volume is meant to hold media or logs for a continuous stream, verify that the relevant process will write to the mounted path rather than to the root filesystem. A successful mount command is not enough if your application is still configured to use a different directory.
Configure a persistent mount
A manual mount command generally addresses the current session; it does not, by itself, tell Linux to mount the volume at every boot. The usual configuration is an entry in /etc/fstab. Read the existing file first and preserve its current entries. A typo or wrong source can cause boot-time delays or recovery work, so treat this as a configuration change to review rather than a line to paste without checking.
After formatting, retrieve the new filesystem’s UUID using lsblk --fs or sudo blkid. Confirm that the UUID belongs to the filesystem you intend to mount, not the root volume or another disk. A typical illustrative ext4 data-volume entry is:
UUID=REPLACE_WITH_REAL_UUID /mnt/data ext4 defaults 0 2
This shows the fields in a familiar form: source, mount point, filesystem type, options, dump field and filesystem-check pass field. Replace the UUID placeholder with the actual verified identifier, and change the path, type or options to match your system. The fstab format and supported options can vary with distribution and system tooling; consult the host’s manual and provider guidance for special volumes or non-default requirements.
Using UUID= or, where appropriate, a verified LABEL= avoids tying the entry to an enumeration name that can change when storage devices are added or removed. The fstab manual documents the configuration format and recommends tags such as UUID or LABEL for device identification. Check that the chosen identifier is unique in the system, especially if a filesystem was copied or cloned.
Before editing, make a copy of the current file or use your normal configuration-management procedure. Add one entry, then inspect the result carefully for spacing, spelling, path, filesystem type and options. Do not delete unrelated system entries to make room. If you use an editor, save a backup you can restore through your provider’s console or recovery process if needed.
For volumes that might not be present at every boot, do not guess at special options. Whether an unavailable device delays or interrupts boot can depend on the distribution, systemd and util-linux versions, and provider setup. Read the distribution’s documentation for optional or network-backed devices, and confirm the provider’s expected behaviour before relying on a customised entry.
Verify the mount and reboot behaviour
Test the configuration before rebooting. After saving /etc/fstab, run:
sudo mount -a
findmnt /mnt/data
lsblk -f
mount -a asks the system to process eligible entries from the file. If it reports an error, correct the entry before restarting. Check the source, filesystem and target path with findmnt, then inspect lsblk -f to see the filesystem association and mount point. Do not assume a quiet command means the correct disk was selected; verify the reported source.
Test that the application can read and write where intended, using a safe test file if appropriate, and remove that file when finished. Check available capacity and permissions as the application’s user, not only as root. A filesystem can be mounted correctly while the service still lacks permission to create files there.
Only after the entry passes validation should you plan a reboot test. Make sure you have a way to reach the VPS if it does not return as expected, such as the provider’s console or documented recovery path. Following reboot, inspect findmnt and lsblk -f again and confirm the expected filesystem is attached at the intended directory. If the volume is absent, investigate provider attachment and boot-time logs instead of repeatedly editing the fstab line at random.
If you later remove or replace the volume, update the persistent configuration deliberately. An obsolete entry can create boot friction or leave an application pointing at an empty underlying directory. The same care applies when changing a UUID, filesystem, mount point or disk layout: update one part at a time, validate, then reboot only when the host’s state is understood.
Common mistakes and a cautious checklist
The most serious mistake is formatting the system disk or a data volume that still matters. Identify the root and boot devices from mounted paths and the device tree, compare size and provider records, inspect filesystem signatures, and stop if any fact is ambiguous. Never use the apparent sequence of /dev/sdX names as proof of which disk is new.
Another common error is confusing the whole disk with a partition. lsblk shows parent-child relationships and TYPE; use those details to choose whether the intended filesystem belongs on the disk or a child partition. Formatting the wrong level can discard a layout you meant to retain or leave the system unable to find the filesystem you created.
A mount point can also mislead. Files already in its directory are hidden from view while another filesystem is mounted there, then become visible again when it is unmounted. If the directory has existing contents, move or preserve them consciously before using it for a volume.
Before finishing, confirm each point: the provider’s attachment procedure is complete; Linux sees the expected capacity; you know whether the candidate is a disk or partition; its current filesystem, UUID and mount points make sense; any destructive step targets only the confirmed volume; the selected mount point is suitable; the fstab source uses the correct stable identifier; and mount -a succeeds before reboot. For a channel whose broadcast process must keep running, storage is only one part of operational planning; the automatic restart guide for a YouTube bhajan stream discusses recovery of the stream process, not disk setup.
If the disk is being added to a VPS that will hold a prerecorded broadcast file, keep the media workflow separate from Linux storage administration. The guide to streaming a product training video playlist continuously on YouTube Live covers the broadcast use case; it does not change the verification steps required before mounting a volume.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is a partition required before I format a VPS disk?
Not in every case. A filesystem can be created on a whole block device or on a partition, depending on the intended layout and provider or organisational policy. Inspect the live device tree and choose deliberately rather than applying a universal /dev/...1 example.
Is ext4 always the right filesystem?
No. It is a reasonable general-purpose choice for many Linux-only data volumes, but workload, provider requirements, interoperability and operational familiarity can change the decision. Check current provider and distribution guidance for your volume.
Why use a UUID instead of /dev/sdX in /etc/fstab?
Kernel device names can change as devices are enumerated, whereas UUIDs identify filesystems more consistently. Verify that the UUID belongs to the intended filesystem and is not duplicated before using it in a persistent entry.
Can I reboot as soon as I add the fstab line?
Test the entry first with sudo mount -a, then inspect the mounted source and target with findmnt. If validation fails, fix it before rebooting, and make sure you have a provider-supported recovery route for the VPS.