Restaurar

Restaurar un backup reemplaza tu base de datos actual y tus archivos de media con el contenido de un archivo de backup. Restaurar desde un archivo subido, desde un backup almacenado en este servidor, desde una copia remota en DO Spaces, o por la API.

Qué se reemplaza

Un restore reemplaza:

la base de datos
el directorio de media
los archivos de theme y los site templates, cuando el backup los contiene
los metadatos de theme, cuando se incluyen

La acción no se puede deshacer, así que la interfaz te advierte antes de que cambie cualquier cosa y te pide confirmar.

Desde dónde restauras

Sube un archivo de backup desde el formulario *Restore from Backup* en la pantalla de Backups. El archivo debe ser un archivo .tar.gz de no más de 50 MiB.

Restaura un backup local desde la lista de archivos guardados en el servidor, usando su botón Preview o Restore. Los archivos de backup locales se reconocen por su patrón de nomenclatura chinaski_backup_<timestamp>.tar.gz.

Restaura desde DO Spaces . si Spaces está configurado bajo Settings → Integrations, puedes restaurar desde una lista de backups remota. En una instancia air-gapped el restore remoto está deshabilitado.

Restore por API . un endpoint permite a los clientes con una API key de escritura restaurar un backup local con nombre, incluida la misma vista previa dry-run que usan las pantallas de admin.

Siempre previsualiza primero

Haz clic en Preview (dry run) antes de restaurar. Un dry run lee el archivo y reporta, sin cambiar nada:

el tipo, fecha de creación, hostname y versión de CMS del backup
su versión de schema comparada con la tuya actual . un desajuste se resalta y garantiza que el restore abortará
qué incluye el archivo (media, themes, site templates)
el resultado de una verificación de integridad sobre la base de datos respaldada
cualquier fallo de validación o advertencias de backup legacy

Los backups hechos por una versión reciente incluyen un manifest de checksums. Si está presente, la restauración verifica cada archivo dentro del archivo contra su checksum SHA-256 registrado; los desajustes abortan el restore con "backup may be corrupted or tampered with". Los backups "legacy" más antiguos se restauran bien pero te avisan que los checksums no se verificaron.

Para los backups subidos, la verificación corre contra el archivo staged exacto que previsualizaste, así que lo que confirmas es lo que se aplica. Si las nuevas vistas previas reemplazan ese upload staged, la confirmación anterior es rechazada.

Qué se aplica obligatoriamente

Estas puertas corren antes de que cambie cualquier cosa:

La versión de schema debe coincidir exactamente. Un backup de una versión de schema distinta aborta el restore por completo antes de que cambie cualquier cosa.
El archivo debe contener el archivo de base de datos . cualquier cosa que no sea un backup de Chinaski es rechazada.
Los archivos deben permanecer dentro del archivo. La extracción recorre la lista de ubicaciones y aborta si alguna entrada intenta escapar del directorio de extracción (trucos de symlink o path traversal).
Los checksums deben coincidir. Cuando el archivo lleva un manifest, cada archivo listado se verifica con SHA-256.
Un timeout de 120 segundos aplica a descargas y extracción; un restore que no termina a tiempo se descarta en lugar de aplicarse tarde.

Qué se muestra en el éxito, y qué necesitas hacer

Una vez que un restore empieza a aplicarse, la base de datos se reemplaza primero, atómicamente. Luego siguen el media, los themes y los site templates:

En un restore limpio ves "Backup restored . database, media, and themes have been replaced". Los restores remotos/API te dicen lo mismo y añaden: reinicia el servicio para recargar la base de datos. Reiniciar después de cualquier restore es una práctica sensata.
Si solo se restauró la base de datos pero el media no pudo intercambiarse (raro, usualmente permisos), el mensaje te dice a reejecutar el restore para reintentar el paso de media.
Si la restauración de themes o site templates falló mientras todo lo demás funcionó, el flash nombra qué revisar.
Los restores exitosos se registran en el audit log con el origen del backup.