Table of Contents

To restore the desired backup of a certain Schema, click on the “Restore” button across the needed schema in the Synched schemas grid (see Backup Configuration | Synced schemas):

The button may be temporarily disabled if there is an error on establishing a connection to the database or if the schema is already deleted from Assets.

Clicking “Restore” button will navigate you to the page with the list of all the available backups and restore history.

Available Backups

Under Available backups, you will see all the backups for the selected schema:

image-20240422-214843.png

For each backup you can see the following information and Actions:

Pagination will appear below the backups if there are more than 20 entries.

Quantity of objects in backup is visible for te backups made with or after version v2.0.12 (November 17th, 2022).

You can also filter the backup with the Backup type (Scheduled or Manual) or the Date, by clicking Date control, which will display a calendar to choose a date or a date range:

While accessing the “Restore“ page, the date filter will be empty and the latest 50 backups will be visible. To show more backups, please use the date filter.

If yet there are no backups of the schema, the list will be empty with the options either to manually backup the schema by clicking Backup now button or schedule backup by clicking Schedule button:

Edit Backup

You can edit the Description of the backup by “Edit“ under the three dots along the backup.

image-20240422-122606.png

You will see the description and basic information of the backup in the popup:

image-20240422-120936.png

After entering the information in the text box, under the “Description”, you can save the backup.

Delete Backup

With the Delete under the three dots along the backup, you can delete a certain backup by confirming delete in the following confirmation popup:

After deleting, the backup data will be permanently removed.

While deleting the backup from own database (e.g. MongoDB), the deletion may take up to 6 hours.

Restore

To restore the schema, select it by clicking the Select button. You will see the information about the selected backup on the left side of the page and the Restore options - on the right (Destination). As the first step, you need to select the destination - DC/Server or Cloud:

image-20240422-195454.png

Restoring on Cloud

After selecting Cloud under Destination, you can restore the schema on the current instance in a new or an existing schema or migrate it to another instance:

image-20240422-195609.png

New schema - current instance

To restore the schema on a current instance in a new schema, choose a new schema name and key, where the schema should be restored in (the schema will be automatically created). Click continue to move to the restore options:

image-20240422-200047.png

From here you can select to restore object history or restore specific object types. After the restore starts, the status will be shown in the right pane Destination) and Restore history. Selecting the options, you will be directed to the last, Review step of the restore wizard, where you can review the selected details and click Restore button to start the restore:

image-20240422-200408.png

After the restore started, the Status of the restoration can be:

The schema will be automatically created during restore, therefore choose a unique schema name and key. If the schema exists either with the same name, or the key, restore will not be successful and the corresponding result message will be visible in the Restores Grid.

Due to the rate limits of the corresponding Atlassian REST API, the performance of the restore process is limited to ~1,000 objects per minute. For example, if a schema contains 90,000 objects, restoration will take approximately 1.5 hours. Also, please keep in mind that if you start more than one parallel restores/migrations, it may also take long due to the Request per-minute limitation of the corresponding Atlassian REST API.

Once started, you can terminate the restore by clicking the STOP button and confirming termination in the confirmation popup:

image-20240121-204536.png

Termination may take some time, therefore if the process is stopped by the end of the progress, restore still might have been completed!

Once restore is started, you can see the stages of the restore under the Status column. The following steps can be observed:

The status is updated every 10 seconds, therefore if number of entries in certain stage is low, displaying the stage progress might be skipped.

After restoring the schema on the current instance, the schemas will be automatically synced on the current instance.

If the restore process is interrupted due the API, connectivity or system error, you will see the error under the status: The process was interrupted due to API or connectivity issues.

Restore with Object Type global custom icons

If this checkbox is checked, custom object icons will be updated with the parent Object Type custom icon. Due to the lack of a corresponding endpoint in the Atlassian REST API, individually uploaded object avatars cannot be restored. The checkbox will not be visible if the restore is done on the same instance as the original one and the icons will be restored by default, because the global icons list is the same for the original and the restored schema.

Restoring icons may take considerably longer! If a schema contains many objects, after backup is completed, icons will be backed up in the background, which may take long, depending on the number of objects. Therefore, if you are trying to restore a backup with icons immediately, icons may not be included in the restored schema.

Restore object history

You can restore also the history of objects by checking the “Restore object history“ checkbox at the “Options” step of the Restore wizars:

image-20240422-200631.png

If checked, after the schema is restored, object history will be restored in a newly created attribute: OBJECT_HISTORY.

Due to the limitations of Atlassian corresponding REST API, after the backup is finished, object history is backed up in the background. To prevent the cases when the history restore is tried before the history is backed up, you will not be able to select this option immediately after the objects backup is finished and the option will be disabled until the backup is completed in the background. The estimated waiting time before restoring object history option becomes available, depends on the number of objects and with a rough average is 5 minutes plus ~1 minute for every 1,000 objects. You can see the object history backup status in the Available backups.

