Modificando la base de datos dentro de una copia de seguridad para eliminar una clave duplicada y que no falle al restaurar

Esta publicación es una versión muy condensada de mis últimas 24 horas, aunque en realidad aún no ha funcionado, así que también espero que alguien publique dónde salió mal debajo de esto.

Mi actualización de Discourse falló debido a una clave duplicada, una de mis etiquetas está duplicada. Para solucionar el problema de la actualización, necesité hacer una instalación nueva de Discourse y luego cargar mi última copia de seguridad, pero la recarga falla porque se enfada por la clave duplicada. Así que necesité ir dentro de la copia de seguridad para editar la etiqueta infractora por algo diferente.

Por alguna razón, la copia de seguridad re-comprimida con el problema de la etiqueta duplicada arreglado es significativamente más pequeña que la copia de seguridad de la que provino, y falla cuando intento restaurarla, así que algo salió un poco mal con el proceso de re-compresión.

1) Localización de copias de seguridad: Para localizar tus copias de seguridad de Discourse, puedes usar el siguiente comando:

sudo find / -name "*.tar.gz"

Esto buscará en tu sistema todos los archivos de copia de seguridad con la extensión “.tar.gz”. Por defecto, debería estar dentro de tu contenedor en: shared/backups/default

2) Hacer una copia: Una vez que hayas encontrado la copia de seguridad con la que quieres trabajar, crea una copia de ella para asegurarte de tener una copia de seguridad del archivo original. Usa el comando “cp”:

bash

sudo cp /ruta/a/copia_de_seguridad_original.tar.gz /ruta/a/copia_de_seguridad_copiada.tar.gz

3) Extracción de la copia: Extrae el contenido del archivo de copia de seguridad copiado usando el comando “tar”:

bash

tar -xzvf /ruta/a/copia_de_seguridad_copiada.tar.gz

Esto extraerá los archivos de copia de seguridad en un directorio temporal.

4) Edición de las etiquetas en la base de datos: Navega a los archivos de copia de seguridad extraídos y abre el archivo de base de datos relevante usando un editor de texto. Me encontré con un problema con etiquetas duplicadas de “socialmedia”, que impidieron una restauración exitosa. En una base de datos grande hay muchas instancias de etiquetas, y probablemente para la etiqueta específica que estás buscando, así que busqué ‘immutable socialmedia’ usando Ctrl W en Nano, lo que me llevó directamente allí.

sudo nano /ruta/a/base_de_datos_extraida.sql

Edité una instancia de la etiqueta “socialmedia” a “socialmedia2”, luego hice una búsqueda rápida para comprobar que ahora solo aparece una vez. Puedo arreglar esas etiquetas desde la sección de administración una vez que la restauración tenga éxito.

5) Recompresión: Después de editar los archivos de copia de seguridad, crea un nuevo archivo de copia de seguridad con el contenido corregido. Usa el siguiente comando para comprimir los archivos modificados:

tar -czvf /ruta/a/nueva_copia_de_seguridad_modificada.tar.gz /ruta/a/directorio_de_archivos_modificados

6) Mover al archivo correcto: Mueve el nuevo archivo de copia de seguridad modificado al directorio apropiado donde se almacenan las copias de seguridad. La ubicación por defecto suele ser “/shared/backups/default”:

sudo mv /ruta/a/nueva_copia_de_seguridad_modificada.tar.gz /shared/backups/default/

7) Detener e iniciar servicios: Antes de restaurar la copia de seguridad modificada, asegúrate de detener los servicios relevantes para evitar posibles conflictos durante el proceso de restauración. Usa el comando “./launcher stop app” para detener la aplicación Discourse:

./launcher stop app

8) Restauración de la copia de seguridad: Para restaurar desde la copia de seguridad modificada, usa el comando “discourse restore” con la ruta al nuevo archivo de copia de seguridad:

discourse restore /shared/backups/default/nueva_copia_de_seguridad_modificada.tar.gz

O puedes hacerlo a través de /admin en tu sitio, ya que ahora debería aparecer en la sección de copias de seguridad.

9) Verificación de la restauración: Después de que el proceso de restauración se completó, verifiqué que los cambios fueron exitosos revisando la aplicación y la base de datos de Discourse para asegurarme de que las etiquetas duplicadas de “socialmedia” fueron eliminadas.

10) Inicio de servicios: Reinicié los servicios que se detuvieron anteriormente para poner la aplicación Discourse en línea nuevamente. Usé el comando “./launcher start app” para iniciar la aplicación Discourse:

./launcher start app

11) Eliminación de archivos temporales y copias de seguridad adicionales: Después de restaurar exitosamente la copia de seguridad, eliminé cualquier archivo temporal y copia de seguridad adicional que se creó durante el proceso para liberar espacio en disco. Usa el comando “rm” para eliminar los archivos:

