What are the best practices for cloning a databases?
IMPORTANT: Do not use this article when replacing servers in an existing environment. This article is intended to be used when cloning one environment into another environment. When replacing or moving Insight servers, please refer to KB 3040455
There are use-cases that require cloning production-level data into a lower environment. If using the provided features within Insight are not feasible (import/export), this article provides an alternative method and best practices for moving Insight databases between two environments.
There is risk with performing this. Part of those risks include data loss. This article makes every effort to minimize those risks but there may be topics not documented here - detailed testing should be done after reviewing this article. Proper backups from all environments should be taken prior to starting this.
This article is subject to updates to ensure quality and accuracy. Information is provided as “best effort” support and has not been formally tested by Kofax.
This article relates to core Insight product. If you are using Kofax analytics products such as Kofax Analytics for Capture (KAFC), Kofax Analytics for KTA (KAFTA), Kofax Analytics for RPA, etc., refer to their respective documents and KB articles in conjunction with this article to ensure you have all the latest information. Integration components related to those analytics products are not documented here.
This article assumes a single-tenant, on-premise Insight installation. Cloud-based, multi-tenant and Docker installations are beyond the scope of this article.
“Source environment” refers to the environment from which the databases are pulled from. “Destination environment” is where you wish to move the databases to.
To further ensure the safety of your source environment’s Insight data, use database and Windows accounts in your destination environment that do not have access to the source environment.
Types of Insight Databases
An Insight project consist of at least two databases per project (Meta and Data) and potentially a Staging database depending on project design. Insight also requires an administrative database to manage its configuration and projects (referred to as admin database). Therefore, there are at least three databases when a single project is created.
Each project will have one or more data-sources that provide the data for your views and dashboards (i.e., external databases or file-based data sources).
Insight’s admin database should not be moved and is not supported. Two environments have different domains and / or forests, therefore, the authentication method (queries, user mappings, Role properties, etc.) used in one environment may not work in the destination environment. E-mail settings and H/A among other options are also different between environments. All these settings are stored in the admin database.
The destination environment has its own admin database; therefore, only project-related databases should be moved. If there are admin-related settings in the source environment that you need, use the export utility to export those settings (found in the Tools tab in Administration application) and import them into the destination environment. You can also use the Add Existing option to attach meta and data databases from another environment. Refer to the Help for more information udner creating new projects.
Similarly, to move custom themes and formats, use the export utility in the Themes application to export and import between environments.
Moving Project Databases
Both source and destination environments should be on the same version, including Service- and Fix-pack level. If not, these databases will be updated when Insight adds them into the destination environment, assuming the upgrade path is supported (refer to the Insight Installation Guide for supported upgrade paths). A newer version cannot be cloned into an older version.
Regardless of what database type is used (Oracle, SQL Server, etc.), use your existing backup and restore process to restore the project databases into your destination environment.
As an added safety measure to prevent impact to the source environment, consider blocking network traffic between the source and destination environments and use database and Windows accounts that are not authorized to access source environment data.
Perform the following in your destination environment.
- Stop all Scheduler services.
- In Administration application, create a new project or open existing project you wish to bring these databases into.
- From Projects tree, highlight the project. Information for the meta database is displayed for your existing (source environment’s) configuration.
- Change the database connection information for your meta database and save. NOTE: Connect button will not work because the scheduler service is currently down.
- Complete the remaining connections under this project (Data, etc.) by updating the connection information and clicking the save button.
- Click on the Connections tree and update all sources listed for your destination environment.
10. Close Admin application and log into Studio.
11. Click Data Sources tree and verify all the connection information is updated.
12. Click Reports tree and update all e-mail settings, if applicable.
13. Click File Processor tree and review all sub-sections, updating all information to reflect your destination environment, if applicable.
14. Click Execution Plans tree and update all tasks that pertain only to the source environment (Run external program or Run FTP Task, for example) and update accordingly.
15. Click Remote Services tree and update all URL’s that may be using the source environment, if applicable.
16. Start all Scheduler services.
17. Test the newly imported project in your destination environment.
Level of Complexity