3.3.0.beta2-dev fc76622b56 There is less backup data and it cannot be restored normally


1 Like

Were there any settings changes in that timeframe that could have had an affect on whether uploads were included in your backups?



1 Like

Did you change to a two-container set-up at that point, or were you always using it?

1 Like


1 Like

I tried restore my latest backup a couple days ago and upload on my dash was refused I felt for a second that my backup is gone so I try one more uploading on FTP and guess what? restored! but this happened idem and I would to know the reason.

I’m afraid I’m more familiar with the standard install and I’m not sure if the two-container setup has any quirks that may be relevant here.

Let me slide this over to installation and see if we can get some more experienced eyes on it. :eyes: (@pfaffman :crossed_fingers:)

1 Like


No. The only difference is that a rebuild rebuilds just the rails and nginx part. The database and redis stay the same. Those change rarely, so they don’t need to be rebuilt. It works just the same. You understand that just fine. (The only complication is when there is a postgres or redis update, which is on the order of once a year, though there were some database updates that happened due to requirements of the AI plugin. So if you weren’t using the AI plugin you’d be just fine, but if you were, you’d get confusing database errors if you didn’t also rebuild the data container.)

My guess is that they moved assets to s3 and so the local uploads aren’t included. This is consistent with them saying that they were able to restore stuff from s3. Or maybe they deleted some posts that had uploads so those uploads weren’t included in subsequent backups.

Also, it sounded a bit like they did a restore and didn’t wait for it to finish completely.

1 Like


I did use an AI plug-in. What should I pay attention to so that the backup data can be used? How should we deal with this kind of problem

意思是只要data.yml不做rebuild就没有问题,还是说要用app.yml,或者这种问题在data.yml web_only方案和app.yml方案上都存在

It means that as long as data.yml is not rebuilt, there is no problem, or is it necessary to use app.yml, or this kind of problem exists in both the data.yml web_only plan and the app.yml plan

问题是我备份时,data.yml构建的容器和我恢复时data.yml构建的容器版本不支持,并且数据库做了升级,如果data.yml rebuild构建升级,就算你们做了大的数据库升级也不会出问题,然后做的备份再去恢复是没有问题的,我怎么可以知道你们的数据库做了大的修改

The problem is that when I backed up, the container built by data.yml was not supported, and the database was upgraded. If the data.yml rebuild is upgraded, there will be no problem even if you do a major database upgrade, and then there is no problem with the backup and restore it. How can I know that your database has been greatly modified

@sober, as a process note, it’s much easier for those reading along/wanting to help out if you include an English translation in your posts. Could you please edit one in. :pray:


I now understand that the problem was a big upgrade of the database that caused backup problems


When discourse is upgraded, how can I ensure that the upgraded version is in beta version instead of dev version? After the last backup went wrong, I have to worry about the upgrade and backup restoration operations

1 Like

What? well I’ll wait for a confirmation cause idk if will broken something here.

I only want to upgrade beta2, not beta2-dev, because I am afraid that dev is unstable, and the recent data backup cannot be restored normally, which almost causes data loss. I used the early backup for backup, but the data was still lost for a period of time

1 Like

They’re not, that’s just a recent change to the versioning system. Technically, you’re not even supposed to see the -dev labels.