image-20240121-204811.png

Times in the restored history attribute will be always shown in CET (UTC+2)

Restore specific Object Types

You can also restore the Schema not completely, but only certain Object Types, including Objects. To do so, check “Restore specific Object Types” checkbox at the “Options“ step of the restore wizard and the list of all the Object Types from the backup will show up:

image-20240422-200924.png

You can Expand and collapse the parent Object Type(s) by clicking the arrow and select child Object Type(s) from the list by clicking the corresponding Checkbox:

image-20240422-201037.png

To expand or collapse all the parent object types, click the “two arrows“ button at the top rightmost corner.

You can see the number of the selected Object Types and the objects, with the list of the Object Types to be restored, on the next (Review) step, after clicking the Continue button:

image-20240422-201505.png

If at least one child Object Type is Selected all the corresponding parent Object Types (including parent Objects) will also be restored.

If you try to restore an Object Type that has an attribute referenced to another Object Type (which you are not restoring), in such case the restored Object Type will lack the corresponding attribute.

New schema - another instance

You can migrate a backup from the current to another instance. To do so, select the “On another instance” option at the Target step of the restore wizard,, choose a Target instance and enter a unique Schema name and key:

image-20240422-202337.png

The Insight Assets Backup and Migration app must be installed on the target instance with an active trial or paid subscription.

Under the Targe instance dropdown, you will see the instances that were added to the List of target instances under the current connection. You can identify and select the added target instance by name and the URL:

image-20240422-202440.png

It is mandatory to select the Target instance before you can continue!

Also, from the same window, you can choose to add a new target instance, by filling the same information as while adding a new target instance under the current connection. Select New target instance in te dropdown to see the necessary fields to fill in:

image-20240422-202539.png

After Migration is started, you will have a chance to save the newly added instance to the List of target instances.

In the next step you will be able to select the options for restore:

On the last (Review) step you can review the details of the restore, before starting the migration process by clicking Migrate button:

image-20240422-203120.png

Schema in another instance will be automatically created during migration, therefore choose an unique schema name and key. If the schema exists either with the same name, or the key, restore will not be successful and the corresponding result message will be visible in the Restores Grid.

If the schema which is being restored contains references to the users, which does not exist in another instance, the object attribute will be still restored but the attribute value will be empty. If the attribute contains several users, from which at least one user does not exist (or is disabled) on the Cloud instance, the attribute will not be populated also with the other users. If this happens, the corresponding error will appear in the real-time and full log, indicating the relevant object key and the attribute. This is also relevant to the cases, when a user group is selected in the attribute, but the user does not belong to that group on Cloud.

Such empty attributes are by default hidden from an object view unless manually edited. Additionally, due to the GDPR restrictions, the matching with the users is not possible via email, and only Name/Surname is used. Therefore, in some cases (e.g. when there are several users with identical names and surnames), the user attribute value may not be restored.

Existing schema

You can restore objects in the original/existing schema by selecting “Existing schema“ option at the “Target” step of the Restore wizard. By checking this option, you will see the list of the existing schemas on the current instance. the “Schema” dropdown will show the list of the existing schemas on the instance, from where you can choose a schema you want the objects to be restored in:

image-20240422-203545.png

In the next step, you can choose the options of the restore:

image-20240422-203801.png

In the last (Review) step of the wizard you can review the details of the restore, selected options and start restore by clicking the Restore button:

image-20240422-204222.png

If you restore a backup twice in the existing schema, even if you choose not to duplicate the objects, they will still be duplicated as the restored objects will have new IDs.

While adding new objects in the restored schema, if you create new objects by cloning the existing ones, due to cloning of ORIGINAL_ID and ORIGINAL_KEY in new objects, these objects will not be restored if this schema is backed up and restored again, unless the duplicate option is selected.

Restoring on Data Center / Server

After selecting “Data Center / Server” under Destination, you can restore the schema on any instance previously added to the Data Center / Server instances.

If not DC/Server is added to the “Data Center / Server instances” list, this options will be disabled.

image-20240422-204422.png

To DC/Server you can migrate the schema to a new or an existing schema:

image-20240422-204532.png

Target Instance

To restore the schema on a target DC/Server instance, choose a target instance from the list and enter a new schema name and key, where the schema should be restored (the schema will be automatically created).

Click the Continue button to move to the restore options:

image-20240422-204947.png

From here you can select to restore object history or restore specific object types. After the restore starts, the status will be shown in the right pane Destination) and Restore history. Selecting the options, you will be directed to the last, Review step of the restore wizard, where you can review the selected details and click Restore button to start the restore:

image-20240422-205047.png

When the restore is started, all the restore statuses and the details are the same as for restoring the Assets on “Cloud: current instance”.

