Avatars lost after restore. How to get them back?

I have made a clean install of discourse an restored the backup that was taken this same night (using the discourse interface to do the backup and restore).

The backup was made of the database and uploads.

After restore and rebuild for the discourse app (as I suppose it was needed due to changes in the config from the clean install) we have got a problem.

Avatars from all people that had customized their profile image has been lost.

I guess it has something to do with image optimization, may be you need to do something (besides launcher rebuild app) to recreate them.

But I have not found what is the missed step.

I have found thread of people that had lost the standard avatars (the ones distributed with discourse) but that is not our case, the people that has not changed their avatar (and uploaded an image) have their letter avatar in place.

UPDATE:

I have made a
./launcher enter app
rake posts:rebake

but it did not help.

¿May be it is not posts:rebake?

1 Like

@arinaf,

Oddly enough this same thing happened to me today on a setup with a nginx reverse proxy to a unix domain socket. Everything was perfect but the custom avatar images were showing as icons (the person icon) and all the letter avatars were the OK.

While trouble shooting, I went back to a standard two container setup (no nginx front end, no unix socket) and the problem was gone.

Then, I went back to the nginx reverse proxy setup to a unix socket, and the problem comes back.

I’m at a loss… so taking a break for a while :slight_smile:

Obviously the data is fine because it works perfectly without a nginx reverse proxy, which is odd because it works fine without it. LOL. (was working flawlessly both ways and suddenly the odd avatar issue came up…)

That is exactly my configuration, as I am running other soft in a docker container (a ghost blog).
I have nginx as a reverse proxy.

Obviously, restoring backups is not as straight forwards as it seems.

I have been doing rebakes, as I thought it was a problems of not saving thumbnails, with no luck.

Will try what you say to confirm if the problem is with the reverse proxy (no idea why that can interfere but I loose nothing trying).

Ya… I don’t think the issues is related to the backend database, restoring the DB, (or raking).

As soon I switch off the reverse proxy and run two containers without it, the issue is gone and since the DB is the same in all cases it is not likely a DB issue.

I’m off the net for 12 hours, so will check back in later and see what happened on your setup @ariznaf

2 Likes

Are you doing https outside the container?

Have you inspected the page source to see what URLs are being used for the avatars?

Sounds like force_https isn’t enabled.

1 Like

I cannot do it right now, as I have to start from scratch again.

I have been trying to copy all the files (with shut down discourse in origin) but it did not work either (problems with the database).

I will try to begin again, install a clean discourse and then restore the backup made with discourse.

I will check, thank you.

Trying to restore databases or migrate from one host to another is getting harder than expected.

Thank you both.

Providing you aren’t using a reverse proxy and the destination platform is representative and configured correctly it’s usually incredibly straightforward.

Well except if the mean time there was some upgrade to the discourse itself or the plugins you are using (I am only using a few official plugins + topic list previews and a few components) each time I have tried to simulate a restore there was some kind of trouble.

I feel the backup system is easy and straight forward but not robust enough when you have to translate everything to other server.
And has not flexible enough.

It takes too long too to finish (for a noto so big site, the full backup is just 3GB).

Our old forum had more than 100GB of data, it would be imposible to backup such a bit forum with the current system.

The various resized avatar images aren’t included in a backup, just the originals. It’ll take some time for the scheduled job to go through and generate the resized versions of every avatar.

5 Likes

AH, OK.
Thanks a lot
I did not know that they were rebuild in the background
So it is a matter of waiting.

I was getting mad using rake posts:rebuild and things like that.

You have saved me a lot of headaches. Thanks a lot.

2 Likes

You can speed it up by going to /sidekiq/scheduled on your forum and pressing the “Trigger” button next to the CreateMissingAvatars job.

2 Likes

Wow there is a whole world hidden there in /sidekiq :slight_smile:

I have been trying what you suggested.

But CreateMissingAvatars job is scheduled and it runs, but it terminates nearly inmidiatly, it take just a few ms to complete. I have tried to run it mannually (using Trigger) but again it terminates inmediatly with a OK result.

But avatars are still wrong.
I was using now my original configuration, with discourse listening in a socket and nginx as a revers proxy.

I will try now to remove nginx and run discourse in 80 and 443 ports.

Yo @ariznaf

Woke up this morning after being off the net for 12 hours and switched back to our socket-only.yml configuration and everything is back to normal again.

So, at least on this end of the expansive discourse-verse, all is well in two container, nginx reverse proxy to unix socket land again.

We had switched to the nginx front end configuration maybe six hours before the anomaly (was noticed) and all was fine.

Based on this helpful hint from @riking (as always, much appreciated Kane)

The various resized avatar images aren’t included in a backup, just the originals. It’ll take some time for the scheduled job to go through and generate the resized versions of every avatar.

My best guess is that when we did the switch to ngnix we did not notice any issues because the many avatar images were already cached and the regeneration process had not ended; so over time, the cache expired for those images and the anomaly started to appear.

So I drop off the net (socket-only.yml container is still running in the background, inactve) for 12 hours, wake up in the morning, and sidekiq had done it’s magic overnight (here) as @riking (great support BTW Kane, on every topic here on meta).

