Respaldo de emergencia - línea directa a la línea de comandos del contenedor

Aprendí algo que puede ayudar a otros.

Antecedentes: Como se detalla en otro lugar, mi instalación de Discourse estaba alojada en un VPS cuyo disco era demasiado pequeño para completar una actualización. Al principio, hice clic en “Actualizar” en el panel de control de administración. La actualización falló y la GUI nunca volvió a funcionar. Después de eso, inicié sesión en la consola de mi VPS y ejecuté el famoso comando ./launcher rebuild app. Eso tampoco se completó: me había quedado decisivamente sin espacio en disco. Para obtener más espacio y mantenerme dentro del presupuesto, decidí mover toda mi configuración a un nuevo VPS con una empresa de alojamiento diferente. Salvar los preciosos datos del sitio era una alta prioridad.

Fallos: Los dos métodos más obvios para hacer una copia de seguridad no funcionaron:

  • mi intento original de actualizar rompió la GUI basada en web, por lo que no había forma de acceder al panel de control de administración e iniciar una copia de seguridad desde allí; y
  • intentar entrar en el contenedor de docker y darle algunos comandos de shell tampoco funcionó. El comando recomendado para esto es /var/discourse/launcher enter app. Pero, al menos en mi caso, el script launcher intentaría reconstruir la aplicación antes de dejarme entrar, y las reconstrucciones fallaban constantemente, por lo que este comando ni siquiera me dio un contenedor, y mucho menos un shell dentro de él.

Éxito: Estaba a punto de rendirme cuando me llevé una grata sorpresa. Trabajando en la línea de comandos de mi pequeña VM, ejecuté docker ps y descubrí que había un contenedor activo llamado app. Y docker tiene una forma directa de entrar en un contenedor en ejecución: el comando es docker exec -it app bash.

Dentro del contenedor, pude progresar: emití el comando discourse backup, esperé unos minutos y luego copié el archivo <backup>.tar.gz a una ubicación segura y nueva. Con una copia de seguridad actual en mano, fue posible terminar de migrar mi configuración a su nuevo hogar. (Hay otros hilos en estos foros que muestran cómo hacer esto).

El punto clave aquí es que el comando docker anterior para entrar en el contenedor funcionó, incluso cuando el comando específico de Discourse ./launcher no lo hizo.

Gracias a los inventores y mantenedores de este excelente producto.

3 Me gusta

¿Probaste

./launcher cleanup

¿O eliminar algunas copias de seguridad?

1 me gusta

Gracias por preguntar.

Durante los días en que intentaba que mi configuración original funcionara, pensé que había hecho todo lo posible para recuperar espacio, ciertamente incluyendo ./launcher cleanup, pero también mucho más… eliminando kernels antiguos, limpiando la caché de apt, desechando software no esencial, etc., etc.

Después de decidirme a trasladar todo mi sitio y dedicarle mucho tiempo al proceso, me pregunté si podría haber hecho más… pero para entonces había perdido el impulso para investigar más. (cf. “falacia del costo hundido”). Para ser específico, el VPS que estoy a punto de abandonar tenía un tamaño de disco nominal de 25G. Aproximadamente 19G de eso estaban dedicados al directorio /var/lib/docker/overlay2. Y los únicos contenedores de docker que estaba ejecutando eran Discourse y su receptor de correo asociado. La experiencia sugiere que Discourse, a pesar de ser potente, debería poder ejecutarse con mucho menos de 19G en el disco. Pero las búsquedas en Internet parecían indicar que hacer cambios dentro del directorio overlay2 no era seguro, así que me sentí detenido en ese punto.

En mi nueva configuración, el directorio /var/lib/docker/overlay2 ocupa 13G. Sigue siendo enorme.

Elegí Discourse para ejecutar los foros en mi sitio web de pasatiempo a pequeña escala con la esperanza de que “simplemente funcionara”, es decir, que fuera súper simple de administrar sin tener que aprender un montón de cosas nuevas. Esto parece ser en gran medida correcto, si se tienen suficientes (¿excesivos?) recursos para asignar.

Mi nuevo plan es esperar ciegamente que el directorio overlay2 no crezca con el tiempo y desborde el disco de 50G en mi nuevo VPS. Si usted (o cualquier otra persona) sabe cómo mantener bajo control el tamaño del dúo dinámico de docker y Discourse, me encantaría saberlo. Sería una buena culminación del resto del aprendizaje que he hecho en los últimos días. Gracias de nuevo.

Me alegro de que hayas podido salir de allí por tu cuenta. Dirijo dos foros pequeños, uno sobre almacenamiento de 20G y otro sobre 25G. Tengo que dedicar bastante tiempo e ingenio a veces para que funcionen. Pero también parece que sigo usando (y publicando sobre) el mismo conjunto de tácticas. Ver abajo.

El desarrollo de Discourse se optimiza para cosas distintas de funcionar en hardware de bajo costo, aunque apenas se las arregla para seguir funcionando para mí en mi entorno limitado. Que así sea por mucho tiempo.

La clave para trabajar en configuraciones de almacenamiento pequeño es medir lo que está sucediendo; con demasiada frecuencia veo a personas adivinando lo que podría estar sucediendo. Mi enfoque siempre comenzará con

Para más información, quizás busca en mis publicaciones prune y journalctl y kernel.

2 Me gusta