Encontrando copia de seguridad generada por UI y restaurando sitio

Hola Discourse,

Ayer por la noche estaba realizando las actualizaciones de Discourse y reconstruí la aplicación, lo que provocó una serie de errores de Postgres. Me di cuenta de que esto era consecuencia de la actualización reciente, pero seguía obteniendo errores de “permiso denegado”, entre otros (y sí, cambié los propietarios de todo a 700, así que no era global). Por lo tanto, moví mi directorio original /var/discourse a un lugar que supuestamente sería temporal y reinstalé una instancia fresca de Discourse para intentar, al menos, actualizar postgres.

Aquí es donde se pone interesante. Tenía una copia de seguridad del sitio (solo la base de datos, las subidas se guardan en un volumen diferente) generada por la interfaz de usuario hace tres días. O al menos, eso pensaba. Lo que tengo ahora es un archivo llamado wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz, del cual creo haber aprendido que, de hecho, no es el archivo tar.gz en el que debería estar la copia de seguridad real.

Actualmente he redirigido a todos a una página de aterrizaje y espero que alguien pueda decirme si aún es posible recuperar el archivo .tar.gz real del servidor de hace tres días, y exactamente cómo debo proceder para hacerlo.

Tengo mis copias de seguridad y subidas guardadas en el almacenamiento de bloques de Digital Ocean, y todavía tengo la carpeta de Discourse de mi instalación anterior que funcionaba, pero moverla o copiarla de nuevo a /var/discourse solo rompe todo una vez más, incluyendo errores de postgres. Llevo trabajando en esto durante 9 horas seguidas y estoy a punto de llegar al límite de mi paciencia. ¿Puede alguien ayudarme, o al menos intentar indicarme la dirección correcta? :pray: Acabamos de alcanzar la marca de 1000 usuarios y realmente, realmente me gustaría evitar perder todo eso.

Editado para corregir mi configuración de subidas.

Si tienes tu configuración de S3 en app.yml, simplemente puedes realizar una restauración desde la línea de comandos y se recuperará la copia de seguridad desde S3.
Dado que tienes tus activos en S3, la copia de seguridad contiene únicamente la base de datos.

Solo deberías poder clonar un nuevo /var/discourse, copiar tu archivo yml, reconstruir y realizar la restauración desde la línea de comandos.

Usar almacenamiento de objetos para cargas (S3 y clones)

Restaurar una copia de seguridad desde la línea de comandos

Supongo que estoy usando el término incorrecto para describir cómo están configuradas mis copias de seguridad/subidas. Utilicé este método: Move Uploads and Backups to DigitalOcean Block Storage

Corregiré eso y diré que mis subidas y copias de seguridad no están locales a la carpeta principal de Discourse (es parcialmente cómo comenzó todo esto; estaba intentando migrarnos a DigitalOcean Spaces). Por lo tanto, no, desafortunadamente, no tengo ninguna configuración de S3 realizada, ya que solo estaba guardando en almacenamiento montado.

Las copias de seguridad se guardaban en mnt/my_storage/shared/standalone, pero cuando voy a buscar las copias de seguridad allí, solo tengo el archivo wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz. De hecho, intenté restaurar desde ese archivo por falta de una mejor idea (lo cual probablemente fue un error), pero obtuve un error de permiso denegado. Estoy seguro de que tiene algo que ver con cómo se generan realmente esas copias de seguridad.

¿Siguen tus subidas en el almacenamiento de bloques de DO?

Sí, todas las subidas están intactas.

Vale, bien.

En ese caso, deberías poder restaurar el archivo SQL y luego volver a montar el volumen de almacenamiento en bloque para recuperar tus archivos subidos.

Hay dos tipos de copias de seguridad: sql.gz, que no incluye las subidas, y tar.gz, que sí las incluye. Así que tenías el tipo de copia de seguridad incorrecto, pero el hecho de que tus archivos subidos estuvieran en un volumen externo te salvó el pellejo.

2 Me gusta

Así que entro a la aplicación e intento restaurar ese sql.gz, pero recibo un error de “permiso denegado”. ¿Tienes alguna idea de por qué podría ser?

¡Me lo estás diciendo! :slight_smile:

(Asumiendo que te refieres a chmod). Si los archivos tienen el propietario incorrecto, no se pueden escribir.

Creo que esto podría haber causado el error de permiso denegado.

¿Cuál es el error exacto?

Sí, gracias, he estado despierto toda la noche y estoy un poco sin cerebro.

