He buscado en Support pero no encontré una respuesta existente, así que disculpen por esta pregunta rápida de soporte:
Hemos estado usando S3 para almacenar archivos de Discourse desde aproximadamente 2016. Cuando miro la raíz del bucket de S3, me sorprendió ver la estructura de directorios “encima” de los que esperaba encontrar, por ejemplo: optimized/, original/, etc.
¿Creen que es seguro eliminar los directorios numerados en la raíz, como 99/, debido quizás a una copia errónea que ocurrió hace mucho tiempo? Es posible que se hayan copiado hace mucho tiempo al lugar incorrecto. ¿Es posible que las publicaciones tengan rutas antiguas “incrustadas” a esas ubicaciones que no quiero romper?
Así es como se ve, y mi objetivo es limpiarlo (si es que necesita limpieza en absoluto):
Creo que también podemos ser un poco extraños en el sentido de que hemos estado ejecutando Discourse desde aproximadamente 2015 y hemos cambiado las ubicaciones de almacenamiento a lo largo de los años.
Comenzamos usando almacenamiento local para los archivos, experimentamos cierto crecimiento y luego pasamos a usar cargas almacenadas en S3. En ese momento, creo que no movimos las existentes mediante la reconstrucción de las publicaciones, por lo que las publicaciones más antiguas aún utilizan las URL de almacenamiento no local.
Una cosa que debo señalar es que no vamos a eliminar nada tal como está ahora mismo, porque incluso si la organización ha cambiado a lo largo de los años, estamos hablando de números pequeños, por lo que es más seguro dejar lo que ya tenemos.
Además, un montón de directorios numerados que van desde 1/ hasta 225/. Cada directorio numerado contiene un solo archivo de imagen con un nombre como ‘874c0706216382af.jpg’.
Tombstone tiene una regla de ciclo de vida en S3 para marcarlo como eliminado después de 30 días.
Adivinando, ¿es solo optimized/, original/ y tombstone/ los que se usan?
Esos archivos siempre están presentes en foros muy antiguos (alrededor de 2014). Creo que son anteriores a optimized y original, y sospecho que aún se les sigue haciendo referencia.
No pude resistirme a averiguar esto. Este es, de hecho, un esquema de carga antiguo. Fue abandonado más tarde de lo que sospechaba, en mayo de 2015, con este commit.
Gracias, Michael. Como estos archivos corresponden al inicio de nuestras actividades en 2014, los números de archivo son bajos y los mantendremos tal como están.
Curiosamente, recientemente cambiamos de servidor y optamos por un proceso de respaldo y restauración de Discourse (en lugar de una actualización in situ de la versión base de Unix). Creo (aunque no estoy 100% seguro) que la restauración no colocó correctamente estos archivos locales. Estaban incluidos en el archivo de respaldo, pero el proceso de restauración solo pareció funcionar para los archivos optimizados y originales de niveles inferiores.
No fue un gran problema, ya que pudimos extraerlos nosotros mismos del archivo de respaldo con tar -x (cuando notamos que los servidores antiguo y nuevo diferían en sus subidas y contenidos), pero es algo que podría causar problemas a alguien, así que quería mencionarlo aquí.
Aunque el 99,9% de nuestras subidas ahora se sirven desde S3 (cambiamos de almacenamiento local a S3 bastante temprano), creo que debemos haber copiado los archivos locales al crear manualmente el bucket de S3 inicialmente. En retrospectiva, probablemente deberíamos haber regenerado las publicaciones, pero siempre funcionó lo suficientemente bien, ya que las publicaciones muy antiguas y pequeñas tenían la URL de subida de archivo local.
en el sentido de que hemos estado ejecutando Discourse desde aproximadamente 2015 y hemos cambiado las ubicaciones de almacenamiento a lo largo de los años.