Persistent volumes and backups
Use a persistent volume for data that must survive container replacement. A volume keeps files on the server; it does not provide an independent backup.
Add a volume
In the deployment runtime step or Settings → Runtime data, add:
| Field | What to enter |
|---|---|
| Name | A recognizable volume name without secrets |
| Mount path | An absolute path inside the container, such as /app/data |
| Size | A positive size with a supported unit, such as 10GB |
Configure the application to write durable files at that mount path. Mounting over application files can hide the files packaged in the image. Allow for an empty directory on first use and check the application’s expected ownership and permissions.
Saving runtime settings starts a deployment. Applications with volumes stop their previous container before replacement to avoid two processes opening the same data directory.
What persists
Named volumes remain in the pool across application redeployments. Removing a mount or deleting an application does not delete the named volume. This also means unused volumes can continue occupying disk space.
Do not assume a pool change transfers volume contents. Plan and verify the backup and restore into the destination server before moving a stateful workload. Deleting a hosted pool removes its backing storage. Disconnecting a customer-owned server preserves local workloads and data but revokes Infralane management access.
Make an independent backup
Choose a process appropriate for your application:
- use the database’s supported backup or export tool for a database;
- keep backup copies outside the application’s server;
- protect backup credentials and restrict access;
- decide how much data loss and recovery time are acceptable;
- test restoration into a separate environment before relying on a backup.
A provider snapshot can be part of your plan. Check its consistency, retention, storage cost and restoration behavior with the provider. Infralane does not configure automatic application backups for you.
Monitoring history and log downloads are not application-data backups. Keep the data, configuration and credentials needed for recovery in their appropriate protected locations.
Before destructive changes
Verify a usable backup before deleting a pool, changing database versions or removing server storage. A saved file is useful only if you can restore it. See Manage an application for deletion behavior and Server maintenance for disconnection.