Skip to content

Persistent Storage

Nexaa's Persistent Storage allows containers to store data reliably and durably across restarts, updates, and failures. Unlike ephemeral storage, which is wiped out when a container stops, persistent storage ensures data is retained until you explicitly delete it. This makes it ideal for applications that need to preserve logs, configuration, or user data.

Use Cases

Persistent storage is well suited for scenarios where data durability is critical:

  • Application Logs
    Store logs persistently to enable analysis, auditing, or long-term debugging.

  • Critical User or System Data
    Retain uploaded files, configuration files, user-generated content, or stateful data across deployments.

  • Backups and Snapshots
    Use as a target for automated backups, export processes, or application snapshots.

  • Queue or Message Broker State
    Prevent message loss during container restarts or failures by storing the message queue on disk.

  • Data Extraction Pipelines
    Retain intermediate or output files from batch jobs and ETL pipelines for later use.

Key Characteristics

  • Durable
    Data persists beyond container lifecycle events, including restarts and updates.

  • Manually Managed
    You control when volumes are created, mounted, or deleted.

  • Namespace Scoped
    Volumes are scoped per namespace and can be mounted by multiple containers within that scope.

  • Mount Path Defined
    You can choose where the volume is mounted inside the container filesystem.

  • Scalable
    Storage capacity can be increased as needed.

Underlying Technology

Persistent storage in Nexaa is powered by NFS (Network File System). Volumes behave like traditional shared file systems — supporting read/write operations, file overwrites, and multi-container mounts.

  • Files deleted or overwritten cannot be recovered.
  • File operations are atomic but not transactional.
  • A lost+found folder may appear inside volumes — this is used by the filesystem for data recovery operations.

Execution Behaviour

  • Mounting
    When you mount a volume to a container, the target directory will be replaced. If the container previously had content at that path, it will be lost.

  • Lifecycle Independence
    Volumes are independent of container lifecycle — they are retained even after a container is removed.

  • Single or Multiple Mounts
    You can mount the same volume to one or more containers within the same namespace.

  • Size Increases Only
    Volume size can be increased but never decreased to prevent unintentional data loss.

Best Practices

  • Use One Volume Per Namespace
    Avoid sharing volumes across unrelated services to minimize coupling and complexity.

  • Choose Logical Mount Paths
    Avoid mounting to paths already used by your application unless intentionally designed.

  • Avoid Mounting to Root Folders
    Mounting over critical paths like /app can lead to container crashes.

  • Separate Persistent and Ephemeral Data
    Don't rely on container-local storage for important data — always use volumes for durability.

FAQs

Q: What happens if I mount over an existing folder like /app?
A: The contents of /app will be replaced by the volume, which may break your app. Always use a dedicated mount path.

Q: Can I reduce the size of a volume?
A: No. You can only increase volume size to prevent accidental data loss.

Q: Is my volume deleted when I remove the container?
A: No. The volume is preserved independently and can be reused or deleted manually.

Q: What is the lost+found folder in my volume?
A: It's a system folder created by the filesystem to store recovered data in case of corruption. It can safely be ignored.

Q: Can I make automated backups of the volume? A: No, data is stored and replicated over different nodes but if you need a periodically backup you can use a Container Job to store the date on a different location.

What's Next