A cloud server’s disk can be larger at the provider level while the operating system still sees the old usable space. To expand storage for a 24/7 stream, identify what is full or constrained, make a recoverable backup, enlarge the correct managed disk, and then verify whether the guest operating system needs a rescan and filesystem change.
Adding capacity is not the same as improving performance, and the exact procedure depends on your provider, disk, operating system and filesystem. Plan for a maintenance window where possible: some provider-side expansions can happen while a VM runs, but that does not guarantee an uninterrupted stream during every guest-side change.
Find the actual storage bottleneck
Start by distinguishing capacity from performance. A full filesystem can prevent a process from writing a recording, cache or log. But a filesystem with free space may still be backed by storage that cannot meet the workload’s throughput, IOPS or latency needs. Resizing is useful for the first problem; it may not solve the second.
On Linux, df -h is a quick way to inspect mounted filesystems, their available space and their mount points. It does not by itself tell you the provider-side size of each disk or whether the workload is waiting on storage. Compare its output with the attached-disk list and the provider’s storage metrics. On Windows, inspect the relevant volume in Disk Management and compare it with the managed disk shown in the cloud console.
Trace what the stream actually stores. Does it write a growing local recording, temporary segments, application logs or a cache? Does it read media from the same disk, or from another storage service? A media loop that only reads a fixed file has a different capacity pattern from a process that continually saves output. Do not assume a particular streaming method or a particular storage requirement from the fact that the channel runs continuously.
Look at the trend, not just a single reading. If the free space steadily falls, identify which directory or application is responsible before expanding anything. If it stays stable but storage metrics show sustained pressure, capacity may not be the problem. You may need a different performance tier or a change in how media is stored. The Google Cloud guide to troubleshooting a full disk is one provider’s reference for checking space and diagnosing disk-full problems; use your own provider’s instructions for its environment.
Identify the managed disk and storage model
Record the provider, VM name, disk name, disk type, region or zone, current size, and whether the disk is a boot disk or a data disk. Also note the operating system, partition layout and filesystem. These details matter: a cloud provider manages the virtual disk, but the guest OS manages partitions and filesystems on it. Enlarging the former does not always enlarge the latter.
Check what kind of storage the application expects. Block storage looks like a disk to the operating system and is often suitable for a VM’s local filesystem. File storage presents shared files through supported protocols, which can help when several machines need common files. Object storage is generally accessed through an API or client rather than treated as an ordinary mounted block disk. Moving between these models can involve application changes; it is not merely a larger-volume setting.
Durability also matters. Temporary or ephemeral storage can be useful for scratch files or a cache that can be rebuilt, but should not hold the only copy of media or data that must survive a VM stop, restart or failure. Google Cloud, for example, describes Local SSD as temporary storage, while its durable disk products are documented separately. Check the lifecycle and recovery behaviour of the specific product you use.
If the requirement is shared access, an archive, or long-term media retention, first ask whether a larger VM-attached disk is the right tool. Google’s storage options guide explains the differences among block, file and object storage in its own product context. Those distinctions are useful when framing the decision, but your provider’s available services, compatibility and terms will differ.
For a practical example, a small devotional channel might keep its current playlist on durable attached storage while writing temporary logs elsewhere. If the playlist is read-only and the disk has ample free space, increasing disk size will not fix a bitrate or network problem. A useful companion when reviewing broader operating costs is the guide to running a continuous stream on a rented Indian VPS.
Prepare a recovery path first
Before changing a partition or filesystem, take a snapshot or another recoverable backup and confirm that you know how you would restore it. A snapshot is not a substitute for understanding recovery: check that it completed, that it covers the right disk, and that you can access the restore procedure. If the data is important, retain a separate copy or follow your organisation’s backup policy as well.
This step belongs before the guest-side changes, not after them. A mistaken device name, unsupported layout or interrupted operation can leave a volume unavailable. The precise risks and recovery features vary by provider and filesystem, so use the provider’s current documentation and your operating system’s documentation rather than copying commands from a different setup.
Review the current disk configuration and save relevant details: device name, partition numbers, filesystem type, mount point and any volume-manager arrangement. Make sure you are not about to resize the wrong disk. If the stream is business-critical, schedule the work when an interruption is acceptable and arrange a way to check the broadcast independently. A provider-side resize that is supported online does not prove every later step is safe to perform without impact.
There may also be a cost and reversibility consideration. Some providers do not support shrinking a disk after expansion, so choosing a larger size can become a lasting commitment. Google Cloud states in its Persistent Disk resizing guidance that a disk cannot be reduced in size. Check the equivalent rule for your product, and confirm current billing in your account before proceeding.
Expand the provider-managed disk
Once the disk and recovery plan are clear, use the provider’s console, command-line interface, API or infrastructure-as-code workflow to increase the capacity of the identified disk. Follow the current procedure for that product and its attachment state. Do not substitute a command written for another cloud, disk type or operating system.
Before applying a target size, check the provider’s limits for the disk and VM, including attachment limits and compatibility with the selected storage type. Decide how much headroom you need based on observed growth and a reasonable review interval, rather than guessing at a universal amount. Leave room to reconsider future retention, but avoid buying capacity that the workload does not need. Check whether performance is linked to capacity for your disk type, or can be configured separately; the answer is provider- and product-specific.
If the provider reports a successful expansion, treat that as confirmation only of the managed-disk layer. It does not confirm that the guest OS can use the extra area. Keep the operation record and note the before-and-after capacity so you can compare provider state with the guest later.
A real example of why instructions must be scoped: Microsoft’s Azure Windows VM disk expansion guide covers Azure Windows scenarios and distinguishes managed-disk expansion from growing a Windows volume. Its rules should not be assumed to apply to Linux, other Azure disk products or another provider. Check the relevant guide for your own combination of OS and disk.
Rescan and inspect the guest operating system
After provider-side expansion, inspect the guest to see whether it recognises the new device size. Some combinations update automatically; others need a rescan or a refresh in the operating system. The process differs across Linux distributions, Windows versions, virtualisation drivers and storage arrangements, so use the appropriate official documentation.
On Linux, first identify the block device and its current size with tools appropriate to the distribution, then compare it with the provider’s reported size. Do not guess the device name: names such as /dev/sda or /dev/nvme0n1 are examples only and can refer to different disks on different machines. If the guest still sees the old size, consult the provider’s rescan instructions before changing partitions.
On Windows, refresh the disk view and confirm the managed disk’s increased capacity is visible before extending a volume. If the volume is not eligible for extension, investigate the partition layout and any intervening recovery or system partitions. Do not delete partitions simply because a guide on another machine shows a different layout.
At this point, if the device size is still unchanged, pause. Recheck that the correct disk was expanded, that the VM is attached to it, and that the provider operation completed. Escalate to the provider’s support or documentation if the state remains inconsistent. Continuing with guessed partition commands can make recovery harder.
Extend the partition and filesystem carefully
A larger device does not always mean a larger partition or filesystem. The guest may have a partition occupying only the original disk size, or the filesystem may need a separate growth operation. A volume manager or storage pool adds another layer. Determine the actual layout before selecting a procedure.
Check the partition table type, whether the disk is boot or data storage, and the filesystem. Confirm whether the filesystem supports online growth and what the operating system requires. If the volume is managed by LVM, Storage Spaces or another pooling layer, follow that technology’s steps as well as the provider’s. Google Cloud notes that most boot disks resize their root filesystem automatically in common configurations, while some images and data disks require manual steps; that is a Google-specific behaviour, not a general rule.
Use a procedure written for the exact platform and layout. If it requires an unmount, reboot or other service interruption, plan that explicitly. If the disk is in a clustered or shared-storage arrangement, stop and confirm how the topology handles a resized underlying device. Google warns that Storage Spaces Direct does not recognise added space from resizing underlying Persistent Disks and that data may become inaccessible; its guidance is to add servers or drives instead. This illustrates why a simple resize recipe cannot be safely applied to every storage stack.
Do not improvise with destructive partition edits. Verify device identity and backup status immediately before the change. If you are not comfortable identifying the partition and filesystem, ask a qualified administrator or the provider’s support to review the plan. This is particularly important for a boot disk or a volume containing the only copy of the media used by the channel.
The operating system should report the expected filesystem size only after the necessary layers have been expanded. If the provider disk is larger but the filesystem is not, the job is not complete. Conversely, if the filesystem grew but reports errors or unexpected free space, stop and investigate rather than assuming the stream will tolerate it.
Verify usable space and monitor the stream
Verify at both layers. In the provider console or API, confirm that the managed disk has the intended size. In the guest, confirm that the relevant filesystem or volume has the expected total capacity and that usable free space is available at the actual mount point used by the streaming application. Compare with your pre-change notes.
Then test the workload’s own path. Check that the media file can be read, that any recording or cache can be written, and that logs are not reporting disk errors. Observe storage utilisation and performance metrics after the change. If the stream is live, confirm its status in the operating system and in YouTube Studio; a larger disk alone does not verify that the encoder, network or YouTube ingest is healthy. For background on stream settings rather than storage, see how to change the stream key in an FFmpeg command and replacing video in a continuous YouTube nature stream.
If free space is now sufficient but dropped frames or buffering continue, investigate the actual symptom. Network capacity, CPU load, encoding settings and disk throughput can each constrain a stream. Added capacity does not automatically increase IOPS or throughput, and a disk with more free space can still be too slow for simultaneous reads and writes. Google Cloud’s documentation distinguishes storage performance characteristics by product; confirm the limits and options for the disk and VM you actually use.
Keep watching the free-space trend after the change. Note how quickly the volume fills under normal operation and set an alert before it reaches a level that threatens writes. Also review retention: recordings and logs may be accumulating because no cleanup or archive policy exists. A one-time resize can delay the next full-disk event without addressing its cause.
If the need turns out to be a different storage model, treat that as a separate design change. For example, a shared media library for several machines may call for managed file storage, while long-retention archives may fit object storage if the application can access objects through the supported interface. Check recovery, access patterns, recurring cost and compatibility before migrating. Do not treat a move to another storage type as a routine partition expansion.
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
Can I expand cloud storage without taking my stream offline?
It depends on the provider, disk type, operating system and filesystem. A provider may allow its disk-size change while the VM is running, but guest-side rescanning or partition work can have separate conditions. Do not assume zero downtime; check the exact procedure and plan a maintenance window if an interruption would matter.
Why does the operating system still show the old size?
The provider-managed disk and the guest filesystem are separate layers. The guest may need to rescan the device and then extend a partition, volume manager or filesystem. Verify the device identity and follow instructions for your OS and layout rather than running a command copied from another setup.
Will a larger disk make the stream perform better?
Not necessarily. More capacity helps when the problem is insufficient space, but throughput, IOPS and latency are separate considerations and depend on the storage product and VM. Compare the workload’s measured symptoms with the provider’s performance options before resizing for speed.
Should I use temporary storage for stream media?
Use temporary storage only for data you can afford to regenerate or lose, such as a rebuildable cache. If the media or recordings must survive a VM stop, restart or failure, use an appropriately durable storage option and keep a recovery plan. Check the lifecycle behaviour of the specific product you select.