Data preservation on cloning target instances

You can use data preservers to protect data on the target instance from being overwritten. If you have custom applications, you must also manually preserve unpublished application content.

Sometimes, preserving certain data on a target instance is desirable. For example, when using a MID Server, you can avoid overwriting the MID Server [ecc_agent] table. Preserved data is stored in a dynamically generated list on the target instance before the clone and restored on the target instance after the clone is complete. You define data preservers on the source instance.

Data preservers are primarily intended to preserve system settings and themes, such as instance-specific authentication settings. Do not use data preservers to transfer large sets of data, such as user groups. If you must preserve table data such as users, groups, and roles, consider exporting the records to a file and importing it after the clone is complete.

Consider whether to preserve the data in the following tables.
  • Bookmark [sys_ui_bookmark]
  • Recent Selection [sys_ui_recent_selection]
  • User Preference [sys_user_preference]

Data preservation and Multi-SSO

The system automatically creates the necessary data preservers for cloning when you activate Multiple Provider Single Sign-On integration.
Name Table Conditions
Certificate X.509 Certificates [sys_certificate] None
Core Instance Properties System Property [sys_properties]
  • [OR] [Name] [is one of] [glide.authenticate.external, glide.authenticate.external.logout_redirect]
  • [OR] [Name] [starts with] [com.snc.integration.saml_esig]
  • [OR] [Name] [is one of] [glide.smtp.port, glide.smtp.auth, glide.smtp.encryption]
  • [OR] [Name] [starts with] [glide.authenticate.multisso]
  • [OR] [Name] [is] [glide.authenticate.sso.redirect.idp]
Digest Properties Digest Properties [digest_properties] None
Identity Providers Identity Providers [sso_properties] None
SAML2 Update1 Properties SAML2 Update1 Properties [saml2_update1_properties] None
Note: Although you can modify these data preservers, a good practice is to avoid changing them. The Digest Properties [digest_properties], Identity Providers [sso_properties], and SAML2 Update1 Properties [saml2_update1_properties] tables are required for multiple source single sign-on to function properly. If multiple source single sign-on is disabled on the target instance, you can safely remove all three data preservers. Remove them at the same time, as the system terminates the clone with an error message when you attempt to clone with one or two of these tables being preserved.

Data preservation and SAML

Preserving SAML SSO-related settings can prevent the target instance from redirecting all authentication requests to the original IdP with the wrong issuer and audience parameters. To preserve SAML settings, create data preservers for the following tables:

  • System Property [sys_properties]: to preserve SAML properties.
  • X.509 Certificates [sys_certificate]: to preserve SAML certificates.
  • User [sys_user]: to preserve SAML users.

You also need to preserve properties, certificates, and users that are involved in SAML.

Create a data preserver

Data preservers maintain certain data on the target instance.

Before you begin

Role required: clone_admin or admin

About this task

Sometimes, preserving certain data on a target instance is desirable. For example, when using a MID Server, you can avoid overwriting the MID Server [ecc_agent] table. Preserved data is stored in a dynamically generated list on the target instance before the clone and restored on the target instance after the clone is complete. You define data preservers on the source instance.

Data preservers are primarily intended to preserve system settings and themes, such as instance-specific authentication settings. Do not use data preservers to transfer large sets of data, such as user groups. If you must preserve table data such as users, groups, and roles, consider exporting the records to a file and importing it after the clone is complete.

Consider whether to preserve the data in the following tables.
  • Bookmark [sys_ui_bookmark]
  • Recent Selection [sys_ui_recent_selection]
  • User Preference [sys_user_preference]

Procedure

  1. Navigate to System Clone > Preserve Data.
  2. Click New.
  3. Enter the table label as the Name, for example, User Preference for the [sys_user_preference] table.
  4. Select the Table to be preserved.
  5. Select the Theme check box if the data being preserved is a UI property.
  6. Define the data to be preserved using the Condition builder.
    You can use conditions to define particular records you want to preserve during a clone. For example, to only preserve particular system properties, you can add conditions for each property name you want to preserve.
    Data preserver with conditions
    Warning: If the clone from backup fails for some reason, the clone process fails over to the legacy clone engine. The legacy clone engine cannot preserve data from extended tables, relationships, hierarchies between tables, and dot-walked queries. You may want to reschedule a system clone or manually transfer data in such cases.
  7. Click Submit.
    If you want to delete the data preserver later, make sure not to modify or delete the following data preserver records:
    • Core Instance Properties
    • Semaphores
    • Email Accounts