sudo rm -r /ruta/a/directorio_temporal
sudo rm /ruta/a/copia_de_seguridad_copiada.tar.gz
3 Me gusta

¿Por qué?

¿Por qué no pudiste arreglar esto ‘en línea’ reiniciando la aplicación, entrando al contenedor, entrando a postgres y luego lidiando con la entrada de datos de inmediato?

1 me gusta

No esperaba el error, así que ya había puesto la nueva versión de Discourse en mi servidor. El error de clave duplicada estaba en la copia de seguridad y no en la aplicación recién instalada, pero no pude restaurar la copia de seguridad porque primero quería que se corrigiera el error.

Así que tuve que intentar editar la etiqueta dentro de la copia de seguridad.

¿Pero viste el error en la actualización?

La próxima vez, hazte la vida más fácil y arréglalo en el momento.

La aplicación no se estaba ejecutando y no podía recargarla, así que actualicé a una versión nueva de Discourse en un intento de solucionar eso. Lo que significó que no tuve acceso a la base de datos en ningún lugar que no fuera la copia de seguridad.

Ciertamente, este es un caso específico que he publicado aquí, la mejor opción habría sido notar el problema y solucionarlo mientras todavía tenía acceso directo a la base de datos de la aplicación, pero lo pasé por alto y no pude encontrar ninguna otra opción.

1 me gusta

No te preocupes. Al menos has demostrado que es posible, has aprendido cosas nuevas y has dado a otros una opción adicional.

¡Buen trabajo! :clap:

3 Me gusta

Gracias, aunque el archivo original era de 128 MB y el nuevo es de 29 MB, así que creo que volver a comprimirlo en el servidor puede haber truncado el archivo debido a su longitud.

Este proceso parece que debería funcionar, pero el archivo que obtuve no se pudo usar para restaurar mi discurso.

1 me gusta

¿El camino que tomaste fue más arriesgado pero ciertamente factible? Quizás alguien pueda dar algún consejo sobre este problema.

Presumiblemente puedes repetir esto de nuevo desde la copia de seguridad, así que…

1 me gusta

¿Se ha resuelto este problema? Parece un tutorial, pero su sitio todavía parece estar roto.

Tal vez estás haciendo algo que no entiendo, pero normalmente puedes simplemente ejecutar ./launcher start app para iniciar el contenedor antiguo, ¿hubo alguna razón por la que no pudiste hacer eso?

Luego puedes usar herramientas de Rails o SQL para arreglar tu base de datos en el contenedor antiguo, y luego intentar ejecutar el bootstrap/rebuild nuevamente.

O tal vez migraste la base de datos más allá de lo que tu contenedor antiguo podía manejar.

He realizado una cirugía similar en una copia de seguridad antes cuando el sitio que se estaba restaurando tenía un año o más. Creo que el volcado de la base de datos era lo suficientemente pequeño como para poder editarlo en vim.

1 me gusta

Gracias por responder.

Se negó a iniciarse ya que estábamos unas cuantas actualizaciones atrasadas, así que actualicé a la última versión de Discourse creando una nueva y subiendo nuestra copia de seguridad antigua, pero rechazó esa copia de seguridad debido a las claves duplicadas.

O tal vez migraste la base de datos más allá de lo que tu contenedor antiguo podía manejar.

Sí, probablemente eso. Ahora mismo no tengo muy claro exactamente lo que hice, pero actualicé algunas cosas de forma independiente basándome en consejos de solución de problemas de por aquí. Una de ellas fue obtener la versión más reciente de PostgreSQL.

Pude editarlo en vim.

Pude editarlo en Nano, y todo parecía bien, pero el archivo vuelto a comprimir era demasiado pequeño, así que algo salió mal en alguna parte… tal vez no pude editarlo en Nano. Parecía haber funcionado en ese momento.

Esperaba que alguien viera un error en él y me corrigiera, para que se convirtiera en una guía de “cómo hacerlo”.

Lo que miraría a continuación:

  • Rehacer toda la descompresión. Comprimirlo sin cambios. Comprobar que el tamaño del archivo zip es el mismo que antes. Si no es así, ¿quizás no estás comprimiendo con las mismas opciones?

  • Descomprimir de nuevo, comprobar el tamaño del archivo que estás editando. Editarlo, guardarlo, confirmar que el tamaño no ha cambiado significativamente.

1 me gusta

Una pequeña actualización. Alguien más en mi equipo estuvo trabajando en esto la semana pasada pero no se encontró una solución, así que lo intenté de nuevo, esta vez editando la base de datos en mi sistema local.

