Persistent Volumes and Snapshots on Dockup

Persistent volumes and snapshots solve two different problems. A volume keeps files across container replacement and deployment. A snapshot captures the volume at a point in time so operators can inspect, retain, or restore that state later.

The container filesystem is replaceable. Anything that must survive a deploy—uploads, generated media, indexes, package artifacts, or application-managed files—needs an explicit persistent location.

Which application data belongs on persistent storage?

Use a volume when the application owns files that cannot be recreated cheaply or safely from another source.

Data	Volume?	Better alternative when available
User uploads	Yes	Object storage if the architecture uses it
Generated thumbnails	Maybe	Regenerate from originals
Search index	Maybe	Rebuild from the source database
Build artifacts	Usually no	Rebuild during deployment
Application logs	Usually no	Runtime log system
PostgreSQL data directory	Not as an app volume	Managed PostgreSQL
Temporary cache	No	Redis or ephemeral storage
Local SQLite production DB	Risky	Managed database for concurrency and backups

A volume should have one clear owner and mount path. Two unrelated processes writing the same directory make recovery and permission analysis harder.

Before adding storage, estimate the initial size, growth rate, retention requirements, and recovery objective. Disk is measured against the plan balance per minute, so unused capacity and uncontrolled file growth have a cost.

How do you create and inspect a Dockup volume?

List existing volumes for the exact service:

dockup volume list production/web --json

Add a volume with a name, absolute container path, and size in gigabytes:

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

The application must write to /app/uploads. Writing to /uploads or another local directory does not magically redirect into the mount.

After deployment, verify that the application is writing to the declared absolute mount path rather than the replaceable container filesystem.

Inspect actual disk use with the returned volume ID:

dockup volume usage <volumeId> production/web --json

Compare real use with the allocated size and application metrics. Alert before the filesystem is full; a full volume can cause partial writes, failed uploads, or application crashes.

Review file ownership expectations. The container’s runtime user must be able to read and write the mount path without granting broader permissions than required.

How do volume snapshots protect data?

An on-demand snapshot captures the volume contents:

dockup volume snapshot <volumeId> production/web --json

List available snapshots:

dockup volume snapshots <volumeId> production/web --json

Snapshots read the volume in a read-only manner and do not require the application to write into a special snapshot directory. They are useful before a risky file migration, bulk media rewrite, or application change that transforms stored data.

A volume snapshot is not automatically application-consistent. If the application is actively writing several related files, the snapshot can capture them at slightly different points. For a managed database, use the managed database backup system rather than snapshotting its raw data directory.

Define when the application should be quiesced. A short maintenance or write pause may be appropriate before a high-value snapshot. Record the snapshot ID, reason, and expected restore point.

How should snapshot retention be planned?

Choose snapshot timing and retention from the recovery requirement rather than habit. Create an on-demand snapshot before every risky file migration, cleanup, or format change, and record the returned snapshot ID.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Recovery need	Snapshot practice	Limitation
Undo a file migration	Snapshot immediately before the change	Does not include later writes
Preserve historical points	Keep labeled recovery points under policy	Retention needs active review
Protect frequent writes	Add application-level backup appropriate to the data	A point-in-time snapshot is not continuous protection
Regulatory archive	Use a dedicated archive workflow	Operational snapshots may not meet policy

Review whether expected snapshots actually exist. A written retention policy is not evidence that a usable restore point was created.

How do you restore a volume snapshot safely?

A restore replaces the current volume contents and restarts the container:

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

This is a disruptive, state-changing operation. Before restoring:

1. Confirm the exact service, volume ID, and snapshot ID.
2. Explain which current files will be replaced.
3. Stop or limit new writes where possible.
4. Take a fresh snapshot of the current state when it may be needed.
5. Record application and schema compatibility.
6. Obtain explicit production approval.
7. Plan post-restore verification.

After restore, verify the container state and application behavior:

dockup status production/web --json
dockup logs production/web --json

Test representative files, permissions, indexes, and application references. A successful restore command proves that the snapshot was applied; it does not prove that every application record points to a valid file.

The AI agent production guardrails model should treat restore as approval-gated even though it is a recovery operation.

