> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/backup-and-storage/network-file-storage/usecases.md).

# Use Cases

Network File Storage (NFS) use cases explained: shared configuration, media serving, backup, log aggregation, and Kubernetes storage on IONOS CLOUD

The guide covers real-world scenarios where <code class="expression">space.vars.ionos\_cloud</code> Network File Storage (NFS) provides shared, durable storage for [<mark style="color:blue;">Virtual Machines (VMs)</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#virtual-machine-vm), from centralized configuration management to high-throughput content delivery and Kubernetes persistent storage. Each scenario describes a problem that per-VM local storage cannot solve efficiently, and how NFS addresses it with centralized, POSIX-compliant shared access.

## Scenario 1: Shared configuration and static assets

### Problem

Fleets of VMs running the same application need identical configuration files, templates, and static assets. Distributing updates to each VM's local disk individually risks configuration drift and requires redeploying or syncing files across every instance whenever a change is made.

### Solution

Mount an NFS share on every VM in the VDC and store shared configuration files, templates, and static assets in one place. Fine-grained POSIX permissions at the file and directory level control which VMs and users can read or write specific paths, and updates are visible to every mounted VM immediately, without redistribution.

## Scenario 2: Media serving and content delivery

### Problem

Serving images, video, and other media from multiple servers usually means duplicating the media library on every instance's local disk, which wastes storage and creates version-consistency problems as the library grows.

### Solution

Store the media library once on an NFS cluster and mount it as a shared origin across all serving VMs. Clusters scale from 2 TiB to 42 TiB with throughput that scales linearly with provisioned capacity, and [<mark style="color:blue;">NIC Multi-Queue</mark>](/cloud/network-services/vdc-networking/nic-multi-queue.md), activated by default on the cluster, distributes network traffic across multiple queues to help sustain throughput under concurrent read load from many clients.

## Scenario 3: Backup target and archival

### Problem

Backing up databases, application data, and VM snapshots requires a durable, encrypted destination that is decoupled from the source VM, so that a single instance failure does not put the backups themselves at risk.

### Solution

Use an NFS cluster as a centralized backup destination. Data is encrypted at rest by default, and the cluster runs across two servers with automatic failover and RAID, so backup data remains available independent of any single compute instance's lifecycle.

## Scenario 4: Centralized log aggregation

### Problem

Collecting logs from many VMs into one place for analysis typically means standing up a separate log-shipping pipeline to external storage, adding operational overhead before the data can even be queried in one location.

### Solution

Mount a shared NFS volume across VMs and have each instance write logs directly to a shared directory for centralized retention and analysis. NIC Multi-Queue, activated by default on the cluster, helps sustain throughput as multiple VMs write concurrently.

## Scenario 5: Kubernetes ReadWriteMany persistent volumes

### Problem

Containerized workloads where multiple pods must read and write the same files, such as shared caches or collaborative processing pipelines, cannot use volumes that support only a single writer at a time.

### Solution

Provision an NFS share as a ReadWriteMany (RWX) persistent volume for your Kubernetes cluster. Multiple pods across nodes mount the same share simultaneously, with POSIX access control governing which workloads can read or write specific paths.

## Scenario 6: High-concurrency multi-client access

### Problem

A fleet of many VMs, for example, a CI/CD worker pool or a batch-processing farm, mounts the same share simultaneously to read and write shared inputs and outputs. As the number of concurrently connected clients grows, network traffic funneled through a single queue can become a throughput bottleneck.

### Solution

[<mark style="color:blue;">NIC Multi-Queue</mark>](/cloud/network-services/vdc-networking/nic-multi-queue.md) is activated by default on any NFS cluster with at least two CPU threads (two cores, or one core with hyperthreading), distributing network traffic across multiple queues based on available CPU cores. No configuration is required, and the feature delivers a throughput improvement of approximately 10% at two cores, helping sustain throughput as concurrent client load increases.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ionos.com/cloud/backup-and-storage/network-file-storage/usecases.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.