Lo que hice:

  1. descargué una copia de seguridad antigua que quiero restaurar
  2. descomprimí los archivos con 7zip
  3. abrí dump.sql con Visual Studio Code
  4. encontré las etiquetas duplicadas directamente en la base de datos.
  5. encontré lo que parecía ser la lista de etiquetas buscando entre comillas simples (’ ') la etiqueta. En mi caso ‘socialmedia’. Las etiquetas parecen ser la 2ª y 3ª desde abajo de las instancias encontradas.

  1. edité una para que dijera

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Volví a comprimir el archivo dump.sql en 7zip
  • Añadir al archivo
  • Formato de archivo .gzip
  1. Volví a comprimir el archivo principal de copia de seguridad
  • Añadir al archivo
  • Formato de archivo .tar (gzip aún no está disponible)
  1. Ahora deberías ver un archivo de copia de seguridad .tar fijo y comprimido

  2. Comprime el archivo .tar en 7zip para crear un archivo .tar.gz, para que coincida con el formato utilizado por Discourse

  • Añadir al archivo
  • Formato de archivo .gzip
  1. Sube a las copias de seguridad y restaura a través de la sección de administración

En este punto, me encontré con un mensaje de error:

Extrayendo archivo dump…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

¿Alguien tiene alguna idea de lo que me perdí en el proceso anterior?
Lo único en lo que puedo pensar es que la ruta que está buscando utiliza la fecha de hoy y no la fecha de la copia de seguridad (estoy escribiendo esto el 08-08-2023).

Este es un seguimiento de mi publicación anterior aquí. Publico de nuevo para que sea más fácil de encontrar para cualquier otra persona que haga esto en el futuro si funciona.

Lo que hice para editar la base de datos en mi portátil:

  1. descargué la copia de seguridad antigua que quiero restaurar desde la sección de administración
  2. descomprimí los archivos con 7zip
  3. abrí dump.sql con visual studio code
  4. encontré las etiquetas duplicadas directamente en la base de datos.
  5. encontré lo que parecía ser la lista de etiquetas buscando entre comillas ’ ’ la etiqueta. En mi caso ‘socialmedia’. Las etiquetas parecen ser la 2ª y 3ª desde abajo de las instancias encontradas.

  1. edité una para que dijera

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Volví a comprimir el archivo dump.sql en 7zip
  • Añadir al archivo
  • Formato de archivo .gzip
  1. Volví a comprimir el archivo de copia de seguridad principal
  • Añadir al archivo
  • Formato de archivo .tar (gzip aún no está disponible)
  1. Ahora deberías ver un archivo de copia de seguridad .tar comprimido y arreglado

  2. Comprime el archivo .tar en 7zip para crear un archivo .tar.gz, para que coincida con el formato utilizado por Discourse

  • Añadir al archivo
  • Formato de archivo .gzip
  1. Sube a copias de seguridad y restaura a través de la sección de administración

En este punto me encuentro con un mensaje de error:

Extrayendo archivo dump…
[2023-08-08 15:09:15] EXCEPCIÓN: No existe tal archivo o directorio @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

¿Alguien tiene alguna idea de lo que me perdí en el proceso anterior?
Lo único en lo que puedo pensar es que la ruta que está buscando utiliza la fecha de hoy y no la fecha de la copia de seguridad (estoy escribiendo esto el 08-08-2023).

1 me gusta

Creo que quizás el nombre exacto de un archivo de copia de seguridad es importante: nombre del foro, fecha y marca de tiempo, identificador de versión. Por lo tanto, si desempaquetas, modificas y vuelves a empaquetar, sugeriría reconstruir con el mismo nombre que el original. Pero, por supuesto, mantén el original a salvo.

1 me gusta

He combinado las publicaciones del nuevo tema en este, ya que parece que mantener este problema agrupado en un solo lugar facilitará mucho su seguimiento para futuros viajeros. :+1:

1 me gusta

Gracias @Ed_S, mantuve el nombre original ya que leí en otro lugar que era importante. Mi pregunta anterior es sobre por qué la herramienta de restauración de copias de seguridad estaba buscando y no encontraba: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

que es la fecha en la que estaba realizando la restauración.

1 me gusta

Ah, lo siento. Eso parece extraño. Puede que se espere que el directorio temporal se nombre según la fecha de hoy, pero no parece bueno que no se encuentre el archivo de volcado SQL.

Si enumera el contenido del archivo tar, ¿ve ese nombre de archivo allí? En mi caso

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
1 me gusta

Gracias Ed, ese archivo no existía. Disculpa la demora, he estado desconectado un tiempo.

No hay un archivo con el nombre correcto allí, así que acabo de intentar crear un archivo vacío manualmente:

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

pero cada vez que presiono restaurar, busca un archivo ligeramente diferente (los últimos 6 dígitos). Supongo que está buscando una carpeta generada por una marca de tiempo, por lo que cada vez que presiono el botón de restauración, la carpeta que busca ha cambiado.

Sospecho que algo está saliendo mal en tu paso 10, donde creas el archivo tar. ¿Puedes verlo? ¿Puedes usar file para describirlo? ¿Puedes listar el contenido con tar tvfz?

1 me gusta