The schema will be automatically created during restore, therefore choose a unique schema name and key. If the schema exists either with the same name, or the key, restore will not be successful and the corresponding result message will be visible in the Restores Grid.

Due to the rate limits of the corresponding Atlassian REST API, the performance of the restore process is limited to ~1,000 objects per minute. For example, if a schema contains 90,000 objects, restore will take approximately 1.5 hours. Also, please keep in mind that if you start more than one parallel restores/migrations, it may also take longer due to the Request per-minute limitation of the corresponding Atlassian REST API.

Once started, you can terminate the restore by clicking the STOP button and confirming termination in the confirmation popup:

image-20240121-204536.png

Termination may take some time, therefore if the process is stopped by the end of the progress, restore still might have been completed!

Once restore is started, you can see the stages of the restore under the Status column. The following steps can be observed:

The status is updated every 10 seconds, therefore if number of entries in certain stage is low, displaying the stage progress might be skipped.

If the restore process is interrupted due the API, connectivity or system error, you will see the error under the status: The process was interrupted due to API or connectivity issues.

Existing schema

You can restore objects in the original/existing schema on the target DC/Server by selecting “Existing schema“ option at the “Target” step of the Restore wizard. By checking this option, you will see the list of the existing schemas on the current instance. the “Schema” dropdown will show the list of the existing schemas on the instance, from where you can choose a schema you want the objects to be restored in:

image-20240422-205313.png

In the next step, you can choose the options of the restore:

image-20240422-205717.png

In the last (Review) step of the wizard, you can review the details of the restore, selected options and start restore by clicking the Restore button:

image-20240422-205905.png

If you restore a backup twice in the existing schema, even if you choose not to duplicate the objects, they will still be duplicated as the restored objects will have new IDs.

While adding new objects in the restored schema, if you create new objects by cloning the existing ones, due to cloning of ORIGINAL_ID and ORIGINAL_KEY in new objects, these objects will not be restored if this schema is backed up and restored again, unless the duplicate option is selected.

All the following actions are identical for restoring on Cloud or or on DC/Server.

Restoring cross-schema references

After the objects are restored/migrated, you can restore also references between schemas.

To restore the references between schemas, ALL the referenced schemas should be preliminarily backed up!

All the schemas with inbound and outbound references should be initially migrated to the same Cloud instance. In the referenced schemas are not migrated, the corresponding attributes in the migrated schema will not be created. However, you can run cross-schema references migration after all the missing schemas are also migrated - this way the missing attributes will be created with the proper referenced objects.

To restore the reference, click the “References“ button in a “Restores” grid or the “Restore references button“ in the Cross-schema references box:

image-20240215-135748.png

After clicking either button, you will see the following popup:

From here you can choose the schemas (one or more) from which you need to restore the references in the current schema.

Only schemas with “Allow others to select objects from this schema“ option selected will show up here. Make sure to “sync schemas“ to see the updated schemas from the last synchronization.

In case of migrating the cross-schema references from Cloud to Cloud, the schemas list will show not the schemas from the instance, but the list of the schemas that are restored on the same target instance. You can check the Restore ID in the Restores grid:

image-20240215-143112.png

You can also choose to whether restore outbound references from the current schema to the selected ones by toggling the “Restore also outbound references” control:

Keep in mind that in case of large number of references, restoring may take hours and the references between the selected schemas (from the select list) will not be restored.

Click the “Restore References” button to start restoring.

You can see the progress and the results of the references restore in the “Cross-schema references“ box:

image-20240118-161737.png

You can see the following information:

Restoring comments

You can restore the comments of the objects if the backups contain the comments.

The comments restore/migration was added on February 16th, 2024. Therefore, only backups taken since that date will contain object comments!

Restore of comments is ativated only when the comments are backed up. If the comments backup status is not completed for the certain backup, comments restore will be disabled.

To do so, after the restore of the schema is completed, click “Start restore“ button in the “Comments“ box under the “Restores” details of the restored schema:

image-20240215-140338.png

After clicking the button, you will see the confirmation popup:

image-20240215-140529.png

You will see the status of the progress (pending, in progress, success, error) in the same box:

image-20240215-140650.png

While migration of comments on DC/Server, the comments format cannot be maintained. If the schema contains more than 50,0000 objects, the comments cannot be restored.

Restore of original Object Type ID

You can also restore the original Object Type ID. To do so, after the restore of the schema is completed, click “Start restore“ button in the “Restore Object Type ID“ box under the “Restores” details of the restored schema:

image-20240215-134013.png

After clicking the button, you will see the confirmation popup:

image-20240128-135205.png

You will see the status of the progress (pending, in progress, success, error) in the same box:

image-20240128-135545.png

After the restore is completed, you can see the original object type ID in the Description of the object type:

