--- sourceDocument: Australia ServiceNow AI Platform Administration sourceDocumentLink: https://www.servicenow.com/docs/r/platform-administration Release : - australia ft:locale : - en-US ft:publication_title : - Australia ServiceNow AI Platform Administration ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # Explore # Exploring Instance Clone {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Exploring Instance Clone Instance Clone enables ServiceNow customers to copy the entire database, including data and configurations, from a source instance to a target instance. This process overwrites the target instance, aligning it closely with the source to create a consistent testing or development environment. Cloning is especially useful for sub-production instances that diverge over time from production, allowing for reset and synchronization. Show full answer Show less Common use cases include validating upgrades, testing new applications, and exploring new capabilities safely without impacting production environments. ## Key Features * **Clone Workflow:** The cloning process involves several phases: configuration, preflight health checks, backup utilization (using the latest daily backup or on-demand backup), pre-clone preparations, database provisioning, restoring data, handling exclusions and preservers, node repointing, script scheduling, and post-clone cleanup. * **Backup Source:** Cloning uses backups no older than 36 hours to ensure up-to-date data transfer. Users can see backup timestamps and clone progress in the Clone log. * **Exclusions and Preservers:** Customers can define specific tables to exclude from cloning or preserve certain data from the target instance, enabling tailored clone outcomes. * **Version Compatibility:** Clones can be performed between instances on different ServiceNow release versions. The target instance is upgraded or downgraded to match the source version during cloning. * **Clone Administration:** Only users with the cloneadmin role can request, cancel, or schedule clones through the Clone Admin Console, which replaces the legacy Instance Clone interface starting with the Australia release. * **Safety Controls:** The system property `glide.db.clone.allowclonetarget` controls whether a production instance can be used as a clone target, helping prevent accidental overwrites of production environments. ## Practical Benefits for ServiceNow Customers * **Consistent Test Environments:** Quickly reset sub-production instances to mirror production, ensuring reliable testing conditions. * **Flexibility in Use Cases:** Supports various scenarios such as validating upgrades and testing new capabilities without risking production stability. * **Controlled Data Management:** Use exclusions and preservers to customize what data is cloned, preserving sensitive or environment-specific information as needed. * **Efficient Version Management:** Seamlessly clone across different release versions, keeping target instances aligned with source versions automatically. * **Modern Interface and Logging:** The Clone Admin Console provides a streamlined, up-to-date interface with visibility into script status and clone progress for better management. Explore how to use a clone to copy everything in a database from one instance to another. ## Instance Clone overview {#exploring-instance-clone__cf-exploring-parent-overview} Clone copies data and configuration from a source instance to a target instance, overwriting the target. After a clone, your environment closely resembles the source instance and allows you to safely test changes. Sub-production instances drift from production over time; clone resets that divergence. Common use cases include: * Validating upgrades * Testing new applications * Testing new capabilities {#exploring-instance-clone__instance-clone-landing_ul_prf_5bc_zfc} Clone data is sourced from the most recent daily backup of the source instance. For clone terminology and definitions, see [Clone terminology](https://www.servicenow.com/docs/WmY0lMPR7eIQEpZSw07gYg "A reference topic that contains various terms and definitions for cloning."). ## Instance Clone workflow {#exploring-instance-clone__section_vhg_ppv_nfc} Figure 1. Instance Clone workflow diagram 1. Clone build configuration: Basic definitions, configurations, and profile options are prepared. Data to be included, excluded, or preserved is verified. 2. Preflight checks: The clone checks the source and target instances to verify that they are in a healthy state before proceeding with the clone. 3. Backup: Uses the latest daily backup. If there were major recent changes, a new backup is created. You can also trigger a new backup manually by selecting On-demand backup in the Clone Admin Console. 4. Pre-Clone: Prepares space for the new database before restoring it. 5. Provision database instance (DBI): A new target instance is set up to receive the restored data. 6. Restore: The backup data is restored to the new target instance. 7. Exclusions: Tables marked for exclusion are deleted. 8. Preservers: Data is preserved from the old target (pre-clone instance) and is copied to the new target instance. 9. Node repoint: The system switches from the old target to the new clone without user disruption. 10. Scheduling scripts: All scripts are scheduled to run in the global scope. Starting with the Australia Patch 5 release, script status is visible. Any changes to cleanup scripts, which are defined on the source, must happen before the Restore phase of a clone to be processed within that clone request. 11. Post Clone: The instance is set up in its own phase. Cleanup scripts run after the clone shows as Complete. To view cleanup script status on the source instance, enable Multi-Instance View. Both instances must be on Australia Patch 5 or later. {#exploring-instance-clone__ol_yfr_ppv_nfc} ## Instance Clone users {#exploring-instance-clone__section_gjg_ylg_pgc} {#exploring-instance-clone__table_mld_zlg_pgc__entry__2} | User | Description | |-|-| | Clone Administrator | Clone admins with the clone_admin role can request, cancel, or schedule clones. | [ ] {#exploring-instance-clone__table_mld_zlg_pgc} ## Instance Clone benefits {#exploring-instance-clone__section_vbz_qwx_kgc} {#exploring-instance-clone__table_vpv_hfg_ngc__entry__2} | Benefit | Feature | |-|-| | Tidy up data with exclusions and preservers for specific clone scenarios. | [Definitions](https://www.servicenow.com/docs/VafoUAje8r~2sFhIi2vjjQ "Use clone definitions such as exclusions, preservers, and cleanup scripts in your clone.") | | Establish consistent clone outcomes with clone profiles and registered instances. | [Configuration](https://www.servicenow.com/docs/nn0cpcLNvUattE0FAkYs6w "Use the Configuration menu to access all clone-related settings, including exclusions, preservers, cleanup scripts, clone profiles, and clone instances.") | | Copy data from a production instance to a non-production instance or to copy data between non-production instances. | [Request a clone](https://www.servicenow.com/docs/TcHcTrs~luy2sg1TDGIsvQ#t_StartAClone "Request a clone to copy data from a production instance to a non-production instance or to copy data between non-production instances.") | [ ] {#exploring-instance-clone__table_vpv_hfg_ngc} ## Instance Clone use cases {#exploring-instance-clone__section_bhg_brn_vgc} ## Clone to a different version {#exploring-instance-clone__section_snh_jrn_vgc} You can clone between instances that are on different family release versions. During a clone, the source version replaces the target version. For example, if you clone from Source (Zurich) to Target (Yokohama) the target will match the source after the clone and be on Zurich release. ## Clone from a backup {#exploring-instance-clone__section_jnj_kxz_5gc} The clone uses data from the most recent, daily backup of the source instance when cloning. Backups that are used for cloning are a maximum of 36 hours old. A clone from backup starts only at the date and time processing that it's scheduled to start. If the source and target instances are on different versions of the ServiceNow AI Platform, the target instance is modified to match the source instance version during this time. When starting a clone from a backup, the Clone log displays the date and time the backup was taken. Periodic progress messages also appear in the Clone log at the bottom of the clone status page. ## Clone over production instances {#exploring-instance-clone__section_knj_kxz_5gc} As long as the system property glide.db.clone.allow_clone_target is TRUE, an instance can serve as a clone target. Ensure the property glide.db.clone.allow_clone_target is set back to FALSE after a production instance has served as a clone target. This prevents accidental clones over production in the future. Note: Beginning with the Australia release, users attempting to access the legacy Instance Clone page, clone_instance.do, are redirected instead to the [Clone Admin Console](https://www.servicenow.com/docs/drWP2ZygnGQjiVNrIzV5pA#Clone-UI "The Clone Admin Console is the user interface where administrators can manage, request, and monitor their instance clones."). To view clone history for clones prior to the Australia release, view the legacy Clone History \[clone_instance\] table. For more information about using Clone Admin Console instead of the legacy Instance Clone, see [KB1425858: Clone Admin Console: Quick Start Guide \& Instructions](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1425858).