# Backup

Back up a deployment's database and uploaded files, and bring the archive off the server.

An archive holds everything PocketBase keeps in its data directory: `data.db`, `auxiliary.db`, and the `storage/` tree that every uploaded file lives in. It is taken while the app keeps serving — the databases are copied with `VACUUM INTO`, so nothing is caught half-written.

### Syntax

```
$ vela backup <command>
```

- [`create`](/backup/create) - Take a backup and download it
- [`list`](/backup/list) - List the backups on a target
- [`download`](/backup/download) - Save an existing backup off the server
- [`delete`](/backup/delete) - Remove a backup
- [`schedule`](/backup/schedule) - Back up automatically

### Where uploads live

Uploaded files are PocketBase's, not the app's. On a server they sit in the instance's shared directory:

```
/var/lib/vela/apps/<instance>/shared/pb_data/storage/<collection>/<record>/<file>
```

`shared/` is a sibling of `releases/`, not part of one, so uploads survive a deploy, a rollback, and a [`vela destroy deployment`](/destroy/deployment) without `--purge`. Nothing in a release ever overwrites them, and a developer's local `data/` is never uploaded.

Locally the same tree is `data/storage/`, which is gitignored.

### Targets

`vela backup` defaults to `-t production` — the copy worth protecting. Name another target, or `local`, to work somewhere else:

```
$ vela backup create                 # production
$ vela backup create -t staging
$ vela backup list -t local          # the development database
```

### With S3 storage

If [`vela enable s3`](/enable/s3) is on, PocketBase leaves `storage/` out of the archive: the files are not on the server to copy. The archive still holds the databases, and the bucket's own versioning is what protects the uploads. `vela backup create` says so when it applies.

[`vela enable s3 --backups`](/enable/s3) is a separate setting, and sends the archives themselves to a bucket rather than leaving them on the disk they are a backup of.