Restaurar desde una copia de seguridad

Tienes un paquete .tar.gz que guardaste antes (o que te envió alguien del equipo, o que acaba de llegar desde otro servidor). Aquí verás cómo volver a ponerlo en marcha como un servicio en ejecución, ya sea en el mismo lugar (sobrescribiendo el original si todavía existe) o como un clon en un dominio nuevo.

¿Buscas cómo crear copias de seguridad? Eso está en otro artículo: Copias de seguridad: cuál necesitas y cómo usarla. Este parte de “ya tengo un paquete en mi ordenador”.

Dónde empezar la restauración: tres puntos de entrada

El flujo es el mismo, con tres puertas de entrada. Elige la que encaje con tu situación. (Dos de las puertas usan el Menú Acciones de la barra superior; haz clic en ese término para ver dónde está.)

Las tres puertas abren el mismo modal Restaurar desde una copia de seguridad. La única diferencia es el contexto que tiene Server Manager en el momento en que lo abres:

• Desde un panel de servicio, el modal sabe qué receta y qué carga de trabajo esperabas. Si el paquete subido tiene una estructura distinta (por ejemplo, abriste el panel de WordPress pero subiste un paquete de Postgres), muestra una advertencia para que puedas elegir otro archivo antes de ejecutar nada.
• Desde el menú Acciones, no hay ninguna expectativa definida: se restaurará lo que indique el paquete.
• Desde una transferencia entrante, el paquete ya está en el servidor; el modal ofrece un botón Restaurar este paquete con un solo clic.

Paso a paso

Elige el punto de entrada que encaje con tu situación (consulta la tabla de arriba). El modal tiene el mismo aspecto en los tres casos:

Arrastra el archivo .tar.gz a la zona de carga o haz clic en cualquier parte de la zona para abrir el selector de archivos. El modal acepta archivos que terminan en .tar.gz o .tgz.

Haz clic en Subir. Mientras el paquete se transmite al servidor, la zona de carga se sustituye por una barra de progreso (subida por fragmentos: incluso los paquetes de varios GB aguantan conexiones inestables).

¿Qué se está subiendo? Tu ordenador envía los bytes del .tar.gz al servidor mediante un flujo de estilo SFTP, cifrado por la sesión SSH a la que estás conectado. El archivo se guarda en /tmp/helm-restore/<id>/<bundle>.tar.gz y permanece ahí hasta que termina la restauración (después se limpia).

Cuando termina la subida, el modal se cierra y Faro te saluda en el chat con el resumen del manifiesto que ha leído del paquete: el título de origen, el dominio de origen, la receta y la fecha y hora de la copia de seguridad. Después te hace una pregunta breve:

¿Quieres restaurar en el mismo lugar (sobrescribiendo el <name> existente si todavía está presente) o clonar a un dominio nuevo (manteniendo el original intacto y creando una copia separada)?

Este es el único punto de decisión. A partir de aquí, tu respuesta determina el resto de los pasos.

4a. Restaurar en el mismo lugar

Elige esta opción cuando:

• La carga de trabajo original ya no existe (se eliminó, o estás en un servidor nuevo) y quieres recuperarla en el mismo dominio con los mismos nombres.
• El original está roto o mal configurado y quieres borrarlo y volver a crearlo desde el paquete.

Qué hace Faro:

1. Lee docker-compose.yml y .env desde el paquete y los vuelve a crear en la ruta de instalación original.
2. Restaura todos los volúmenes con nombre de Docker (datos de base de datos, archivos subidos, etc.) desde los volúmenes incluidos en el paquete.
3. En sitios estáticos, copia de nuevo el árbol de archivos bajo /var/www/<domain>/.
4. Vuelve a aplicar el bloque del Caddyfile para que el dominio original vuelva a servir el sitio.
5. Inicia el servicio y ejecuta una comprobación de salud.

Cada comando se pausa para que lo apruebes antes de ejecutarse: el chat muestra las líneas exactas docker compose up, tar xzf, caddy reload que estás a punto de lanzar.

4b. Clonar a un dominio nuevo

Elige esta opción cuando:

• Quieres que el original siga funcionando mientras se levanta una copia en otro dominio (staging, dev, demo, segundo negocio…).
• Estás restaurando en un servidor que tiene apuntado un dominio distinto al origen del paquete.

Faro hace una pregunta adicional: ¿cuál es el nuevo dominio? (por ejemplo, staging.example.com).

Qué hace Faro además de los pasos de restauración en el mismo lugar:

