# Restore Replace a deployment's database and uploaded files with the contents of a backup. ### Syntax ``` $ vela restore # choose from the target's backups $ vela restore vela_myapp_20260901134501.zip # a backup on the target $ vela restore ./backups/vela_myapp_20260901134501.zip # one on this machine ``` A local path is uploaded first. Anything else is looked up among the target's own backups, and with no argument at all you are shown the list to pick from. A target that has never been deployed, or was deployed without a database, is refused before anything is uploaded. ### Options - `-y, --yes` - Skip the confirmation prompt - `--no-migrate` - Do not run migrations against the restored database - `--keep-previous ` - How many replaced databases to keep, defaults to `1` - `--lock-wait ` - How long to wait for a deploy or rollback of the same target to finish before giving up, defaults to `300` - `-t, --target ` - Which copy of the app to act on, defaults to `production` - `--server ` - Server this target runs on, recorded on first use Restoring production asks you to type the app name, the same way [`vela destroy deployment`](/destroy/deployment) does. ### What happens The app and PocketBase stop, the archive is unpacked beside the data directory, and the two are swapped. Then: - **Migrations run** from the release that is deployed, so a backup older than the running code is brought up to the schema that code expects. - **The superuser is reconciled.** A restored database carries whatever account the backup held, while the environment on the server still holds the one the app signs in with on every render. They are made to agree, and the restore is not called a success until an actual login proves it. - **The backup history is carried across**, so restoring does not discard the other archives on the box. If any step fails, the previous data directory is put back and both services are restarted. ### Undo The database that was replaced is renamed, never deleted: ``` /var/lib/vela/apps//shared/pb_data.pre-restore- ``` Its path is printed when the restore finishes. It is the only way back — remove it by hand once you are satisfied, or leave it for `--keep-previous` to prune on the next restore. ### Uploads and S3 An archive taken while [S3 storage](/enable/s3) was on holds no uploaded files. Restoring it keeps the files already on the server rather than deleting them, and says so. ### Local `vela restore` acts on a deployment. There is no `-t local` yet: rebuild a development database with [`vela migrate up`](/migrate/up) and [`vela seeds load`](/seeds/load).