Este tema evolucionó más tarde a ‘Restaurar fallos’ a partir de la 4ª publicación en adelante, que es el problema principal ahora. Puede ignorar las primeras 4 publicaciones.
Configuré mis cargas en Aws S3 hace años/al principio.
Incluso cuando (hasta donde puedo decir) nunca habilité la opción para incluir las cargas de S3 en mis copias de seguridad, ayer, cuando elegí incluir ‘Cargas’ en mis copias de seguridad, obtuve esto en mis registros:
Surge una serie de curiosas discrepancias que me desconciertan:
Ayer por la tarde, activé la opción en mi Configuración de administrador para incluir ‘Cargas’ en mis copias de seguridad. Y luego, cuando vi mi carpeta local ‘Cargas compartidas’ a través de WinScp, solo tenía menos de 100 archivos en solo 1 carpeta (no existen otras carpetas 2x, 3x allí, puedo compartir capturas de pantalla si es necesario). Entonces, ¿por qué los registros de copia de seguridad muestran que se descargaron alrededor de 3000 archivos? (‘Error al descargar’ es otro dolor de cabeza/problema en estos registros, pero eso es ‘otro’). Ahora, si está descargando estos archivos del almacenamiento local, ¿dónde existen tantos archivos? Y si está descargando de S3, entonces, a, ¿por qué está descargando de allí, porque nunca cambié esa opción en la consola de Rails para incluir datos de S3 en las copias de seguridad, ni creé ninguna opción similar en la sección Env de mi archivo yml?
Luego, hoy cambié esa opción en la consola de Rails a ‘Verdadero’. Y ahora, cuando ejecuté el trabajo de copia de seguridad, mostró los mismos alrededor de 3.2k archivos descargados, alrededor de 100 ‘Error al descargar’. Pero cuando lo verifiqué en mi bucket de Aws S3, tenía casi 10 veces más, 32k archivos de alrededor de 3 GB. Entonces, ¿por qué no está descargando todos esos archivos?
¿No hay una forma de cotejar/sincronizar todos estos datos y, posiblemente, saber qué discrepancias están ocurriendo y dónde?
Ahora estoy muy desconcertado, ¿qué debo hacer? Mi objetivo final es cambiar mi (demasiado costoso) almacenamiento de AWS a una versión más barata (Hetzner mismo, donde se ejecuta mi VPS, es muy, muy económico, por lo que también puedo aumentar el almacenamiento de mi servidor principal).
Incluso cuando mi carpeta ‘Uploads’ (en el bucket de Aws S3) tiene más de 3 GB (3,2k archivos), ¿por qué las copias de seguridad son de poco menos de 1 GB (con solo 2,9k archivos descargados en la copia de seguridad), incluso después de habilitar la opción ‘include_s3_uploads_in_backup’ a través de la consola de Rails?
Esa configuración descarga los archivos a un directorio temporal y los incluye en la copia de seguridad. No los pone en el directorio de subidas. Para que estén en el directorio de subidas, necesitas restaurar la copia de seguridad. Lo haría en un servidor nuevo para que, si algo sale mal, tu servidor original siga intacto.
Parece que faltan algunos archivos. ¿Tienes publicaciones con imágenes faltantes? Otra posibilidad es que la tabla de subidas incluya subidas que ya no se referencian en las publicaciones, por lo que esas imágenes faltantes no importan.
Si son solo unos 100, probablemente no sea gran cosa.
O podría ser que un error en algún momento haya limpiado (eliminado) archivos que deberían haberse conservado.
Para ver los archivos que descargó, necesitarás descargar el archivo de copia de seguridad y ver qué incluye. Restaura tu copia de seguridad en un servidor nuevo para ver cómo funciona.
Pero el punto principal es por qué la copia de seguridad es de poco menos de 1 GB (con solo 3100 archivos) incluso cuando la carpeta ‘Uploads’ de S3 por sí sola es de 3.2 GB y 32K archivos. (los registros de copia de seguridad muestran claramente que descargó alrededor del 10%, 3k archivos).
[Me resulta muy engorroso crear una nueva configuración de discourse con un dominio diferente para probar esto, aunque me resulta muy fácil crear una instantánea y luego, si es necesario, revertir mi sitio, muy poco concurrido, en 5 minutos sin ningún problema]
Bueno, pensé que incluso después de cambiar la opción en Rails C, por qué no añadir esta línea en yml también DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true pensando que tal vez esto llamaría a todas mis cargas desde Aws S3.
Pero después de cambiar esta opción en yml, reconstruir el contenedor, ejecutar la copia de seguridad, encontré las mismas líneas en los registros de copia de seguridad (3000 descargas de medios con alrededor de 100 fallos).
Y cuando intenté restaurar (aún no había cambiado ninguna configuración de carga/S3 en mi configuración de administrador), dio un error.
Registro completo:
Así que deshabilité las cargas de S3 e intenté restaurar mi copia de seguridad de 1 GB (la copia de seguridad todavía está en Aws S3), y volvió a fallar. ¿Qué puede salir mal aquí?
Además, después de que la restauración fallara, cerré sesión y, cuando volví a iniciar sesión, se me mostró un banner que indicaba que todos los correos electrónicos que no son del personal están deshabilitados. Y cuando intenté acceder al registro desde el enlace recibido en mi correo electrónico, ese archivo no se encuentra/es inaccesible (se muestra mi página de error configurada).
Cuando estaba intentando restaurar, justo antes de que cerrara sesión, estaba viendo estos mensajes de registro:
[2024-08-19 04:12:58] ¡'Bathinda_Helper' ha iniciado la restauración!
[2024-08-19 04:12:58] Marcando la restauración como en curso...
[2024-08-19 04:12:58] Asegurándose de que /var/www/discourse/tmp/restores/default/2024-08-19-041258 existe...
[2024-08-19 04:12:59] Descargando el archivo al directorio tmp...
En el siguiente intento ‘FAILED-restore’, pude hacer clic en el enlace del registro justo antes de que cerrara la sesión. Aquí está: log- failed restore.txt (98.9 KB)
He experimentado que se están creando nuevas cargas en mi servidor local de Ubuntu. Pero la restauración de S3 a local está fallando. Pero la cosa es que algunas publicaciones que he revisado todavía continúan mostrando las imágenes de S3 (esas no faltan).
Por favor, ayuda. La restauración está fallando de nuevo.
Además, después de ‘Restauración fallida’, incluso cuando inicio sesión con el mismo administrador, no puedo acceder al archivo adjunto ‘Log.txt’. En su lugar, muestra la página no disponible / la página de error de mi configuración.
En realidad, intenté hacer exactamente lo mismo que en tus capturas de pantalla en la publicación mencionada justo arriba. De todos modos, ahora solo haré esta ‘restauración de Discourse’.
Según lo que he entendido/espero, no necesito proporcionar ninguna ruta al archivo de copia de seguridad (.tz) que se encuentre en cualquier lugar, sino que lo recogerá automáticamente de la carpeta de copias de seguridad de mi servidor local.
