No I don’t see this in my app.yml
All the S3 settings were defined in the Admin → Settings pages and it was working fine for year until I needed to restore it when the server went down last night.
Correct, this is what I used to setup the S3 backups and uploads.
I think I would try editing the app.yml with your settings and from there I believe (hope?) you should see your backups in the admin section and restore from there, without the manual import and the uploads, which you shouldn’t have to restore, but seem to be included in the backups. I don’t know why it is failing though…
I think this may be because your backup contains a mix of S3 and local uploads. I’m afraid it’s not my area of expertise, but there is some discussion and a workaround in this topic which allows you to bypass the failure. However, it was for a much smaller number of errors so you may want to take that into account:
Thanks, my site has crashed unfortunately so I’m only left with the S3 uploads and back ups. I’m assuming there’s no way to for me to migrate any left over local files to the S3 now.
So I’m wondering what are my options right now? Is there a way to restore from S3 backups and ignore the local files? I found a way to have it ignore the S3 upload but then pretty much all the posts have broken links/images (90%+ is probably in the S3 because I setup the S3 upload many many years ago).
So an update for folks who may be struggling with the same issue (basically I’m unable to restore from a backup and the server crashed due to a fault system upgrade).
From what I understand the root cause of the issue is that there are local uploads AND there are S3 uploads, so when the restore tool is trying to restore it’s bugging out because it doesn’t know how to handle local and S3 restores at the same time (maybe it’s time for Discourse to relook at backup/restores).
Thanks to @RGJ for this tip, he suggested force discourse to ignore the S3 upload while restoring:
- Add a line to your app.yml
- Rebuild discourse
./launcher rebuild app
- Attempt a restore (either from the GUI Backup page or using the CLI)
- Then after restoring, remove that line from app.yml and rebuild one more time
While this worked, point to note that the forum was badly broken, the categories, settings and posts were restored, however all the images, links, embedded documents etc were broken and errored out.
The hail-mary solution:
I managed to salvage the old server and extracted the
/var/discourse directory (tar/gz) and copied it onto the new server and did a
./launcher rebuild app. This completely restored the operation of the forum, however the fundamental problem still remains - the backups will NOT work because they have a mix of local and S3 uploads.
So I really need some advice on the best way to fix this issue once and for all. Is it better/easier to move all the upload from local to S3 or from S3 to local and how does one do it? The entire point of a backup is to help out in situations like this one, but it’s failed me so I need yourself to get it straightened out.
If you configure as described in Using Object Storage for Uploads (S3 & Clones) you should be able to
If you want to stop using s3, then you can enter the rails console and set
Then take a backup, make sure that you do not have s3 configured in your
app.yml and restore the backup. I think that this will restore backups to local.
But in either case, I would still recommend setting your keys and backup bucket in ENV variables in your
app.yml file and then check that you can restore it to a new site.
Okay I think I got a little mixed up here.
I’m thinking the ideal thing to do would probably be to have all uploads local and save the backups (zips) to the S3. This way the backup is available on S3 should anything happen to the server but the backup in itself is self contained with no dependencies so it should be easy to restore it on a new server.
So if I understood correctly, I should follow these instructions:
If you want to stop using s3, then you can enter the rails console and set SiteSetting.include_s3_uploads_in_backups=true Then take a backup, make sure that you do not have s3 configured in your app.yml and restore the backup. I think that this will restore backups to local.
- disable the
enable upload to S3option in Admin → Settings → Files
- enable the backup to S3 option in the Admin → Settings → Backups page
Is that correct?
This is the part that confused me, why would I want to put the S3 configuration in the app.yml file?
So that you have access to your backups via a command line restore before you restore your backup. Otherwise, you have to set up an admin account and then configure S3 and then restore. Similarly, whatever settings you put in your database get overwritten when you restore the database.
I think that best practice is to configure S3 only via ENV variables in the
app.yml file. It would probably make sense to make them be hidden settings, if not for hundreds of people who would be surprised that they had disappeared.
Because you will have trouble restoring otherwise.
How would one restore a backup from S3 using the command line? According to the instructions here: Restore a backup from command line
It says you can drop the backup file into the
/var/discourse/shared/standalone/backups/default folder and then start a restore from the CLI. This is what I had done with your suggestion earlier (which eventually led to broken links unfortunately), but that does work.
How does one restore directly from S3 using the CLI?
cd /var/discourse ./launcher enter app discourse restore
It’ll print the available backups you can then copy/paste the one that you want to do the restore.
Thanks, so it’ll read the S3 backups and list them an option.
Jay, to follow up on a suggestion you had made to move assets local:
I think you can set a hidden setting
include_s3_uploads_in_backupsto true and then make a backup and restore it when s3 is turned off to stop using S3.
Having S3 backups with them configured in
app.ymlmeans that you can do a command line restore with only the
app.ymlfile (after cloning discourse and installing docker).
For the first step would I need to backup the S3 buckets or is this a bucket safe operaiton?
Well, atleast I figured out why my server crashed last night (and again today after a complete rebuild , see this topic for details: Ubuntu 20.04 kernel update with docker causing a crash
So to get it up and running from a backup, I had to
- disable Settings → Files →
enable s3 uploads
Settings → Backups →
- enable Settings → Backups →
backup with uploads
Then I took a backup and I was able to restore it successfully. However one things did break, all the attachments (files) not have invalid links. The images are all good, but attachments links like
https://domain.com/uploads/short-url/phu1HOLvkE8LWpkKYfnMPSWsvHh.zip now give me a error
Oops! That page doesn’t exist or is private.
Is there a way to fix these short-url links?
You might try doing an html rebuild (aka rebake) on one of those topics to set if it fixes it.
Thanks. Is there a guide somewhere on how to issue the command to bake specific topics?
Sadly that did not work, the URL didn’t change after Rebuilding the HTML and it still leading a
Oops! That page doesn’t exist or is private.
Any other ideas or thoughts?
Did rebuilding from the UX work or not?