É improvável que você encontre alguém que entre no seu servidor e conserte tudo de graça. Muitas pessoas podem fazer isso, mas você precisará pagá-las. Acredito que @pfaffman ofereça serviços de recuperação, mas posso estar errado.
Se eu puder arcar com isso, estou pronto para pagar.
Você pressionou CTRL + C no meio do comando? Você deve esperar que ele termine completamente em vez de interrompê-lo no meio.
Eh, é possível que eu não tenha entendido a situação e tenha cometido um erro.
Ahem! Não sei por que você continua fazendo isso? Isso não vai ajudar 
Seja paciente e deixe terminar.
Ah, sim, não tenho certeza de como perdi isso… aí está o seu problema. Você não vai chegar muito longe se continuar interrompendo a reconstrução.. 
Uma reconstrução pode levar 20 minutos. No mínimo. A parte que você está cancelando com Control-C pode levar 5 minutos. Se você realmente esperou 10 minutos sem que nada acontecesse nessa etapa, deve informar isso.
Em uma máquina mais lenta, a reconstrução pode até levar muito mais tempo. Pode ser uma hora. Se fizer algo, certifique-se de anotar o horário e informar quanto tempo já se passou.
Isso não é um problema de build. É um problema do VPSmanager com o https://vds.eurobyte.ru/ - parece que eles ativaram um firewall que está bloqueando tanto os payloads de cadastro quanto o envio de arquivos. Analisei a configuração do nginx e ela está funcionando, mas os payloads POST estão sendo bloqueados antes de chegar ao servidor. Já conversei com o OP.
Sim, muito obrigado 
eu estava impaciente
Todos estamos impacientes com fóruns quebrados! Sem problema. Isso acabou sendo um problema interessante. 
edição: este é um fórum corporativo, então a impaciência era muito compreensível — ninguém gosta de tempo de inatividade, especialmente por horas.
correções:
- corrigido o problema de
containers/app.ymlser legível por todos e corrigido um problema de sintaxe no arquivoapp.yml - revisada/corrigida a configuração do firewall do nginx e dos provedores de ISP/VPS russos
- recuperados 25 GB de arquivos de imagem fantasma deixados no servidor por reconstruções incompletas ou falhas
- configurações de upload de arquivos do fórum atualizadas para 100 MB:
max attachment size kbemax image size kb - recomendada atualização do servidor de 2 GB para 4 GB de RAM; parece ser um fórum com muitas imagens, e o arquivo de swap está trabalhando muito, especialmente perceptível durante as reconstruções, razão pela qual o autor da postagem saiu quando parecia travado — as reconstruções estavam levando mais de 40 minutos
