Hola a todos: estoy en proceso de migrar de Discourse alojado a autoalojado. He realizado varias pruebas exitosas de diversas cosas, pero cuando intento hacer la migración real, incluyendo todas las cargas, después de un par de horas descomprimiendo el archivo, dice que no existe tal archivo o directorio al intentar extraer el archivo de volcado. ¿Así que ahora me enfrento a la perspectiva de perder alrededor de 140 GB de cargas a menos que alguien tenga alguna idea?
¿Puedes proporcionar el registro?
¿Estás restaurando desde la línea de comandos o desde la interfaz web? Recomiendo la interfaz web.
Hola: Adjunté el registro en el correo electrónico anterior, aunque lo adjunto de nuevo aquí. Lo intenté primero usando la interfaz web y luego por segunda vez a través de la línea de comandos. Sospecho que la copia de seguridad podría estar corrupta de alguna manera, ya que no se reconoce cuando se sube a S3 y se rechaza casi instantáneamente si intento subirla a través del navegador.
restore-failure-log.txt (3.28 KB)
Eso parece. ¿Subiste con el navegador web o con scp/rsync? Yo volvería a subir con rsync.
Hola Jay: Lamento la confusión anterior, ya que también hemos estado en conversaciones con Discourse por correo electrónico durante todo este proceso de migración, y ahí es donde adjunté el archivo de registro.
Al ver el error, sospecho que el tarball en realidad no contiene un volcado de SQL, solo imágenes. El archivo fue iniciado y verificado por Discourse en nuestro nombre. Lo descargué a través de http y lo subí al servidor a través de scp, ya que la carga del navegador lo rechazó.
Sí, acabo de ejecutar un comando para inspeccionar el contenido del tarball y solo contiene imágenes, no un volcado de SQL.
¿Puedes verificar si los tamaños del tarball son exactamente los mismos?
- en la instancia de CDCK
- el descargado
- el que subiste usando scp
Es posible que quieras usar tar tfvz para verificar si el archivo no está truncado.
Es posible que quieras verificar si te estás quedando sin espacio en disco en algún lugar, ya que necesita un múltiplo del tamaño del archivo.
Ok, he salido un momento pero revisaré más tarde. El espacio no debería ser un problema ya que tengo 512 GB y el archivo de copia de seguridad es de 70 GB. Me sorprendió que el archivo fuera unos pocos GB más pequeño que el último que creamos, esperaba que fuera un poco más grande. Estoy bastante seguro de que por alguna razón no ha incluido la volcada de SQL, que sería la diferencia de tamaño.
Hola @pfaffman @RGJ, solo una actualización sobre cómo ha progresado esto. El volcado de SQL efectivamente faltaba en el archivo descargado, y no estaba seguro de si hacer una copia de seguridad separada de la base de datos e insertarla en el archivo funcionaría (y llevaría varias horas probarlo). Así que terminamos restaurando la base de datos y migrando (con éxito).
El problema ahora es que tan pronto como Discourse desmantele todo y apague el bucket S3 / CDN, todas nuestras imágenes históricas se romperán.
Tengo todas las imágenes y creo que podré subirlas todas a nuestro bucket S3 manteniendo la misma estructura de carpetas. He visto algunos hilos discutiendo la posibilidad de usar discourse.remap / dbhelper.remap para actualizar masivamente los enlaces a nivel de base de datos. ¡Cualquier comentario al respecto será muy apreciado!
No puedo imaginar cómo pudo haber sucedido eso. ¿Tu navegador descomprimió y desempaquetó la copia de seguridad de alguna manera y trataste de volver a armarla?
Puedes pedirle a la gente de discourse.org que te dé una copia de seguridad que incluya las cargas. Eso es lo que quieres hacer. Activan una configuración include_s3_uploads_in_backup (eso está cerca, pero casi con certeza no es el nombre de la configuración oculta).
También puedes ingeniártelas para usar herramientas de S3 para bajarlas todas de su bucket y subirlas de nuevo. Hay un par de temas sobre eso. No lo recomiendo.
Recientemente migré una copia de seguridad de aproximadamente 100 GB de CDCK a Digital Ocean, droplet, bucket de espacios y CDN de bunny.net por $1000. Lo lamenté.
¿Es solo la base de datos?
Oh, ¿hiciste de alguna manera una restauración solo de la base de datos a pesar de tener las imágenes en el archivo tar?
Necesitas hacer la restauración del archivo exacto que hicieron y que Discourse lo restaure. El que tiene la base de datos y las cargas. O puedes mirar el código de restauración e ingeniártelas para hacer a mano las cosas que hace para reasignar las imágenes a la nueva ubicación. Aunque creo que Richard tiene las habilidades y herramientas para hacerlo, no creo que quieras hacerlo de esa manera.
Hicimos una prueba hace un par de meses y todo salió bien. Creo que dejaron activada esa configuración oculta, ya que esta vez pude activar una copia de seguridad que incluía cargas desde el backend, aunque después de unas 12 horas recibimos una notificación de que había fallado. Luego me puse en contacto con Discourse y dijeron que crearían la copia de seguridad desde su extremo. Un par de horas después, la copia de seguridad que había iniciado pareció completarse, aunque descartamos el archivo según lo aconsejado por Discourse. Luego se encontraron con una serie de problemas con las copias de seguridad que caducaban y devolvían errores, antes de decirnos finalmente que había un archivo completo. Pero cuando intenté restaurar el archivo, después de tardar varias horas en extraer el archivo, se quejó de que faltaba el volcado. Al inspeccionar el archivo usando tar -tf se confirmó que no había ningún volcado allí (mirando otras copias de seguridad completas, normalmente es el primer archivo en el archivo). Como era domingo, no pude ponerme en contacto con Discourse, y habíamos prometido completar la migración el lunes por la mañana, así que hice una copia de seguridad solo de la base de datos (unos 7 GB) y la utilicé para migrar.
Discourse está intentando ayudar, pero realmente solo pueden hacer mucho ahora, ya que hemos completado la migración y hemos estado en nuestro entorno autoalojado desde el domingo por la tarde. La solución más fácil sería que mantuvieran activo nuestro bucket S3 y CDN (por una tarifa), pero han dicho que esto no es posible. Supongo que tendremos que perder las imágenes históricas, la verdad.
Esto se puede arreglar. Simplemente descarga el contenido del bucket S3 en tu directorio de subidas local y luego realiza una remap en tu base de datos, reescribiendo las URL de la CDN y del bucket a la URL de tu instancia.
1 me gusta
Un par de problemas: el tamaño de las imágenes subidas agotaría el SSD de nuestro nuevo VPS, y no tenemos la capacidad de adjuntar un disco adicional. Quizás podríamos tomar un subconjunto, aunque no estoy seguro de cómo funcionaría esto al ver la estructura del directorio. Además, ya hemos configurado el sitio para usar S3 para las subidas en lugar del almacenamiento local.
Ok, ¿entonces copias su S3 (o una copia de seguridad de S3) a tu S3 y remapeas?
1 me gusta
¡Sí, eso es lo que espero que sea posible!
1 me gusta
Ah. Ya veo. Sí, una vez que has salido en vivo, estás comprometido. Todavía es muy posible mover los archivos a S3 antes de que se eliminen.
Siempre necesitaste tener suficiente espacio para guardar todas las imágenes para hacer la restauración. Podrías copiar las imágenes una por una. También hay herramientas que copian los archivos directamente, creo.
El plan original era usar una VM temporal de Azure para restaurar, con un disco grande adjunto, luego enviarlo de vuelta a S3, hacer otra copia de seguridad una vez completado y finalmente moverlo a nuestro VPS (intentando mantener los costos bajos).
Así que tengo un tar.gz que contiene todas las cargas y puedo introducirlas directamente en nuestro bucket de S3 manteniendo la estructura de directorios (creo que el cargador estándar de AWS puede hacerlo hoy en día, si no, está la CLI). Podría haber alguna consideración sobre la propiedad/permisos, aunque quizás no.
Después de eso sería la reasignación, no estoy seguro de la diferencia entre discourse.remap y dbhelper.remap. Intentaría probar todo esto en una instalación ficticia con un par de archivos primero.
1 me gusta