Clone BasicsThis article answers the basic questions that ServiceNow Technical Support receive regarding clones from a source instance to a target instance. Find out more about: how a clone works, clone roll back, cloning options, data server configuration, and cloning over a production instance. The source instance provides progress and automation milestone updates within its clone history record. If email notifications are desired for any of the milestone updates, the instructions in KB0966447 - Email notifications for clone can guide to create custom notifications in the source instance itself. This article is part of a 3-part series on Clones, including: Clone FAQs - KB0715621Clone Tips and Tricks - KB1214621 width: 70%; .mce-toc { background-color: #f7f7f7; padding: 10px; border-radius: 5px; border: 1px solid #dedede; min-width: 500px; } Table of Contents How does the clone work?Can I roll back my clone?What do all the options do for cloning?Where do I configure the data preserver?Can I clone over my production instance and how?How to do a full clone? How does the clone work? In response to a clone request, the ServiceNow platform performs the following tasks: Generates a file to preserve operational data on the target server. This file contains the data preserved by data preservers.Creates a new database for the target instanceRestores the database schema and data from the latest backup to the newly created databaseAfter all data is copied across it starts the exclude/preserver functionsIf Exclude options are ticked Tables in the exclude module are truncated (All data is cleared out) (unless this is TPH table where it will be deleted) File created in Step 1 for preservers is loaded into the target database (overwriting any data from the restore)Email functionality is disabled in the target databaseOnce all is completed the target instance repoints to the newly created databaseAll Clone cleanup scripts are executed in the target instance. Regenerate Text indexesClear scheduled job node associations The clone is complete and the instance is accessible for the customer.After the clone completes a backup is taken of the old Target database Once the backup completes, the old target database is retired. Can I roll back my clone? Yes, only within the 7 days after the clone is run for non-sharded DBs, or within 2 days for sharded DBs. As we take a backup of the database after the cloning process, we can roll back the clone up to 7 days after the clone was run. After a clone is complete there is a UI action 'Rollback clone'. If you click this button, it will roll back the clone using the same automation that Technical Support will use to roll back the clone. If you are facing any issues or need clarification about your clone rollback, please contact Technical Support for assistance. What do all the options do for cloning? Clone options Field Description Exclude tables specified in Exclusion List Prevents cloning records from tables on the source instance which are listed under System Clone > Exclude Tables. If a table is on the Exclusion List, clone will exclude the records on the table as well as records on the child tables. When excluding tables, their table schema and hierarchy will still be cloned to your target instance. As a result, your target instance will have empty but usable tables after the clone. A few important notes: ServiceNow out-of-the-box table exclusions will still be excluded and are not affected by this setting. These include tables containing auditing, license usage, logging, and notifications. You can choose to disable this setting if you need the data from your excluded tables. This is called a ‘Full Clone’ and is recommended for upgrade or deployment testing. The legacy clone engine does not support this option. The default setting is that tables specified in the Exclusion List are excluded from a clone. Exclude audit and log data Prevents the cloning of audit and log records from the source instance. This will create empty but usable audit and log tables on the target instance. Note: If you exclude audit and log data from your clone, the Activity Stream for records will not match the source instance. This is because the Activity Stream relies on the audit table to generate the history. The default setting is that audit and log data are excluded from a clone. Exclude attachment data Prevents the cloning of certain files (incl. videos, images, documents, zip files) from the sys_attachment table. Please see exceptions below. Note: ServiceNow out-of-the-box attachments and other system-relevant files (e.g. catalog item images, theming images, icons) are not affected by this setting. The following ServiceNow out-of-the-box attachments and other system-relevant files are not affected by this setting and will not be excluded from a clone: Table name values that start with ZZ_ Table names: sys_certificate, sc_cat_item , sys_upgrade_manifest , ecc_agent_jar, ecc_agent_mib , sys_store_app , or invisible.sys_store_app This option is on by default. Preserve theme Preserves the theme and CSS elements on the target instance. As a result, your target instance will keep its theme, its look & feel after a clone. The default setting is to preserve the theme on the target instance. Lock settings for this clone request If you use a clone profile, this option locks the settings and options at the time of the clone request. Any subsequent changes to the clone profile, regardless of when the clone runs, do not affect the clone request. This option is not selected by default. Amount of data copied from the Task tables Limits the number of days of historical data for the Task table and its child tables (e.g. Incident, Problem, Change) to 90 days. Important Note: Selecting 'Last 90 days' can increase clone time, due to the post-clone deletion process of records older than 90 days. To reduce clone time, consider excluding large tables altogether. When excluding tables, your target instance will have the same table schema and hierarchy (i.e. empty usable tables) as the source instance. The default setting is to clone all data from the Task table and its child tables to the target instance. Preserve In Progress Update Sets Preserves the last 90 days of in-progress update sets in the global application scope. This option allows you to keep in-progress, global update sets created within the last 90 days on your target instance. Note:This option does not preserve your in-progress scoped update sets. Keep in mind that update sets that are older than 90 days will not be saved. As a best practice, we recommend reviewing and committing your update sets before cloning. The default is to not preserve update sets. Clone frequency This option allows you to schedule recurring clones from your source to your target instance. It allows you to define the clone frequency and the maximum number of occurrences. By default, the clone frequency is set to None. For more information about scheduling cloning, see Schedule cloning. For more information, Request a Clone. Where do I configure the data preserver? Data preserver applied to the clone target is configured on the clone source from where the clone is requested. Can I clone over my production instance and how? Here is a potential scenario of cloning over a production instance: initial go-live, where you clone over a fresh production instance which doesn't have data yet, and where data loss is not an issue. **Otherwise, this is a risky procedure, especially if your instance is already live, and we advice against it. Please contact Technical Support for assistance.** To add your production instance as a clone target you can follow the below steps: Log in to your production instanceGo to the system properties listFind system property: glide.db.clone.allow_clone_targetSet this to 'true' This will now allow this instance to be used as a clone target. Cloning over this instance is the same as any other request for a clone. After cloning is complete this property should be then set back to 'false' so you don't accidentally clone over your prod instance in the future. How to do a full clone? A full clone is when you bring over all the information from your source instance and you do not exclude any data from source. This is normally done when you want a full replica of your prod instance with logs, emails, etc. This is helpful when doing upgrading, updating sets, application deployments, etc. to see how it would run on your production instance. To request a full clone, please toggle these options: Exclude audit and log data - UncheckedExclude large attachment data - UncheckedExclude tables specified in Exclusion List - UncheckedPreserve Theme - CheckedAmount of data copied from the Task table - Full Note: Emails are disabled during the clone, so even though emails were copied across they will not send after a full clone.