Ao tentar executar backups do sistema, recebo a seguinte mensagem: “O backup falhou. Verifique os logs.”
O log relata: pg_dump: [archiver (db)] conexão com o banco de dados "discoursedb" falhou: não foi possível conectar ao servidor: Connection refused
Acredito que podem haver dois problemas envolvidos:
O servidor remoto está rodando em uma porta não padrão.
O PostgreSQL remoto está executando uma versão mais recente do PSQL.
Ao acessar o app (/var/discourse/launcher enter app) e executar um backup manual, observei que, inicialmente, sem a definição da porta, obtive exatamente o mesmo erro:
$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: [archiver (db)] conexão com o banco de dados "discourse_db" falhou: não foi possível conectar ao servidor: Connection refused
O servidor está rodando no host "123.456.789.101" e aceitando
conexões TCP/IP na porta 5432?
Isso foi resolvido facilmente (EXCETO que não sei como forçar o Discourse a usar a porta correta nos backups). No entanto, o próximo problema foi um pouco mais preocupante: estamos usando uma versão mais recente do PSQL no servidor de banco de dados:
$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: versão do servidor: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); versão do pg_dump: 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump: abortando devido a incompatibilidade de versão do servidor
O que pode ser feito nessa situação? Existe alguma maneira de tornar o backup do sistema funcional nesse caso, ou o Discourse e o banco de dados PostgreSQL precisam ser feitos separadamente?
Se a segunda opção for a única viável, qual é a maneira CORRETA de fazer backup, pelo menos, dos dados? Existe algum mecanismo coeso preferencial disponível para realizar ambos ao mesmo tempo, sem a necessidade de escrever um novo script para isso?
I did find some discussion in another post regarding someone who has a slightly comparable situation. The big difference in my case is that we store files on the local server vs S3. I could forego backing up PostgreSQL since that is backed up independently, however I do still need to back up:
local content and
Discourse settings
I still would like a consolidated backup with the db + content + settings all in one place, but I’m guessing you don’t/won’t support that and thus I’d like to at least get content + settings into a consolidated package.
Interesting and odd. I had read somewhere that 11 was alright, but aside from that I have a system already deployed to 11 and have not seen any errors or problems (aside from backup) thus far… Now you have me worried…
Yes. I’ve got two systems deployed on pg11 too. They are working fine except I’m doing backups directly. I upgraded pg to 11 in the container. They’ll make backups but not restore them.
The Discourse backup system should simply warn and not fail if there is a PostgreSQL version mismatch. I just tried to make a backup myself and because I too am using an external PG server, no tarball was created at all.
O mesmo problema aconteceu comigo. Movi o banco de dados postgresql para um servidor separado e comecei a receber um erro de backup. Encontrei a solução excluindo e reinstalando o postgresql no docker no servidor principal.
cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql