# Restaurar

Sustituye la base de datos y los archivos subidos de un despliegue por el contenido de una copia de seguridad.

### Sintaxis

```
$ vela restore                                       # elegir entre las copias del objetivo
$ vela restore vela_myapp_20260901134501.zip         # una copia en el objetivo
$ vela restore ./backups/vela_myapp_20260901134501.zip   # una en esta máquina
```

Una ruta local se sube primero. Cualquier otra cosa se busca entre las copias del propio objetivo, y sin ningún argumento se te muestra la lista para elegir.

Un objetivo que nunca se ha desplegado, o que se desplegó sin base de datos, se rechaza antes de subir nada.

### Opciones

- `-y, --yes` - Omitir la confirmación
- `--no-migrate` - No ejecutar migraciones sobre la base de datos restaurada
- `--keep-previous <n>` - Cuántas bases de datos sustituidas conservar, por defecto `1`
- `--lock-wait <seconds>` - Cuánto esperar a que termine un despliegue o reversión del mismo objetivo antes de rendirse, por defecto `300`
- `-t, --target <target>` - Sobre qué copia de la aplicación actuar, por defecto `production`
- `--server <ssh>` - Servidor en el que se ejecuta este objetivo, registrado en el primer uso

Restaurar producción pide escribir el nombre de la aplicación, igual que [`vela destroy deployment`](/es/destroy/deployment).

### Qué ocurre

La aplicación y PocketBase se detienen, el archivo se descomprime junto al directorio de datos, y ambos se intercambian. Después:

- **Se ejecutan las migraciones** de la release desplegada, de modo que una copia más antigua que el código en ejecución se pone al día con el esquema que ese código espera.
- **Se reconcilia el superusuario.** Una base de datos restaurada trae la cuenta que tuviera la copia, mientras que el entorno del servidor sigue teniendo aquella con la que la aplicación inicia sesión en cada render. Se hacen coincidir, y la restauración no se da por buena hasta que un inicio de sesión real lo demuestra.
- **Se conserva el historial de copias**, así que restaurar no descarta los demás archivos de la máquina.

Si algún paso falla, se restituye el directorio de datos anterior y se reinician ambos servicios.

### Deshacer

La base de datos sustituida se renombra, nunca se borra:

```
/var/lib/vela/apps/<instance>/shared/pb_data.pre-restore-<timestamp>
```

Su ruta se imprime al terminar. Es la única vuelta atrás — bórrala a mano cuando estés conforme, o déjala para que `--keep-previous` la limpie en la siguiente restauración.

### Archivos subidos y S3

Un archivo tomado con [almacenamiento S3](/es/enable/s3) activo no contiene archivos subidos. Restaurarlo conserva los que ya están en el servidor en lugar de borrarlos, y lo indica.

### Local

`vela restore` actúa sobre un despliegue. Todavía no hay `-t local`: reconstruye una base de datos de desarrollo con [`vela migrate up`](/es/migrate/up) y [`vela seeds load`](/es/seeds/load).