Encontrando backup gerado por UI e restaurando site

Olá Discourse,

Ontem à noite, enquanto avançava com as atualizações do Discourse e recriava o aplicativo, acabei com uma série de erros do Postgres. Percebi que isso era resultado da atualização recente, mas continuava recebendo erros de “permissão negada”, entre outros (e sim, eu alterei as permissões de tudo para 700, então não era algo global). Então, movi meu diretório original /var/discourse para um local que deveria ser temporário e reinstalei uma nova instância do Discourse para tentar, pelo menos, atualizar o Postgres.

É aí que a coisa fica interessante. Eu tinha um backup do site (apenas do banco de dados, os uploads estão salvos em um volume diferente) gerado pela interface há três dias. Ou pelo menos, eu achava que tinha. O que tenho agora é um arquivo chamado wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz, que, pelo que aprendi, não é, de fato, o arquivo tar.gz no qual o backup real deveria estar.

No momento, redirecionei todos para uma página de aterrissagem e estou esperando que alguém possa me dizer se ainda é possível recuperar o arquivo .tar.gz real do servidor de três dias atrás e, exatamente, como devo proceder para fazer isso.

Tenho meus backups e uploads salvos no armazenamento em bloco da Digital Ocean, e ainda possuo a pasta do Discourse da minha instalação antiga que funcionava, mas movê-la/copiá-la de volta para /var/discourse apenas quebra tudo novamente, incluindo erros do Postgres. Estou trabalhando nisso há 9 horas seguidas e estou quase sem ideias. Alguém pode me ajudar, ou pelo menos tentar me apontar na direção certa? :pray: Acabamos de atingir a marca de 1.000 usuários e eu realmente, realmente gostaria de evitar perder tudo isso.

Editado para corrigir minha configuração de upload.

Se você tiver sua configuração do S3 no app.yml, basta executar uma restauração pela linha de comando e o backup será recuperado do S3.
Como seus ativos estão no S3, o backup contém apenas o banco de dados.

Você deve ser capaz de clonar um novo /var/discourse, copiar seu arquivo yml, reconstruir e executar a restauração pela linha de comando.

Usando armazenamento de objetos para uploads (S3 e clones)

Restaurar um backup pela linha de comando

Acho que estou usando o termo errado para descrever como meus backups e uploads estão configurados. Usei este método: Move Uploads and Backups to DigitalOcean Block Storage

Vou corrigir e dizer que meus uploads e backups não estão locais à pasta principal do Discourse (fois parcialmente assim que tudo começou, eu estava tentando migrar para o DigitalOcean Spaces). Então, não, infelizmente, não tenho nenhuma configuração do S3 feita, pois estava apenas salvando em armazenamento montado.

Os backups estavam sendo salvos em mnt/my_storage/shared/standalone, mas quando vou procurar os backups lá, só tenho o arquivo wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz. Na verdade, tentei restaurar a partir dele por falta de uma ideia melhor (o que provavelmente estava errado), mas recebi um erro de permissão negada. Tenho certeza de que está relacionado à forma como esses backups são realmente gerados.

Então, seus uploads ainda estão no armazenamento de blocos DO?

Sim, todos os uploads estão intactos.

Ok, bom.

Então, nesse caso, você deve conseguir restaurar o arquivo SQL e, em seguida, remontar o volume de armazenamento em bloco para recuperar seus uploads.

Existem dois tipos de backups: sql.gz, que não inclui uploads, e tar.gz, que inclui uploads. Portanto, você tinha o tipo errado de backup, mas o fato de ter os uploads em um volume externo salvou você.

2 curtidas

Então, entro no app e restauro esse sql.gz, mas recebo um erro de permissão negada. Alguma ideia do porquê isso pode estar acontecendo?

Você está dizendo!! :slight_smile:

(Assumindo que você quis dizer chmod). Se os arquivos estiverem com o proprietário incorreto, eles não serão graváveis.

Acho que isso pode ter causado o erro de permissão negada.

Qual é o erro exato?

Sim, obrigado. Fiquei acordado a noite toda e estou um pouco zumbi.

EXCEÇÃO: lib/discourse.rb:93:in `exec': Falha ao copiar o arquivo compactado para o diretório tmp.
cp: não foi possível abrir '/var/www/discourse/public/backups/default/wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz' para leitura: Permissão negada

Tente chmod 644 /var/www/discourse/public/backups/default/*

2 curtidas

Ok, estou trabalhando nisso agora e volto a falar em breve. Obrigado por dedicar tempo para me ajudar.

Isso funcionou para iniciar a restauração, OBRIGADO. :pray:

Agora só preciso descobrir por que o site ainda não está carregando. :grimacing:

Reconstrução em andamento com o arquivo app.yml salvo de antes de tudo quebrar.

1 curtida

Existe algum comando para mover esse backup diretamente para o aplicativo? O Restore não está encontrando e não me lembro como fiz para carregá-lo antes.

Você pode baixá-lo do S3 e colocá-lo em

/var/discourse/shared/standalone/backups/default

Você deverá conseguir restaurar pela linha de comando.

Mas, após isso, configure sua configuração do S3 conforme descrito no link acima; isso facilita as coisas.

2 curtidas

Obrigado, Jay. E sim, esse é absolutamente o meu plano.

1 curtida

Ok, então aqui é onde estou agora.

  • A restauração foi bem-sucedida a partir daquele arquivo .sql.gz. (Uhuu! Obrigado novamente, Richard.)
  • Garanti que o app.yml tivesse a mesma configuração de antes de tudo dar errado
  • ./launcher rebuild app
  • A reconstrução foi bem-sucedida com o Postgres 13 (finalmente)

No entanto, acessar o site em si ainda está fora do ar. Uso o Cloudflare, mas tenho o Modo de Desenvolvimento ativado agora e limpei o cache de DNS. Tudo está apontando para onde deveria. O template do Cloudflare está no app.yml.

O DNS está resolvendo corretamente, os hostnames estão atualizados, a instalação do Discourse foi feita com a URL apropriada e estou ficando sem ideias.

https://forum.wackywriters.com é a URL, e estou recebendo apenas erros de “servidor indisponível”. Sinto como se estivesse dando voltas aqui (desculpe), mas alguma sugestão?

Edição: Quando executo ./discourse-doctor, vejo que há duas instâncias do app rodando no Docker:

Isso é normal? (Parece que não seria, mas tudo o que eu pensava saber sobre o Discourse foi jogado fora nas últimas 24 horas :sweat_smile:)

Edição 2: Estive adiando isso como último recurso, mas vou tentar configurar um servidor totalmente novo com uma instalação limpa do Discourse. Estou preocupado que algo tenha saído do controle com toda a minha bagunça e não consigo descobrir o que está quebrado. Felizmente, ainda tenho o backup e todos os uploads no armazenamento em bloco, então, se tiver sorte, devo conseguir conectar isso a um novo droplet e mover as coisas de lá. Se alguém tiver sugestões ou dicas adicionais, ainda apreciaria mais experiência do que a minha.

Edição 3: Mesmo com um novo servidor e IP propagando (nslookup e ping estão bons, whatsmydns.net também), o fórum não carrega. Ainda estou recebendo erros de conexão. É como se não estivesse conectando o endereço IP à instância do Discourse e, em vez disso, estivesse tentando carregar uma página estática, que, claro, não existe neste caso.

Então, após quase 24 horas de luta, descobri por que o site se recusava a carregar depois que iniciei o processo de restauração.
:point_down:

Devido a tantos resetes, reinstalações e Deus sabe o que mais, atingi o limite de taxa. Por isso, comentei temporariamente os modelos SSL e os reativarei em uma semana.

O site está “funcionando” enquanto reprocesso todos os posts para corrigir as imagens quebradas, mas agradeço muito ao Jay e ao Richard por me ajudarem hoje. Vocês me ajudaram a superar as partes que eu realmente não conseguia resolver.

Agora, preciso baixar um backup real para configurar o S3 esta semana sem me preocupar com isso novamente. :sweat_smile:

1 curtida

Se você pesquisar, há uma maneira de adicionar um segundo domínio, de modo que ele seja contado como uma solicitação separada para o Let’s Encrypt. Mas esperar é mais fácil.

Recomendo que você coloque o Cloudflare em modo de nuvem cinza, sem aceleração.

1 curtida

@pfaffman Você não está confundindo armazenamento de objetos com armazenamento em bloco? Armazenamento de objetos é o S3, mas o TS disse que usaram armazenamento em bloco, que é apenas um disco montado no diretório de uploads deles:

1 curtida

Ah. :man_facepalming:

É. Então nada do que eu disse faz sentido.

Obrigado por notar isso, Richard.

2 curtidas

Bem, a maioria das coisas que você disse de fato fazia sentido, mas você me confundiu aqui :slight_smile:

2 curtidas