1. Elige un nombre de proyecto compose nuevo (para que los contenedores del clon no choquen con los del original), por ejemplo mysite-com → staging-example-com.
2. Reescribe la entrada del Caddyfile para usar el nuevo dominio.
3. Rota los secretos en .env (nueva contraseña de base de datos, nuevas claves de la app): el clon no comparte credenciales con el original.
4. En WordPress, ejecuta wp search-replace <old-domain> <new-domain> dentro del contenedor clonado para que los enlaces dentro de las entradas y los metadatos de medios apunten al nuevo dominio.
5. En aplicaciones web, actualiza cualquier variable de entorno *_URL / *_HOST que apunte al dominio antiguo.
6. Solicita un nuevo certificado TLS para el nuevo dominio (Let's Encrypt mediante Caddy, automático).

El original sigue funcionando sin cambios.

¿Vas a clonar una base de datos? Las bases de datos no tienen dominio. Faro te pide en su lugar un sufijo corto (como staging o qa) y lo usa para derivar un nombre de proyecto compose, un nombre de contenedor y un puerto de escucha únicos, de modo que ambas bases de datos puedan ejecutarse en paralelo sin choques.

Cuando terminan los pasos, Faro muestra la URL final (clon) o el dominio ya restaurado (en el mismo lugar). Ábrelo en tu navegador; si no carga de inmediato, dale a Let's Encrypt entre 30 y 60 segundos para emitir el certificado y vuelve a intentarlo.

El paquete original se elimina automáticamente de /tmp/helm-restore/ cuando la restauración termina correctamente.

Diferencia de receta

Si abriste el modal de restauración desde un panel de servicio (por ejemplo, el panel de WordPress para mysite.com) y subiste un paquete de una receta diferente (por ejemplo, un paquete de Postgres), el modal no sigue adelante sin más: te avisa.

Tienes dos opciones:

• Elegir otro archivo: casi siempre es lo que quieres (has cogido el paquete equivocado).
• Usar este paquete de todos modos: el paquete dirige la restauración, así que esto configurará un servicio nuevo de la receta que tenga el paquete, NO modificará el servicio cuyo panel abriste. Elige esto solo si lo entiendes y es lo que quieres.

La comprobación de diferencias solo se activa cuando el modal se abrió desde un panel de servicio con una receta esperada. La ruta Acciones → Restaurar la omite por completo (no hay ninguna expectativa que comprobar).

Restauración automática después de mover de un servidor a otro

Si usaste pestaña Copia de seguridad → Mover a otro servidor en otro servidor y se transfirió un paquete aquí, el modal de restauración se abre automáticamente con ese paquete resaltado en la parte superior:

Haz clic en Restaurar este paquete y el resto del flujo será idéntico al de una restauración nueva desde ese punto (Faro pregunta si quieres restaurar en el mismo lugar o clonar, tú apruebas comandos, etc.). El paquete ya está en el servidor, así que no hay paso de subida.

También puedes hacer clic en Usar otro paquete… para descartar la precarga y abrir el selector de archivos normal. Es útil si transferiste el paquete equivocado y quieres empezar de nuevo.

Preguntas frecuentes

¿Dónde queda el original durante un clon? Intacto. El clon usa nombres de contenedor distintos, volúmenes distintos, puertos distintos (en bases de datos) y secretos distintos. Puedes eliminar el clon más adelante sin afectar al original.

¿Puedo restaurar un paquete en una distribución de Linux distinta? Sí. El paquete es simplemente Docker compose + volúmenes con nombre + (en sitios estáticos) un árbol de archivos. Server Manager se encarga de la instalación de Docker específica de cada distribución en el destino si falta. La excepción son los paquetes de aplicaciones web nativas (sin contenedor): dependen del gestor de paquetes y de systemd de la distribución de origen, y el artículo de restauración te indicará si no puede traducir la instalación.

El paquete es enorme: ¿se agotará el tiempo de espera de la subida? No. La subida se hace por fragmentos (~4 MB por fragmento) y el servidor los une. Los paquetes de varios GB funcionan; si la conexión se corta a mitad de subida, el modal te permite cancelar y empezar de nuevo, en lugar de reiniciar desde cero en cada fragmento.

¿Qué pasa si cancelo a mitad de la restauración? Si cancelas durante la subida, se elimina el archivo parcial y vuelves a la zona de carga. Si cancelas durante los pasos del chat (entre aprobaciones), se queda lo que Faro ya haya hecho: puede que existan algunos contenedores y algunos volúmenes. Puedes volver a ejecutar la restauración desde el mismo paquete o pedirle a Faro que limpie primero el estado parcial; si algo te parece raro, pregunta en el chat y Faro lo diagnosticará.

¿Puedo restaurar el mismo paquete varias veces en clones distintos? Sí. Vuelve a abrir el modal, sube el mismo paquete y elige clonar cada vez con un dominio nuevo distinto. El paquete sigue siendo válido para siempre (no es más que un tarball).

¿Dónde dejan archivos las restauraciones fallidas? En /tmp/helm-restore/<id>/ en el servidor de destino. La superficie Acciones de la pantalla de inicio muestra los directorios helm-restore huérfanos en la vista de limpieza si queda alguno. Se pueden eliminar sin problema.

Qué NO entra aquí

• **Archivos .helm-backup/** (deshacer archivo por archivo en la pestaña Archivos) → consulta la sección “Recuperar un solo archivo” del artículo Copias de seguridad.
• **Volcados de base de datos sin procesar .sql.gz** (cargables en cualquier Postgres/MySQL) → consulta la sección “Crear una copia solo de la base de datos” del artículo Copias de seguridad.
• Restaurar entre recetas distintas (por ejemplo, un paquete de WordPress como sitio estático): los paquetes son específicos de cada receta. Elige un paquete que coincida con lo que quieres levantar.

Referencia

Qué necesita la restauración en el servidor de destino:

• El servidor Linux accesible por SSH al que estás conectado en Server Manager.
• Espacio en disco para extraer el paquete (aproximadamente 2× el tamaño del paquete, durante un breve momento, mientras se extrae).
• Docker instalado (Server Manager lo instala automáticamente si falta en un destino nuevo).

Rutas de disco durante la restauración:

• Paquete subido (transitorio) → /tmp/helm-restore/<id>/<name>.tar.gz
• Origen extraído → /tmp/helm-restore/<id>/extracted/
• Instalación final: la misma ruta que usaba el original (por ejemplo, /opt/wordpress-mysite-com/, /var/www/mysite.example.com/, …)

El árbol de decisión de un vistazo: