Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

System clone

Log in to subscribe to topics and get notified when content changes.

System clone

The system clone application allows users with the clone_admin or admin role to clone data from one instance to another.

This functionality is primarily used to clone a production instance over an existing sub-production instance before developing or testing changes. All clones are performed using the most recent nightly backup.

Figure 1. Clone process
Clone process overview
In response to a clone request, the ServiceNow platform performs the following tasks:
  1. Generates a file to preserve operational data on the target server.

    This file contains the data preserved by data preservers.

  2. Copies the database schema from the source instance to the target instance.
  3. Creates tables in the target instance database using the source instance table definitions.
  4. Copies data from the most recent nightly backup of the source instance to the target instance database.

    Certain large tables are normally excluded. These include audit, log, and email tables.

  5. Briefly disables UI traffic and requests to the target instance server.
  6. Displays the message Clone in progress... to any user accessing the target instance.
  7. Restores operational data preserved from the target instance.
  8. Runs any post-clone cleanup scripts on the target instance.
  9. Briefly suspends all email functions on the target instance.
  10. Queues an event to regenerate text indexes.
  11. Enables UI traffic and requests to the target instance server.

During a clone, the target instance may be intermittently unavailable. After clone completion, you have up to 24 hours to contact ServiceNow Technical Support and request a rollback of the target instance to its pre-clone state. You are notified when the rollback is complete.

Clone to an instance on a different version

The System Clone application can target an instance running a different instance version from the source.

A central web service controls clone processing and automatically modifies the target instance version to match the source instance version. This matching process starts up to 8 hours before the time specified in the Date and time field on the System Clone form. This web service also ensures that there is enough disk space on the target instance for the clone to proceed.

When cloning from a backup, the target instance does not need additional time to upgrade or downgrade. The ServiceNow platform performs any version changes during a brief window where the target instance is unavailable, after it copies data from the source instance backup.

Clone from a backup

The platform uses data from the most recent nightly backup of the source instance when cloning. Backups used for cloning are at most 36 hours old. System Clone begins the initial preparation process, including selecting the latest backup to use, only at the date and time processing is scheduled to commence.

If a clone from backup fails for any reason, the system instead uses 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 restore the target instance from a backup and then reschedule the clone in such cases.

After cloning from a backup, the target instance is unavailable for several minutes before the clone is marked as complete in the source instance. If the source and target instances are on different versions of the ServiceNow platform, the target instance is modified to match the source instance version during this time.

When starting a clone from a backup, the date and time the backup was taken, as well as periodic progress messages, appear in the Clone Log related list.

Figure 2. System clone backup log
Clone log backup record

Clone over production instances

Production instances cannot be used as the target instance for a clone after the instance is live. Production clones are created during non-core business hours. Tables are backed up sequentially rather than simultaneously. Modifying data on the source instance during a clone can cause a data mismatch between records or duplicate record entries. This issue is minimized by running a clone after normal business hours.

When scheduling a clone for a production instance, the system automatically follows this process:
  • Determines the instance region.
  • Determines the non-core business hours for the region.
  • Restricts the possible cloning time that can be specified on the Clone Request form to the non-core hours.
Region Non-core business hours
Americas East Coast 23:00 to 04:00 Eastern time (UTC –5) and all day Saturdays and Sundays
Americas West Coast 20:00 to 01:00 Pacific time (UTC –8) and all day Saturdays and Sundays
Australia 23:00 to 04:00 Australian Eastern time (UTC +10) and all day Saturdays and Sundays
Europe Amsterdam 00:00 to 05:00 Central European time (UTC +1) and all day Saturdays and Sundays
Europe London 23:00 to 04:00 British time (UTC) and all day Saturdays and Sundays
Asia Hong Kong 23:00 to 04:00 Hong Kong time (UTC +8) and all day Saturdays and Sundays
Asia Singapore 23:00 to 04:00 Singapore standard time (UTC +8) and all day Saturdays and Sundays