Recover from filesystem backup: can't rebuild nor start

AI-generated summary

The user ulysses4ever is trying to recover a Discourse instance from a filesystem backup after a server RAID failure. They are encountering errors when running ./launcher rebuild app and ./launcher start app. Falco suggests using the official backup features and restoring a backup file, but ulysses4ever does not have a recent backup. Falco points out that backups are enabled by default and may be available in the backups folder. However, ulysses4ever finds only old backup tarballs.

Falco recommends moving the backup file to another server and following the restore process, but ulysses4ever only has a single server. Falco asks for more error output, which ulysses4ever provides in a link. The error output reveals that the Postgres cluster was not shut down cleanly.

Falco advises swapping the Postgres template in the app.yml file to postgres.12.template.yml to start the database without the upgrade, and then update afterwards. ulysses4ever confirms that this solution worked.

Server’s RAID died couple days back and we’re trying to bring back to life our Discourse instance from a filesystem backup. No luck so far.

I get this error message from ./launcher rebuild app:

FAILED
--------------------
Pups::ExecError: /root/upgrade_postgres failed with return #<Process::Status: pid 46 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params "/root/upgrade_postgres"

Its output claims that I should be able to just ./launcher start app, but it fails with:

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=3 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e DISCOURSE_DEVELOPER_EMAILS=bravit111@gmail.com,ulysses4ever@gmail.com -e DISCOURSE_HOSTNAME=forum.mmcs.sfedu.ru -e DISCOURSE_SMTP_ADDRESS=class.mmcs.sfedu.ru -e DISCOURSE_ENABLE_CORS=true -e 'DISCOURSE_CORS_ORIGIN=*' -e DONT_PRECOMPILE_CSS=1 -h users-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 8088:80 -p 2222:22 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:b1:c6:37:24:01 local_discourse/app /sbin/boot
Unable to find image 'local_discourse/app:latest' locally
docker: Error response from daemon: pull access denied for local_discourse/app, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.

Full output of both commands available here.

Just in case, my docker ps is empty.

I’m not sure how to proceed and will appreciate any help.

Why don’t you use our official backup features and restore a backup file to a new server?

That is our supported recovery method and it’s documented at Create download and restore a backup of your Discourse database

This method assumes you have a backup prepared by a running discourse instance. I don’t have one (anymore) :cry:

Backups are enabled by default and saved on the host file system. If you have a file system backup you have the backup files in the backups folder…

The backup feature doesn’t seem to have been enabled: I’m seeing only a couple of backup tarballs with rather old modification dates…

I believe weekly backup is on by default in a normal Discourse install.

I may end up using one of those but still I need a running instance and I keep getting those errors when trying to run it.

It a lot easier to move the backup file to another server and follow Restore a backup from the command line

How do you mean “another sever”: I only have a single server.

Okay, so let’s take a step back.

When you issue a rebuild, you end up with a error. Can you paste more than just 4 lines of error so we know exactly what is failing?

You maybe missed it because I added the link to the full output only in an update to the top post:

Full output of both commands available here.

Oh cool!

So

The source cluster was not shut down cleanly.

You will need to follow this

to start the database without the upgrade first, and then do the update afterwards.

It worked, thanks a lot!