Olá pessoal - no processo de tentar migrar do Discourse hospedado para auto-hospedagem. Fiz uma série de testes bem-sucedidos de várias coisas, mas quando tento fazer a migração real, incluindo todos os uploads, após algumas horas descompactando o arquivo, ele diz que não existe tal arquivo ou diretório ao tentar extrair o arquivo de dump. Então, agora estou enfrentando a perspectiva de perder cerca de 140 GB de uploads, a menos que alguém tenha alguma ideia?
Você pode fornecer o log?
Você está restaurando da linha de comando ou da interface web? Eu recomendo a interface web.
Olá - Anexei o log ao e-mail anterior, embora o anexe novamente aqui. Tentei primeiro usando a interface web e depois pela segunda vez via linha de comando. Suspeito que o backup possa estar corrompido de alguma forma, pois ele não é reconhecido quando enviado para o S3 e é rejeitado quase instantaneamente se eu tentar enviá-lo pelo navegador.
restore-failure-log.txt (3,28 KB)
É o que parece. Você fez o upload pelo navegador ou via scp/rsync? Eu faria o upload novamente com rsync.
Oi Jay - desculpe, fiquei um pouco confuso antes, pois também estivemos em discussões com a Discourse por e-mail durante todo o processo de migração, e foi lá que anexei o arquivo de log.
Analisando o erro, suspeito que o tarball não contenha um dump SQL, apenas imagens. O arquivo foi iniciado e verificado pela Discourse em nosso nome. Eu o baixei via http e o carreguei para o servidor via scp, pois o upload pelo navegador o rejeitou.
Sim, acabei de executar um comando para inspecionar o conteúdo do tarball e ele contém apenas imagens, nenhum dump SQL.
Você pode verificar se os tamanhos do tarball são exatamente os mesmos?
- na instância do CDCK
- o baixado
- o que você carregou usando scp
Você pode querer usar tar tfvz para verificar se o arquivo não está truncado.
Você pode querer verificar se você não está ficando sem espaço em disco em algum lugar, já que ele precisa de um múltiplo do tamanho do arquivo.
Ok, saí por um momento, mas verificarei mais tarde. O espaço não deve ser problema, pois tenho 512 GB e o arquivo de backup tem 70 GB. Fiquei surpreso que o arquivo fosse alguns GB menor que o último que criamos, esperava que fosse um pouco maior. Tenho certeza de que, por algum motivo, ele não incluiu o dump do SQL, o que seria a diferença de tamanho.
Olá @pfaffman @RGJ, apenas uma atualização sobre como isso progrediu. O dump SQL estava realmente faltando no arquivo baixado, e eu não tinha certeza se fazer um backup separado do banco de dados e inseri-lo no arquivo funcionaria (e levaria várias horas para testar). Então, acabamos restaurando o banco de dados e migrando (com sucesso).
O problema agora é que, assim que o Discourse desativar tudo e desligar o bucket S3 / CDN, todas as nossas imagens históricas quebrarão.
Eu tenho todas as imagens e acho que posso fazer o upload de todas para o nosso bucket S3, mantendo a mesma estrutura de pastas. Vi alguns tópicos discutindo a possibilidade de usar discourse.remap / dbhelper.remap para atualizar em massa os links no nível do banco de dados. Qualquer opinião sobre isso seria muito apreciada!
Não consigo imaginar como isso pôde ter acontecido. Seu navegador descompactou e descompactou o backup de alguma forma e você tentou juntá-lo novamente?
Você pode pedir ao pessoal do discourse.org para lhe dar um backup que inclua os uploads. É isso que você quer fazer. Eles ativam um include_s3_uploads_in_backup (isso é próximo, mas quase certamente não é o nome da configuração oculta).
Você também pode usar ferramentas S3 para baixá-los de seu bucket e enviá-los de volta. Existem alguns tópicos sobre isso. Eu não recomendo.
Recentemente migrei um backup de cerca de 100 GB do CDCK para o Digital Ocean, droplet, bucket de espaços e CDNs da bunny.net por US$ 1000. Fiquei arrependido.
Isso é apenas o banco de dados?
Ah, você fez alguma restauração apenas do banco de dados, mesmo tendo as imagens no arquivo tar?
Você precisa fazer a restauração do arquivo exato que eles fizeram e ter o Discourse restaurando-o. Aquele que tem o banco de dados e os uploads. Ou você pode olhar o código de restauração e criar uma forma de fazer manualmente as coisas que ele faz para remapear as imagens para o novo local. Embora eu pense que Richard tem as habilidades e ferramentas para fazer isso, não acho que você queira fazer dessa forma.
Fizemos um teste há alguns meses e tudo correu bem. Acho que eles deixaram essa configuração oculta ativada, pois desta vez consegui acionar um backup, incluindo uploads, pelo back-end, embora após cerca de 12 horas tenhamos recebido uma notificação de que ele falhou. Em seguida, entrei em contato com a Discourse e eles disseram que criariam o backup do lado deles. Algumas horas depois, o backup que eu havia iniciado pareceu ser concluído, embora tenhamos descartado o arquivo conforme aconselhado pela Discourse. Eles então encontraram vários problemas com timeouts de backup e retornos de erro, antes de finalmente nos dizerem que havia um arquivo completo. Mas quando tentei restaurar o arquivo, após várias horas para extrair o arquivo compactado, ele reclamou que o dump estava faltando. Inspecionar o arquivo usando tar -tf confirmou que não havia dump nele (olhando outros backups completos, ele é normalmente o primeiro arquivo no arquivo). Como era domingo, não consegui entrar em contato com a Discourse, e havíamos prometido concluir a migração até segunda-feira de manhã, então fiz um backup apenas do banco de dados (cerca de 7 GB) e o usei para migrar.
A Discourse está tentando ajudar, mas só há tanto que eles podem fazer agora, pois concluímos a migração e estamos em nosso ambiente auto-hospedado desde domingo à tarde. A solução mais fácil seria que eles mantivessem nosso bucket S3 e CDN ativos (mediante pagamento), mas eles disseram que isso não é possível. Acho que teremos que perder as imagens históricas, para ser sincero.
Isso é corrigível. Basta baixar o conteúdo do bucket S3 para o seu diretório de uploads local e, em seguida, executar um remap no seu banco de dados, reescrevendo os URLs do CDN e do bucket para o URL da sua instância.
1 curtida
Alguns problemas - o tamanho das imagens carregadas esgotaria o SSD em nosso novo VPS, e não temos a capacidade de anexar um disco adicional. Talvez pudéssemos apenas pegar um subconjunto, embora não tenha certeza de como isso funcionaria olhando para a estrutura do diretório. Além disso, já configuramos o site para usar S3 para uploads em vez de armazenamento local.
Ok, então copie o S3 deles (ou backup do S3) para o seu S3 e remapeie?
1 curtida
Sim, é isso que espero que seja possível!
1 curtida
Ah. Entendi. Sim, uma vez que você entrou no ar, está comprometido. Ainda é bem possível mover os arquivos para o S3 antes que eles sejam excluídos.
Você sempre precisou ter espaço suficiente para guardar todas as imagens para fazer a restauração. Você poderia copiar as imagens uma por uma. Existem também ferramentas que copiam os arquivos diretamente, acredito.
Sim, o plano original era usar uma VM temporária do Azure para restaurar, com um disco grande anexado, depois enviar de volta para o S3, fazer outro backup assim que concluído e, finalmente, mover para nosso VPS (tentando manter os custos baixos).
Então, eu tenho um tar.gz contendo todos os uploads e posso colocá-los diretamente em nosso bucket S3, mantendo a estrutura de diretórios (acho que o uploader padrão da AWS pode fazer isso hoje em dia, senão existe a CLI). Pode haver alguma consideração sobre propriedade/permissões, embora talvez não.
Depois disso, seria o remap - não tenho certeza da diferença entre discourse.remap e dbhelper.remap. Eu testaria tudo isso em uma instalação dummy com alguns arquivos primeiro.
1 curtida