System Backup
Regular backups of contents of the repository are highly recommended. Talend Data Catalog stores all the data entirely in the database, including models, the cache of what is harvested (to be used when exporting or when populating a glossary from a harvested model, as well as information maintained to support incremental harvesting), users and Admin information, and logs.
Information note
The UI based backup/restore is not a substitute for a full database backup, as it does not contain critical admin data, such as logs, history, etc.
The UI based backup/restore use cases are typically:
- For support to reproduce issues as explained in the Help: http://metaintegration.com/Products/MIMM/OEM/MITI/Help/MetadataManager/#!Documents/reportingissues.htm
- To deliver demos/tutorial
- To reproduce production in a demo/QA environment (e.g., with a backup without content and harvest in production)
- To migrate to a new type of database such as PostgreSQL to Oracle.
The rules by which the backup and restore process works are as follows:
- A repository backup may be performed at the repository root level, or at any repository sub levels. In all cases, the full path of the backup starting level is not recorded within the backup so that it can then be restored at any repository sub-levels later.
- When restoring a repository backup, some repository objects may already exist and will be reused as is (rather than overwritten) by the content of the backup.
- Any repository backup may contain repository objects having repository object dependencies, which is generally the case for a Directory, Configuration, Data Mapping, Semantic Mapping or Physical Data Model. Each dependent repository object is saved in the backup with its full path from the root. Therefore, when performing the backup, the start level name must not conflict with any root level object names.