How should volumes behave during deployment and rollback?

A deployment replaces application containers while the mounted volume remains. This allows a new image to see existing files, but it creates a compatibility obligation.

A new application version should not irreversibly transform stored files before its release is proven. If it changes file formats or directory layouts, use a migration that is resumable and backward compatible where possible.

Application rollback reruns an older deployment:

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

The volume does not automatically roll back with the image. An old application may be unable to read files transformed by the new version. Coordinate image rollback with snapshot restore only when both are required and approved.

This separation is important:

Recovery action	Changes image?	Changes volume data?
Deploy new version	Yes	No, unless app migrates it
Roll back deployment	Yes	No
Restore snapshot	No	Yes
Restore plus rollback	Yes	Yes

The zero-downtime deployment process protects traffic cutover, not data-format compatibility.

What is a durable storage operating runbook?

Assign an owner to every production volume. The runbook should contain:

• Service target and volume ID.
• Mount path and expected runtime user.
• Allocated size and alert threshold.
• Data description and rebuildability.
• Snapshot schedule and retention.
• Last verified snapshot.
• Restore approval policy.
• Application validation steps.
• Image and data compatibility notes.
• Growth and deletion policy.

Inspect usage regularly:

dockup volume usage <volumeId> production/web --json

CPU, RAM, and disk are measured per minute. The Free plan offers $2.50 starting credit, while the recommended Go plan costs $20 per month with $20 usage credit.

Snapshot restore drill

Do not wait for an incident to discover that no one knows which snapshot to choose. Run a controlled drill on a non-production service or approved copy:

1. Create recognizable test files.
2. Take a snapshot.
3. Change the files.
4. Restore the snapshot.
5. Verify contents and permissions.
6. Observe the container restart.
7. Record timing and failure points.

A restore drill turns persistent volumes and snapshots from a checkbox into a tested recovery capability.

For initial service design, see Git repository to production. For command details, use the Dockup CLI reference.

Define recovery objectives for file data

Recovery point objective answers how much recent data the business can lose. Recovery time objective answers how long restoration may take. A daily snapshot with seven-copy retention may satisfy an internal media cache but not a user-upload product that promises near-real-time durability.

Document both values and test the actual restore duration. Snapshot creation speed, data size, container restart, file validation, and application reindexing all contribute to recovery time.

Control file deletion and growth

Persistent storage can fill because the application never removes temporary or replaced files. Add a retention policy at the application layer and distinguish logical deletion from immediate physical deletion. A short recovery window may justify delaying permanent removal.

Before running a bulk cleanup:

1. Measure current volume use.
2. Produce a deletion candidate list.
3. Take a snapshot.
4. Run the cleanup in bounded batches.
5. Verify application references.
6. Confirm expected space recovery.

This gives persistent volumes and snapshots a preventive role, not only an incident role.

Verify snapshot inventory

Review snapshot IDs, creation times, retention, and the last successful restore test on a schedule. A configured job with no recent usable snapshot is not a recovery system.

Assign restore authority

Name who may approve a production restore and who performs post-restore validation. Separating approval from execution reduces the chance that urgency bypasses target and snapshot verification.

Start with a verifiable deployment

Create one non-production volume, take a snapshot, change a test file, and complete a restore drill before storing irreplaceable production data.

Start free at app.dockup.ai. The Free plan is $0 per month, includes $2.50 in starting credit, and supports one workspace, three databases, and three deployments.

FAQ

Does a Dockup volume survive deployment?

Yes. The volume remains persistent while service containers are replaced, provided the application continues to use the configured mount path.

Is a volume snapshot the right backup for PostgreSQL?

No. A hot snapshot of a database data directory may not be transaction-consistent. Prefer the managed database backup system for managed databases.

What happens when a volume snapshot is restored?

The current volume contents are replaced with the selected snapshot and the container is restarted, so the operation should be approved and verified.

Can Dockup schedule volume snapshots?

Yes. The volume schedule command supports daily snapshots with a retention count, and the schedule can be disabled explicitly.

Does rolling back an application also roll back its volume?

No. Application deployment history and volume snapshot history are separate. Coordinate both only when the recovery plan requires it.