Pause images optimization upon restore to new instance of server

Product Support

AI-generated summary

The discussion revolves around pausing image optimization during a Discourse instance restore to a new server, particularly to save disk space. adopilot seeks a way to halt image processing after initial upload and database restore to verify the restore’s success before deleting the backup. pfaffman suggests using rsync to transfer images and restore only the database, avoiding full backup restoration. adopilot shares a workaround: deleting the backup file during the restore process after it’s copied to the temporary folder, allowing the restore to complete without needing the original file. This method avoids the need for 4x the backup size, as the restore process can continue without the backup file once the initial data is unpacked and processed. pfaffman acknowledges this as a valid solution for those needing to manage disk space during migration.

1

I am trying to migrate my discource instance to new server, Since I am limited whit space on server I want first to

How i can pause image optimization after initial upload db and restore it.

So I can check did restore pass well and delete backup file and delete.

My backup file is about 200GB whit unchecked settings Include generated thumbnails in backups. Disabling this will make backups smaller, but requires a rebake of all posts after a restore.

So I am going to run out of disk space if my instance holds backup file and start optimizing images.

2

If you need more space you need more space.

But maybe you want to rsync the images and restore only database. That way you don’t have two copies of all of the uploads (and don’t have to make thumbnails again.

3

Thanks for trying to help.

I did try it, but I was now quite sure why my restore did not went good.

My main problem is that my old instance has stacked on PostgreSQL version 12 I did not find way to upgrade it, and try to move to new fresh instance.

Do you know is possible to restore only database to fresh install.

When I tried instance just start retuning error code 500 and I had to start all over.

4

What I would do is follow the Move a Discourse site to another VPS with rsync except don’t copy over the postgres files.

Then do a database-only backup and restore that. You’ll rsync over the backup as well and restore from the command line.

Is this a very old version, I guess? Did the restore appear to complete successfully?

5

Thanks for helping.

Yes but for straightforward restore using web gui and expected procedure you need +4x free size of your backup file.

Here is how:

  1. Upload backup file (or rsync into /var/discourse/shared/standalone/backups/default)
  2. Once when restore is initialized backup file.gz is copied to /var/discourse/shared/standalone/tmp/restores/
  3. During restore backup file in /var/discourse/shared/standalone/tmp/restores/ folder is unpacked
  4. From tmp folder uploads are rsync to native place and sql dump being inserted to pg database.

How I managed to success restore.

During restore process once when discource copied file from restore folder to temp i did delete original backup file uploaded to over ssh.

Once again when discource finished with sql inserts and stat rsync unpacked files from tmp folder to /var/discourse/shared/standalone/uploads/ I manually deleted bakupxxx.tar.gz file in temp folder over ssh without interrupting the process of restore.

Once when my instance was online and rsync finished I did

rm -rf /var/discourse/shared/standalone/tmp/restores/default/*

If you backup large restore process my seems death and instance over web start returning error code 500 (happened to me twice) you can check restore process by entering into app

cd /var/discourse
./launcher enter app

ps aux | grep restore

Also since my db restore was too long

cd /var/discourse
./launcher enter app
watch -n 10 “sudo -u postgres psql discourse -c "SELECT now(), state, query FROM pg_stat_activity WHERE state != ‘idle’;"”

Helped me to monitor db restore progress, to see that is restore is still alive.

6

That’s some solution! If anyone else finds this, I think that doing a database-only restore would have worked and been a bit easier, but glad you got it worked out!