Use system clone

Start the cloning process by requesting the clone, and then perform any post-clone cleanup that might be necessary.

Request a clone

For most instances, an administrator can request a clone.

Before you begin

Role required: clone_admin or admin

The glide property glide.db.clone.allow_clone_target must be set to True to allow an instance to be a clone target. Attempting to clone over an instance where this property is False displays the following error:

Figure 1. Clone target invalid
Clone target error message

This property is False by default, and to True on instances where the name ends in Dev, Test, Stage, UAT, or QA.

To modify the value of this property, add the property to the [sys_properties] table.

About this task

For instances that use an Oracle database, see KB0538884 - System Clone Support for Oracle Customers.

Procedure

  1. Navigate to System Clone > Request Clone.
  2. Select a Target instance to receive the cloned data.
  3. Complete the Options form section.
    Table 1. Clone options
    Field Description
    Clone from Select the source database, if more than one database is available. If only one source is available, the Clone from menu does not appear.

    By default, the clone process ignores this field and uses data from the most recent nightly backup of the source instance. The clone process only uses this field value if the clone from backup fails for some reason.

    Exclude audit and log data Select this option to prevent the cloning of tables specified in System Clone > Exclude Tables. This option is selected by default. Clearing the check box causes the platform to ignore the Exclude Tables module.
    Exclude large attachment data Prevents the cloning of large attachments such as video files, image files, and other typically large binary file types. Excludes all common binary file types, regardless of file size. When selected, the clone also excludes attachments from the Attachments [sys_attachment] and Attachment Documents [sys_attachment_doc] tables that meet all these criteria.
    • The attachment table_name value does not indicate it is a small file. Small attachments have table name values that start with ZZ_.
    • The attachment data type value indicates it is a large file such as application or video.
    • The attachment table_name is not one of these system tables: sys_certificate, ecc_agent_jar, ecc_agent_mib, sys_store_app, or invisible.sys_store_app.

    This option is selected by default.

    Preserve theme Select this option to prevent the cloning of CSS elements, colors, and banner displays. This option enables or disables any data preservers where Preserve theme is True.
  4. Schedule a Date and time to perform the clone.
    Scheduling prevents multiple clones from occurring on the same target instance concurrently. A clone must be scheduled at minimum four hours in advance.
  5. Enter an Email address to receive alerts after the clone finishes, is canceled, or has an error.
    Clone start
  6. Click Submit.
  7. In the authentication window that appears, enter the Username and Password for an administrator account on the target instance.
  8. Click Authenticate.
  9. Review the clone settings and click OK.
    An email is sent to the supplied address after the clone finishes, is canceled, or has an error.
    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.

What to do next

You can cancel a clone without negatively impacting system stability or usability. Canceling a clone restores the target instance to the pre-clone state, retaining all original data.

To cancel a scheduled or in-progress clone, navigate to System Clone > Clone History. Select the clone and click Cancel Clone.

Post-clone cleanup scripts

The Cleanup Scripts module allows you to define scripts to automatically run on the target instance after a clone is finished.

Cleanup scripts run after data preservers and the clone is complete.

You can add new post-cloning scripts on the source instance to perform any action that can normally be accomplished through script includes or business rules. To add a script, navigate to System Clone > Clone Definition > Cleanup Scripts and click New.

The following post-clone cleanup scripts perform various actions on the target instance.

Table 2. Post-clone cleanup scripts
Script Description
Bad MID Server credentials after clone Runs a script include called BadMIDCredentialAfterClone on a cloned instance to detect bad MID Server user credentials. This script include creates scheduled jobs that log MID Servers in the Down state to the MID Server Issue [ecc_agent_issue] table after an instance clone.
Clear scheduled job node association Resets any scheduled jobs that were active on the source instance to the Ready state. This script also clears the value of the System ID and Claimed by fields on all scheduled jobs.
Configure Email Accounts Migrates email accounts that existed on the source instance to the target instance if they are not enabled there. This script also migrates the email properties to the target instance.
Disable emails Disables email on the target instance. A default data preserver maintains other email settings from the target instance.
Install deactivated plugin Enables the Domain Separation plugin for instances that use this feature.
Regenerate all text indexes Rebuilds text indexes on the target instance after a clone. Text indexes are not cloned from the source to the target instance.
Schedule drop backup tables Schedules the deletion of the data contained in the target instance database prior to the clone. This original data is preserved for 24 hours following a clone to allow you to roll back an instance to the pre-clone state. If the target instance is downgraded as part of the clone, backup data is not available.

View clone history and active clones

You can view clone history information. All previously and currently scheduled clones from a particular instance display on this table. The clone history module additionally lists clones that have begun but have not yet finished.

About this task

Role required: clone_admin or admin

Procedure

Navigate to System Clone > Clone History.
Clone history also displays the State for current and past clones. Clones in the draft state do not appear on the clone history table.
Clone completed
Table 3. Clone state
Clone state Description
Requested The clone was requested and is awaiting approval.
Scheduled The clone is ready to begin at the scheduled time and date.
Active The clone is currently running.
Completed The clone completed successfully.
Canceled A user canceled the request.
Hold The server rejected the clone request. This can happen either because the clone was not ready to proceed by the scheduled time or because additional clone requests were submitted before the first one completed.
Error The clone encountered an error while running. Contact technical support for help resolving this issue.
Figure 2. Active system clone
Active clone log

After starting a clone, the Clone Log and Database Table Clones related lists appear on the form. These related lists show general log messages, and the details of individual tables respectively.

The duration of time a clone remains active varies depending on the amount of data being cloned, and whether the source and target instance are in the same physical location. If a clone takes longer than anticipated, ServiceNow Technical Support can identify additional details about the clone progress.