Links

Backups

Backups store all your app content and is useful for a few scenarios.

What is a backup?

A backup is an ZIP archive file that stores all your data for one app. It contains several files of these types:
  1. 1.
    One file per each event that has happened in your system, for example AppCreated or ContentDeletedevent. These files are named in a consecutive order by the order they have happened in your application.
  2. 2.
    One file per asset in your app.
  3. 3.
    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.

Creating Backups

How to create backups

If you are the owner of the app, go to Settings (1) and then Backups (2). To create a new backup press the Start Backup (3) button.
Backups in Squidex
The screen will not refresh 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).

Restoring Backups

Restore a backup - Self-hosted

In order to restore a backup you will need access to the Administration page. If you are hosting Squidex, 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.
  1. 1.
    Click on your profile, select Administration (1) and click Restore (2).
  2. 2.
    Copy the URL from your backup and add it the the first input field called Url to backup (3). You can optionally give an app name (4) as well in the second input field. If an app with the same name already exists you have to either delete the app first or define a new name for your restored app.
  3. 3.
    Press the Restore Backup button (5) to restore your backup. If you have restored a backup before you will still see the logs as shown in the following screenshot.
Restore a backup

Restore a backup - Cloud

Backups are critical paths for Squidex and do not provide the same security mechanisms as normal API calls, therefore we have to validate 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:
  1. 1.
    Provide a download link directly to the backup. If you need to delete your app (see point 4) you have to upload your backup to an external storage location first. Please ensure that the backup can be downloaded anonymously (without any authentication). Do not use Google Drive, because it causes issue when downloading the backup.
  2. 2.
    Provide the number of events and assets, so that we can estimate how long it might take to restore the backup.
  3. 3.
    If you want to change the name of the app, provide a new name.
  4. 4.
    If you want to keep the name you have to delete your app first. Once the app is deleted, the download link for the backup becomes invalid, hence it is important to upload the backup first to an external storage location (see point 1).
  5. 5.
    Do not share your backup link in a public post, use personal messages for that.
Click the profile picture of the user you want to write a personal message to.

How does the restore process work?

The restore process executes the following steps:
  1. 1.
    The name of the app is reserved.
  2. 2.
    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.
  3. 3.
    All indices are restored based on the inserted events.
  4. 4.
    Contents and assets are created from the events and added to the database.
  5. 5.
    The app name reservation is either taken if the restore operation was successful or released when the operation has failed.
The backup cannot use an existing app and creates a new app to avoid conflicts.

Using the backup system

The backup feature has a few DOs and DONTs that are important to understand.

When to use the backup system?

  1. 1.
    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.
  2. 2.
    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.

When not to use the backup system?

  1. 1.
    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 at 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 MongoDB Atlas, it is typically built in.
  2. 2.
    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 (link below) for that. If you use the backup system for this use case you create a lot of zombie apps in your system.
Last modified 2mo ago