Es poco probable que encuentres a alguien que entre a tu servidor y lo repare todo por ti gratis. Muchas personas pueden hacerlo, pero tendrás que pagarles. Creo que @pfaffman ofrece servicios de recuperación, pero puede que esté equivocado.
Si puedo permitírmelo, estoy dispuesto a pagar.
¿Presionaste CTRL + C en medio del comando? Deberías esperar a que termine completamente en lugar de detenerlo a mitad de camino.
Jefe, es posible que no haya entendido la situación y haya cometido un error.
¡Ejem! No estoy seguro de por qué sigues haciendo eso. No ayudará 
Ten paciencia y deja que termine.
Ah, sí, no estoy seguro de cómo me lo perdí… ahí está tu problema. No llegarás muy lejos si sigues interrumpiendo la reconstrucción… 
Una reconstrucción puede tardar 20 minutos. Como mínimo. La parte que estás cancelando con Control-C puede tardar 5 minutos. Si realmente has esperado 10 minutos sin que ocurra nada en esa etapa, deberías mencionarlo.
En una máquina más lenta, la reconstrucción podría incluso tardar mucho más. Podría ser una hora. Si haces algo, asegúrate de anotar la hora y indicar cuánto tiempo ha transcurrido.
Esto no es un problema de compilación. Es un problema de VPSmanager con https://vds.eurobyte.ru/; parece que han activado un firewall que está bloqueando las cargas de datos de registro, así como las subidas de archivos. Revisé la configuración de nginx y funciona correctamente, pero las cargas de datos POST están siendo bloqueadas antes de llegar al servidor. Ya he hablado con el OP.
Sí, muchas gracias 
estaba impaciente.
¡Todos estamos impacientes con los foros rotos! No hay problema. Resultó ser un tema interesante. 
edición: este es un foro de empresa, así que la impaciencia era muy comprensible; a nadie le gusta el tiempo de inactividad, especialmente durante horas.
soluciones:
- se corrigió que el archivo
containers/app.ymlfuera legible por todos y se solucionó un problema de sintaxis en el archivoapp.yml - se revisó y corrigió la configuración del firewall de nginx y del proveedor de servicios de internet/vps ruso
- se recuperaron 25 GB de archivos de imagen fantasma limpios que quedaron en el servidor debido a reconstrucciones incompletas o fallidas
- se actualizaron la configuración de carga de archivos del foro a 100 MB:
max attachment size kbymax image size kb - se recomienda actualizar el servidor de 2 GB a 4 GB de RAM; parece ser un foro con muchas imágenes y el archivo de intercambio está trabajando muy duro, especialmente durante las reconstrucciones, razón por la cual el OP se desconectaba cuando parecía que se quedaba colgado: las reconstrucciones tardaban más de 40 minutos