image-20240128-140704.png

If the original Description of the Object Type contained the information, it will be overwritten by the original object type ID!

Restores grid

After the restore is of the schema is started, the restore will appear in the Restores grid for the certain backed-up schema:

image-20240215-134435.png

The grid shows the following information:

To view additional information regarding the restore, click the “down arrow” in the beginning of the schema row:

image-20240215-135517.png

The information about the restore is organized in the following boxes:

Real-time log monitoring

When the restore of objects is started, you can monitor the process in real-time by clicking the “Real-time log monitoring“ button in the Restore information box:

image-20240118-161037.png

In the displayed window you will the the log of the successful and erroneous object restores when they appear in the process:

image-20240118-161235.png

Only the events of last 500 objects restore are displayed in the log!

Full restore log

After completing the restore, you can download the full restore log in .josn format, which will show a detailed log of the restored objects or the error messages per certain object. The downloaded file contains:

Example of the log file:

[
    {
        "ObjectKey": "OBJECTKEY-001",
        "Result": true,
        "Message": "{ message: 'OK' }"
    },
    {
        "ObjectKey": "OBJECTKEY-002",
        "Result": true,
        "Message": "{ message: 'OBJECTKEY-002 {"errorMessages":[],"errors":{"attribute-id":"The attribute '[attribute name]' has to be unique"}}' }"
    }
  ]

Full log is available for the restores and migrations performed after October 12th, 2023. For the restoes done before, the downloaded log will be empty.

Restore History

All the restores, whether successful or unsuccessful will be shown in the History table on the main page of the app:

image-20240229-123123.png

Total shows the total number of the restore/migrations, including successful and failed ones. You can also select the number of restores you want to see on one page (from 10 to 200).

Restores Grid shows the following information regarding all the restores after the app installation:

When there are more than 20 schemas, pagination will appear below the Schema Grid.

In addition, by clicking the downward arrow button on the left of the schema name, you can see more details regarding the certain restore:

image-20240118-140121.png

The following additional details are available:

If two or more restores are started approximately simultaneously, the restores executed later will wait in queue until the first ones are completed.

If schema contains many objects, restore may take time!

Additional Remarks

If you are migrating from Server to Cloud, the “Text“ attributes may contain more than 255 characters. In such case, after the migration, the objects containing more than 255 characters in this attribute, will not be restored. If this happens, you need to change the affected attribute type “Text“ to “Text Area“ on the Cloud and Restore only affected specific object types in the existing schema: https://twinit.atlassian.net/wiki/spaces/IB/pages/596476255/Restore+Migration+Guide#Existing-schema.

If the objects types that were backed up,

  • had either custom icons,

  • or they were imported with Asset Discovery,

  • or were restored to different instance,

some icons may be lost after restore, as they are not saved in the schema itself. If this happens, the icons will be changed with the default object icon (see the screen below). As a workaround, you can upload the original icons to the global icons on the target instance, keeping the name identical to the original ones, and after the restore, correct icons will be updated for Object Types and corresponding objects.

It may happen that the Schema was backed up in Cloud and after some time you decide to switch to your MongoDB. In such case, if you try to Restore the older backup, you will see the error message. This is true also if you backed up a schema in your MongoDB and later you try to Restore that certain backup after switching to Cloud backup (Switced off the “Backup on local database“ toggle).

During restoring the schema on the current instance, If the objects in the schema contain references to another schema not existing on the instance, the attributes will be restored, however with the empty values.

Due to the corresponding REST API limitations, when the objects are restored, they always have new Object ID, Object key and date/time of creation is when the objects are migrated. This results in various issues in the restore process e.g. the objects are duplicated when restored more than once, or the references are lost between the schemas. To deal with this issue, all the restored objects have 2 new additional attributes:

  • ORIGINAL_ID

  • ORIGINAL_KEY

  • ORIGINAL_CREATED (showing original creation date/time in UTC)

All the attributes represent the data, that the object had in the VERY FIRST backup of the schema. e.g. If the schema was backed up, restored and the newly restored schema was restored again, the original ID and the Key will not be changed in the last restore.

If the schema which is being restored contains references to the users, which does not exist in another instance, the object attribute will be still restored but the attribute value will be empty. If the attribute contains several users, from which at least one user does not exist (or is disabled) on the Cloud instance, the attribute will not be populated also with the other users. If this happens, the corresponding error will appear in the real-time and full log, indicating the relevant object key and the attribute. This is also relevant to the cases, when a user group is selected in the attribute, but the user does not belong to that group on Cloud.

Such empty attributes are by default hidden from an object view unless manually edited. Additionally, due to the GDPR restrictions, the matching with the users is not possible via email, and only Name/Surname is used. Therefore, in some cases (e.g. when there are several users with identical names and surnames), the user attribute value may not be restored.