EXCEPCIÓN: lib/discourse.rb:93:in `exec': No se pudo copiar el archivo comprimido al directorio tmp.
cp: no se puede abrir '/var/www/discourse/public/backups/default/wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz' para lectura: Permiso denegado

Prueba chmod 644 /var/www/discourse/public/backups/default/*

2 Me gusta

Estoy trabajando en esto ahora mismo, les daré noticias en breve. Gracias por tomarse el tiempo de ayudarme.

Esto funcionó para iniciar la restauración, ¡MUCHAS GRACIAS! :pray:

Ahora solo tengo que averiguar por qué el sitio aún no carga. :grimacing:

La reconstrucción está en curso con el archivo app.yml guardado de antes de que todo se rompiera.

1 me gusta

¿Existe un comando para mover esta copia de seguridad directamente a la aplicación? La restauración no la encuentra y no recuerdo cómo logré cargarla anteriormente.

Puedes descargarlo desde S3 y colocarlo en:

/var/discourse/shared/standalone/backups/default

Deberías poder restaurarlo desde la línea de comandos.

Sin embargo, después de eso, debes configurar tu configuración de S3 como se describe en el enlace anterior; esto facilita las cosas.

2 Me gusta

Gracias, Jay. Y sí, ese es absolutamente mi plan.

1 me gusta

Bueno, aquí es donde me encuentro ahora.

  • La restauración desde ese archivo .sql.gz fue exitosa. (¡hurra! Gracias de nuevo, Richard.)
  • Aseguré que app.yml tuviera la misma configuración que antes de que todo se derrumbara.
  • ./launcher rebuild app
  • La reconstrucción fue exitosa con Postgres 13 (por fin).

Sin embargo, al intentar acceder al sitio en sí, sigue sin estar disponible. Uso Cloudflare, pero tengo activado el Modo de Desarrollo en este momento y he vaciado la caché de DNS. Todo está apuntando donde debería. La plantilla de Cloudflare está en app.yml.

El DNS se está resolviendo correctamente, los nombres de host están actualizados, la instalación de Discourse se realizó con la URL apropiada y se me están acabando las ideas.

https://forum.wackywriters.com es la URL, y solo estoy recibiendo errores de “servidor no disponible”. Siento que estoy dando vueltas en círculos (lo siento), pero ¿alguna sugerencia?

Edición: Cuando ejecuto ./discourse-doctor, veo que hay dos instancias de la aplicación en ejecución en Docker:

¿Es esto normal? (Parece que no debería serlo, pero todo lo que creía saber sobre Discourse ha sido tirado por la ventana en las últimas 24 horas :sweat_smile:)

Edición 2: He estado posponiendo esto como último recurso, pero voy a intentar configurar un servidor completamente nuevo con una instalación limpia de Discourse. Me preocupa que algo se haya estropeado con todas mis intervenciones y no puedo averiguar qué está roto. Afortunadamente, todavía tengo la copia de seguridad y todas las cargas en almacenamiento en bloque, así que si tengo suerte, debería poder conectar eso a un nuevo droplet y transferir las cosas desde allí. Si alguien tiene sugerencias o consejos adicionales, aún apreciaría más experiencia que la mía.

Edición 3: Incluso con un servidor nuevo y la propagación de la IP (nslookup y ping se ven bien, whatsmydns.net también), el foro no carga. Sigo recibiendo errores de conexión. Es como si no estuviera conectando la dirección IP con la instancia de Discourse y, en su lugar, estuviera intentando cargar una página estática, la cual, por supuesto, no existe en este caso.

Así que después de casi 24 horas de lucha, descubrí por qué el sitio se negaba a cargar después de iniciar la restauración.
:point_down:

Debido a tantos reinicios, reinstalaciones y Dios sabe qué más, alcancé el límite de velocidad, así que temporalmente he comentado las plantillas SSL y las volveré a activar en una semana.

El sitio está “funcionando” mientras reprocuro todos los mensajes para corregir las imágenes rotas, pero realmente agradezco a Jay y Richard por ayudarme hoy; lograron guiarme por las partes que simplemente no podía resolver.

Ahora debo descargar una copia de seguridad real para configurar S3 esta semana sin tener que preocuparme por esto nuevamente. :sweat_smile:

1 me gusta

Si buscas, hay una forma de agregar un segundo dominio para que cuente como una solicitud separada para Let’s Encrypt. Pero esperar es más fácil.

Recomiendo que configures Cloudflare en modo «nube gris» sin aceleración.

1 me gusta

@pfaffman ¿No estás confundiendo el almacenamiento de objetos con el almacenamiento en bloques? El almacenamiento de objetos es S3, pero TS dice que usaron almacenamiento en bloques, que es simplemente un disco montado en su directorio de cargas:

1 me gusta

Oh. :man_facepalming:

Sí. Así que nada de lo que dije tiene sentido.

Gracias por darte cuenta de eso, Richard.

2 Me gusta

Bueno, la mayoría de las cosas que dijiste tenían sentido, pero me tenías confundido aquí :slight_smile:

2 Me gusta