Cloning Back - Table Exclusion Best Practice

[Sam Ogden]

Hi All,

We are at a position where we need to request a clone back from Prod into our TEST and DEV instances.

We have only once previously had a clone, and we realised after this that we would of been better place to have excluded some tables.

I was wondering if anyone had any advise on which tables are best to add to the system clone >exclude tables

I need to add the sys_user table to this as we encounted issues with logging in to the instances etc.

Any help on any best practice or tips of tables to exclude will be very useful

Thanks

Sam

[joost2]

Hi Sam,

I would not recommend excluding the sys_user table nor to create data preservers. If you have users on the target instance that you want to backup you should do an export to xml for the following three tables and import them back again.

1. sys_user

2. sys_user_grmember

3. sys_user_has_role

Make sure you export the group member and role records for the users you backed up from sys_user.

This recommendation is based on three years of experience cloning.

Best things to preserve are system properties.

Excluding tables is quite hard since you can only exclude tables that are not extended from another table (if you do it anyway you will end up with orphan records in the base table).

Kind Regards,

Joost

[Sam Ogden]

Hi Joost,

Thanks for the above.   What issues would excluding the sys_user table cause?

The trouble we had previously is we use SSO in Production and TESt, but not in DEV.   The clone back meant - no-one could login to DEV.

Are there any tables you would recommend that we exclude, or any other tips you have for cloning back?

Thanks

Sam

[joost2]

Hi Sam,

Well first of all if you exclude the sys_user table you would not have any users on your DEV instance. Not having any users means not having an account you can use to log in with. Also these users could includes Servicenow maint accounts that are not visible to you leaving you with an instance nobody can log into not even Servicenow. You could set up data preservers for the three tables I mentioned, but since you can't be sure in which order the tables are restored there could be issues with the references.

Best practice is to have some admin accounts on Prod that have a Servicenow password set which you can use to log into your DEV instance with after the clone. You could try this in combination with data preservers for the three tables, but my experience with that setup has not been good, which is why I use the XML.

Kind Regards,

Joost

[Sam Ogden]

Thanks for the above,

In your experience are there tables that we should be looking to exclude?

Any other areas which are common pitfalls when performing a clone that we can pre-empt?

Thanks

Sam