This scenario seems to confirm what @riking suggested.

Honestly, the more we use Discourse, the more we like it. The hiccups and anomalies are very interesting and the two-container configuration is really great.

Our containers currently looks like this:

# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml

What I like about this is even when we see an issue, for example this avatar regeneration anomaly, we can easily switch back-and-forth from socket-only.yml to web-only.yml.

In this case, we switched back to web-only(during this regeneration) and switched back after the process was done (because all the containers are still running). When we perform a container rebuild, we can just switch between these containers and config very easily.

Coming from two decades of running a LAMP forum, we are more and more impressed with Discourse, on the sys admin side.

Sidebar (Editorial);

Of course, it is way above my page-grade here on meta, but I think the basic two container configuration (without the reverse proxy) should be the default, as it is very easy to setup and we gain much more from this configuration than any perceived “penalty” for having two yml files.

1 Like

On my side, I have tried to do the restore using just the backup made from the interface.

As commented we lost avatar images and some other minor things.

I have tried to follow the guidance giving by @riking, but no luck.

I have tried to refresh the avatar images forcing the execution of the process.
But it ended with OK status after a few milliseconds and the avatars were not generated.

As we were in a hurry of moving the content, I have stopped the forum in the old server, copied all the content in containers and shared directories using tar and install discourse in the new server (without doing initial configuration) copied there the shared an containers directory and rebuild app.

Now everything is working in the new server.

Restoring from backup is getting more problematic than expected (as it seems straight forward given the instructions of just reinstalling and restoring from the interface)

I have to investigate what goes wrong when restoring and how to get sure the system will start up even if we restore from an old backup when discourse is several versions ahead of the version it was when backed up.

I like discourse a lot.
Coming from other traditional forums, sometimes you find it difficult to find where is what you want.
The clean interface does not help find it in this cases.

But when you finally find it, it is where it should be and makes things in a clever way.

We are having problems only with restoring from backup.
And sometime with the heavy use of caching it does.

Discourse takes a while to load the first time in you web navigator, but after that it flies, as most of the processing is done in your own machine, and it uses a los of caching (avatars, images, css…).
The app does not retrieve the info it has already in your computer and that saves a lot of work in the server (at least that is what it seems to do, given my experience).

When I try to move from one server to another, or reinstall discourse from scratch, you continue seeing the old content even if you refresh the view.

I could not get rid of that until I clean the navigation history of the web explorer.
That kept me occupied and confused for quite a while.

BY THE WAY ¿are those avatar images saved if you select the saved thumbnail images in the backup?
¿Do you think it is better to save them?
Our forum is not too big, but raking 36000 images took quite a while.

1 Like

Hi @ariznaf,

Our full backup is the same size, around 3GB fully gzipped.

So, far I have not experienced any of the problems you mentioned in your post (just above, #13).

Do you restore from the command line or from the UI?

We only restore from the command line in container. I assume that is the same for you?

That’s good news. Congrats.

Thank you for your interest.

I have followed the instructions in the tutorials, using the interface. I don’t know how to restore from the command line (backups taken using the discourse interface).

Let me explain:

I had to move the server from a.domain.com to b.domain.com.
The discourse forum is access using HTTPS with a custom SSL (we domain wide SSL certificates).
Discourse is install using a socket and with HOST NAME a.domain.com.
We have configured nginx as a reverse proxy to permanently redirect http(80) traffic to https(443) and https(443) act as a reverse proxy with https traffic, redirecting it to the socket where discourse is listening.

I had a backup (through the interface) o a.domain.com in S3 bucket, with database and uploads, not thumbnails (about 3GB).

I install nginx and copy the configuration file from a.domain.com changing the name of the host from a.domain.com to b.domain.com.

I have installed discourse cloning from GitHub (as adviced in the 30 minutes install tutorial).
Then I have run discourse setup (with nginx stopped) and configured it to HOSTNAME b.domain.com.

I accessed the new b.domain.com installation entering as admin.
Using the interface, I have configured backups to access the S3 bucket, and activate admin restore capabilities, and restored the last backup.

Then you are logged out from discourse, as there are new users, config, etc.

Back to the command line, I edit the app.yml and copy the configuration from the original server (a.domain.com) changing just the host name to b.domain.com.

Then I make a ./launcher rebuild all and after finishing, I start nginx.

I get access to the discourse forum but avatars are lost and there are some other problems with image thumbnails).

1 Like

Thanks for such nice details @ariznaf

Honestly, I am not a fan of cloud storage services like S3 and so better, I think, that I sideline any more ideas since we are not “S3 users” …

You say avatars are lost, but did you inspect the page source to see where they are being requested from?

Are they still in s3?

Why did you need to change subdomains?

To be clear you’ve changed both physical server, and dns address?

1 Like

Riking says that the system has to rebuild the miniatures. But the job seemed to have finished.

I will try again. Now I have solved it in another way.

In S3 in only save the bacuos, images,uploads, are store locally.

But I have to make restore tests to see what the problem is.
I will see where it is trying to retrieve the image from.

But it showed an image if a white silouette so it is not a broken link, it is changed by the system probably because it has not the thumbnail.