Skip to main content

Backup and Restore

Information note

The Talend Data Catalog Backup and Restore are not a substitute for the repository database backup and not a means for upgrading the system. I.e., never try to restore a backup from an older major release version to a newer one.

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.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!