andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug 8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)
El contenido completo del archivo parece estar bien, aunque es difícil decirlo ya que es mucha información: Hastebin
Creo que tiene que ver con las rutas de los archivos. Echa un vistazo a
Hmm. Puede que ese no sea el problema. Mayormente no confío en 7zip para crear un archivo tar compatible, pero eso puede ser irracional.
-h, --dereference
Sigue los enlaces simbólicos; archiva y vuelca los archivos a los que apuntan.
La respuesta podría estar en el archivo anterior. De hecho, probablemente esté en otro archivo del mismo directorio.
Gracias. El contenido es correcto, pero creo que los nombres están equivocados. Por eso el problema.
Tienes
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz
pero el original y cualquier copia de seguridad no modificada tendrían
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 dump.sql.gz
Edición: así que necesitas dirigir 7zip de una manera un poco diferente al crear ese archivo tar.gz.
Gracias por toda tu ayuda. He descomprimido los archivos, he editado la etiqueta duplicada de nuevo y luego la he vuelto a comprimir con mucho cuidado, prestando especial atención al nombre del archivo, ¡y hay progreso!
Ahora, al restaurar, veo este mensaje de error, que parece ser mucho más común:
[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR: no se pudo crear el índice único «index_tags_on_lower_name»
[2023-08-25 15:25:21] DETAIL: La clave (lower(name::text))=(socialmedia) está duplicada.
[2023-08-25 15:25:21] EXCEPTION: psql falló: DETAIL: La clave (lower(name::text))=(socialmedia) está duplicada.
Supongo que eso significa que he cambiado la etiqueta con éxito, pero todavía hay algunas ocurrencias de la etiqueta en las publicaciones de mi base de datos. El número de tag_id dice que debería haber una etiqueta llamada socialmedia, pero en su lugar está encontrando una etiqueta llamada socialmedia2, lo que está causando un conflicto.
esta publicación y esta otra discuten soluciones, pero como solo tengo acceso a mi copia de seguridad editando directamente el código en mi máquina local, no puedo usar las herramientas de MySQL para ayudar a limpiarlo.
Afortunadamente, en mi base de datos solo tengo 38 instancias de ‘socialmedia’ (en lugar de más de 50.000 ocurrencias de socialmedia). Suponiendo que tuve razón al cambiar la línea 395421 como la capturé arriba, entonces no puedo ver cómo decir cuáles de las restantes están vinculadas a la etiqueta ‘socialmedia’ y cuáles a la etiqueta que he editado a ‘socialmedia2’.
Aquí hay un ejemplo de una publicación bastante corta que usa la etiqueta socialmedia
9488 '/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82 Gracias por tomarte el tiempo de comentar aquí @R, significa mucho, especialmente en el st... ha estado trabajando duro en ello y todos estamos muy emocionados de verlo finalmente cerca de estar listo en el sitio en vivo :slight_smile: :slight_smile: en_GB 4 f
Sin embargo, podría estar equivocado, ya que parece haber más etiquetas al principio de las que un usuario probablemente usaría en una publicación. También es posible que ‘socialmedia’ no sea una etiqueta utilizada en la publicación anterior, aunque debería haberlo sido.
Restauraría la base de datos manualmente e intentaría agregar los índices y solucionar los problemas de la base de datos en lugar de un archivo de texto, pero eso también es difícil.
No creo que esa sea la conclusión inmediata que puedes/deberías sacar. El problema debería ser sencillo:
La razón por la que ese índice no se crea es que tienes al menos dos entradas en la tabla tags que se resuelven a lo mismo cuando tomas la versión en minúsculas de su nombre. Eso es lo que te está diciendo el mensaje de error.
Así que creo que todavía necesitas encontrar las entradas relacionadas en esa única tabla que chocan al pasar por esa transformación.
Antes de eliminar el/los duplicado(s), anota sus ids porque también necesitarás eliminar las filas relacionadas de la tabla topic_tags (algo que podrías haber solucionado rápidamente si hubieras realizado todo este mantenimiento en línea simplemente reiniciando el contenedor en lugar de destruir la instancia).
¡Nuestro sitio ha vuelto! Gracias a todos por su ayuda.
Parece que lo resolví hace días, pero fui descuidado al leer el mensaje de error. Había dos etiquetas duplicadas, ‘socialmedia’ y ‘social-media’. Después de arreglar la primera, no me di cuenta de que el mensaje de error había cambiado, dada la similitud de ambas etiquetas duplicadas.
Aquí están los procesos para solucionar esos dos errores:
1. Encontrar la tabla de etiquetas y la etiqueta duplicada
Descargue la copia de seguridad a su sistema operativo. Esta guía es para Windows, pero el proceso será prácticamente el mismo en Linux.
Extraiga todas las carpetas comprimidas, lo que debería dejarle un archivo dump.sql y una carpeta uploads.
Abra el archivo dump.sql con un editor de texto; yo usé Visual Studio Code.
Busque “COPY public.tags” para localizar la tabla de etiquetas. Debería estar cerca del final y verse así:
Navegue por ella manualmente o copie y pegue su tabla de etiquetas en un documento separado donde pueda usar la función de búsqueda para encontrar su etiqueta duplicada.
Guarde su archivo dump.sql corregido como dump.sql.
2. El orden y los nombres de los archivos y carpetas deben ser perfectos en la nueva compresión.
Después de la extracción, debería tener un archivo dump.sql y una carpeta uploads.
Haga clic derecho en dump.sql. Seleccione 7zip y ‘añadir al archivo’.
Seleccione gzip como formato de archivo, manteniendo el mismo nombre para el archivo.
Seleccione el nuevo archivo dump.sql.gz y el archivo uploads, luego haga clic derecho > 7zip > añadir al archivo > formato de archivo: tar. Asegúrese de que el nombre del archivo sea exactamente el mismo que el de la copia de seguridad original, debería verse algo así: ‘public-happiness-2023-07-25-033857-v20220628031850’.
Seleccione su nuevo archivo .tar > 7zip > añadir al archivo > formato de archivo: gzip. Asegúrese de que el nombre del archivo sea exactamente el mismo que el de la copia de seguridad original, debería verse algo así: ‘public-happiness-2023-07-25-033857-v20220628031850’.
Su resultado final debería ser un archivo .tar.gz con el mismo nombre que su copia de seguridad original.
Cargue en el área de administración y restaure su copia de seguridad.
Hay un lugar más donde la etiqueta está/podría estar repetida y esa es la tabla de datos de búsqueda:
COPY public.tag_search_data (tag_id, search_data, raw_data, locale, version) FROM stdin;
No estoy seguro de si eso también necesita ser corregido o no.
¡Me alegro de que finalmente lo hayas arreglado!
