My schemes are gone, what to do?

I added a commit with a rebuilder, where you can rebuild the content based on the schemas:

You can enable it in the settings:

See the full commit here:

You can enable it with environment variable: REBUILD__SCHEMAS=true

or you can just run it with dotnet run --Rebuild:Schemas=true (I think)

You can read more about it here:

Even doing what you gave me can not retrieve the schemas / data, any other suggestions?

You can export your database and send it over to me me, so that I can debug through it and have a look.

I’ve remade the compose again!

And it solved the problem?

No, this is very strange!

As I said: Send me your backup and I can have a look. Otherwise it is like a blackbox for me.

Can I pass you the connection string?

If your mongodb is available from the outside, sure

Follow the connection string
Password download: DELETED

Thx, please send it as PM the next time :wink:

It looks like the whole database has been recreated. I don’t know what has happened but this is basically an empty database + 1 user. There is nothing I can do for you.

No problem, thanks for the help!

You are welcome. I am 100% sure, that is not Squidex. Because there is nothing that deletes users or events from the database. The whole concept of Squidex is to never delete data.

Hey @Sebastian,
I am experiencing the same issue. It looks like after I restart my Docker Container something recreated the Database. I can remember to read something about recreating the Mongo Db on the configured folder even if it is not empty.

I am 100% sure that Squidex does not recreate any databases. Do you have a persistence volume for your database?

I mapped an szure storage account as described in my Azure Setup Documentation. For some reason they are all empty. It looks like the MongoDb container does not use it to persist the data.

Perhaps the path mapping is just not correct?

I found the Problem. It seems like the Azure Linux Hosts for WebApps does not fully support SMB 3.0, which is needed by Azure File Share mounts. So if you have a correct path mapping there will be error messages on Mongo DB startup and if you screw up the path mappings, all files are stored in the container.
I fixed the Issue by setting up the MongoDB in an azure container instance (ACI), which supports SMB 3.0.
@Sebastian I will update the Azure Documentation again with this new insight and send you a Pull Request

1 Like

Awesome, thanks for your contributions :slight_smile: