A backup is an ZIP archive file that stores all your data for one app. It contains several files of these types:
One file per each event that has happened in your system, for example
ContentDeletedevent. These files are named in a consecutive order by the order they have happened in your application.
One file per asset in your app.
Metadata files, for example all users in your system as a pairs of user id and email addresses. When the backup is restored these users are created in target system if they do not exist yet.
If you are the owner of your app, go to "Settings" (1) and then to "Backups" (2). You can create a new backup there by pressing the "Start Backup" (3) button. The screen will not update immediately and it can take a few seconds until you see the status of your backup.
Squidex only allows 10 backups per App. If you have reached this limit you have to deleted an old backup. Each backup item has a download link (5) that you need to restore the backup and also shows the number of events and assets in your backup (4). When you restore the backup it will print the number of restored events and you can compare this with the total number of events in your backup to get an understanding how long the backup operation might take. We do not show a progress indicator because it almost never works properly (see Microsoft Windows).
If you are hosting Squidex yourself you are very likely the administrator and you will see a link to the Administration section when you click your profile. This option is not available for you in the Cloud.
Go to "Administration" (1) and "Restore" (2)
Copy the URL from your backup and add it the the first input field (3)
Presse the "Restore Backup" button to restore your backup (4). If you have restored a backup before you will still see the logs as shown in the following screenshot.
If an app with the same name already exists you to either delete this app first or define a new name for your restored app (5).
Backups are critical paths for Squidex and do not provide the same security mechanisms as normal API calls, therefore we have to prove first that your backup does not cause any harm to our system. Create a backup of your local or cloud app and send us the URL in personal message in the support forum.
If you want to restore a backup please do the following things:
Provide a download link directly to the backup. If you need to delete your app (see point 4) you have to upload your backup first. Please ensure that an anonymous user can download your backup. Do not use Google Drive, because it causes issue when downloading the backup.
Provide the number of events and assets, so that we can have an understanding how long it might take to restore the backup.
If you want to change the name of the app, provide a new name please.
If you want to keep the name you have to delete your app first. Please do that. The download link for your backup becomes invalid, so you have to upload your backup first (see point 1).
Do not share your backup link in a public post, use personal messages for that.
The restore process executes the following steps:
The name of the app is reserved.
All events from the backup are inserted into the system. If the event is an asset event, the corresponding asset is added to the system.
All indices are restored based on the inserted events.
Contents and assets are created from the events and added to the database.
The app name reservation is either taken if the restore operation was successful or released when the operation has failed.
The backup has a few implications that are important to understand.
The backup system is useful if you want to clone your app with the full history to either the same installation or another installation. You can define a new app name for your backup and create as many independent copies as you want.
The backup system can be used to migrate from the cloud to a self hosted installation or from self hosting to the cloud. In first case you can just restore the backup yourself. In the second case you have to create a support ticket as described above.
The backup system is not as fast as MongoDB backup and can only secure your app information. Therefore it is not recommended to use the backup system for system backups. Have a look the official documentation about Back Up and Restore with MongoDB Tools to understand the different backup options for MongoDB. If you use a cloud provider like Mongo Atlas, it is typically built in.
The backup system creates a new app all the time and old apps are not deleted from the system and only marked as deleted. Therefore you should not use the backup system to make syncs between different environments. It is much more efficient to use the synchronization features of the CLI for that. If you use the backup system for this use case you create a lot of zombie apps in your system.