Cloning a Self-Hosted Database Using KB1645366
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-17-2026 05:55 AM
Hello everyone,
KB1645366 describes how to clone a database for MariaDB and MySQL for ServiceNow self-hosted.
One of the important steps is backing up the KMF tables from the target instance. The KB provides a list of tables to back up :
- sn_kmf_identity_group
- sn_kmf_identity_group_alias
- sn_kmf_identity_group_member
- sn_kmf_resolution_framework_log
- sys_kmf_certificate
- sys_kmf_ephemeral_key
- sys_kmf_external_key
- sys_kmf_instance_key
- sys_kmf_key_metadata
- sys_kmf_module_key
- sys_kmf_wrapped_module_key
However, some of these do not exist or no longer exist. They no longer appear in the sys_db_object and sys_storage_table_alias tables.
For example, on Yokohama Patch 5 (the version we’re using, which will be migrated to Australia Patch 3 after we create a clone of the DEV environment :)) and on Australia Patch 2 (a PDI I just created), the following tables do not exist:
- sn_kmf_identity_group
- sn_kmf_identity_group_member
Is it possible that these tables existed in previous versions of ServiceNow?
Furthermore, if we search for all tables related to kmf (whose names contain “kmf”), we find 33 for Yokohama and 36 for Australia.
How should we interpret this information? Since the KB was updated in April 2026, is it possible that the list of tables to back up is not exhaustive?
Thank you for your help.
Regards,
Francis
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago - last edited 2 weeks ago
@Auverland Did you have any luck? I'm in the same boat.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hello,
The fact that those two tables are absent from both your Yokohama Patch 5 instance and an Australia Patch 2 PDI suggests they may be legacy tables that existed in earlier KMF implementations, rather than tables that every current release should contain. I would not assume that all 33/36 tables containing kmf need to be backed up. The KB’s list is likely intended to identify the specific KMF tables relevant to the self-hosted database-cloning procedure, rather than every table whose name happens to contain kmf. ServiceNow’s documentation also indicates that KMF and key-exchange behavior has evolved across releases.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
I'm not sure I understand. Is this message really meant for me, or is it for ChauV?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
@Auverland It was for you. Accidentally @'d the wrong person!
