# Add a volume

Give a Component a durable, automatically growing filesystem with optional backups.

Canonical: https://docs.deliberate.space/data/volumes/

Use a volume when your application needs files to survive restarts and
deployments. Mount it into one Component and choose how its recovery points
should be protected:

```yaml
resource: volume
name: uploads
backup: offsite

---
resource: component
name: app
image: ghcr.io/acme/app:1.4.2
needs:
  volumes:
    - name: uploads
      path: /app/uploads
```

You do not choose a disk size up front. The filesystem grows automatically as
the application fills it, and billing follows storage used.

## Choose a backup policy

`backup` describes how recoverable the data must be. It does not select a disk
product.

| Policy | Schedule and retention | Use it for |
| --- | --- | --- |
| `none` | No scheduled backup | Scratch data, caches, and data that can be regenerated |
| `standard` | Daily storage snapshots retained for seven days | Durable data protected against application mistakes |
| `offsite` | Snapshots every six hours, copied to EU object storage and retained for 30 days | Source-of-truth data that needs a recovery point outside the workload cluster |

`standard` is the default. Choosing `none` does not make the filesystem
temporary—it only means the platform does not create scheduled recovery points.

Restores are created as a new volume first. The existing volume is not destroyed
to discover whether a backup is usable. You can inspect the available recovery
points and explicitly choose the one to restore.

## Make snapshots application-consistent

A normal volume snapshot is **crash-consistent**: it represents the filesystem
as if power had been lost at that instant. Journaled filesystems and storage
engines are designed to recover from this state, but an application may keep
important data only in memory.

For software with a supported flush or lock command, a Blueprint author can add
`consistency` hooks. deliberate. runs the `before` command in the component that
mounts the volume, waits for it to succeed, captures the volume, and then runs
the optional `after` command. That produces an application-consistent recovery
point without pretending the platform understands every storage engine's file
format.

```yaml
resource: volume
name: data
backup: offsite
consistency:
  before: redis-cli BGSAVE
```

Platform-operated databases use their database-native backup and recovery path instead;
do not place a PostgreSQL data directory on a general-purpose volume.

## Copy files into a preview

When you create a derived Environment, the platform can snapshot and copy the
upstream volume into an isolated filesystem for the new Environment. The copy
can then change independently. Blueprint consumers get the complete application
shape—including its data-bearing components—without manually wiring storage.

Be deliberate about sensitive production data: an Environment copy is another
copy of that data, protected by the destination Environment's access controls
and lifecycle.

## Next steps

- [Choose how previews receive data](/deploy/environments/)
- [Understand encryption and recovery boundaries](/data/protection/)
- [Use object storage instead of a filesystem](/data/object-storage/)