Preserve SAML properties

If you want a clone target instance to keep its existing SAML integration, you must edit the Core Instance Properties data preserver to include the SAML properties.

Before you begin

Role required: admin

Procedure

  1. Navigate to System Clone > Preserve Data.
  2. Select Core Instance Properties.
  3. Add the following Conditions.
    • [OR] [Name] [is one of] [glide.authenticate.external, glide.authenticate.external.logout_redirect, glide.authenticate.failed_requirement_redirect]
    • [OR] [Name] [starts with] [glide.authenticate.sso.saml2]
    • [OR] [Name] [starts with] [com.snc.integration.saml_esig]
    SAML system property preservation
    Note: Ensure the Theme check box is cleared so these properties are preserved regardless of whether you preserve the instance theme.
  4. Click Update.

Preserve unpublished applications during a system clone

Application developers must manually save a copy of each application currently in development prior to cloning over their development instance.

Before you begin

  • Role required: admin
  • Write access to the application record
  • A source control repository

About this task

The cloning process does not preserve version differences for applications in development. Instead, the system clone only copies the application version installed on the source instance onto the target instance. If the target instance had a development version of the same application, the application will be editable after the clone, but it will be at whatever version was installed on the source instance. If the application was missing from the source instance, the cloning process deletes the application from the target instance.

Procedure

  1. Use one of these actions to preserve the application on the clone target instance.
    Table 1. Version differences between instances
    Application version state Action to take
    The application version on the clone target instance is different than the source instance version. Export each application from the clone target instance. Choices include:
    • (Recommended) Link each application to a source control repository.
      Note: If the application is already linked to a source control repository, commit the latest version to it.
    • Publish each application to an update set.
    The application is only available on the clone target instance.
    The application version on the clone target instance is the same as the source instance. None. The system clone process will copy this application version onto the target instance during the clone.
  2. Schedule a system clone of the source instance over the target instance.
    For example, clone your production instance over your development instance.
  3. Log in to the clone target instance.
  4. If you saved each application to a source control repository, use one of these actions to retrieve them from the source control repository.
    Table 2. Retrieve applications from a source control repository
    Application installation state Action to take on clone target
    The application was previously installed on the source instance. Apply remote changes from source control repository.
    The application was never installed on the source instance. Import the application from source control repository.
  5. If you saved each application to an update set, use one of these actions to retrieve them from the update set.
    Table 3. Retrieve applications from an update set
    Application installation state Action to take on clone target
    The application was previously installed on the source instance.
    1. Delete the application version cloned from the source instance.
    2. Load the update set containing the current application version.
    The application was never installed on the source instance. Load the update set containing the current application version.

Result

The applications previously in development are available for further development on the clone target instance.

Preserve the Marketing Events application

Suppose your company previously created version 1.0 of a custom application called Marketing Events. You have already published version 1.0 of the Marketing Events application to the application repository and installed it on your production instance.

Over time, users have submitted enhancement requests for the application, and you decide to develop version 2.0 of the Marketing Events application on a sub-production instance to address these requests. As development nears completion, you want to update your sub-production instance to the latest copy of production for some comprehensive testing.

Since you previously used a source control integration to develop version 1.0 of the Marketing Events application, you have already linked the Marketing Events application to a source control repository. You commit version 2.0 of the Marketing Events application to the source control repository.

You schedule a clone of the production instance over the development instance. After completion, you log in to the development instance and see that it has version 1.0 of the Marketing Events application, because that was the version installed on the source instance.

Since the application was already installed on the source instance, you apply remote changes from the source control repository to receive the latest application version. The development instance now has version 2.0 of the Marketing Events application available for further development and testing.