Taking Backups in PowerCenter. Why care at all? – Part 1

Taking a backup of your daily work usually is a time-consuming task. There are several points to consider:

• A backup file can only be created for a whole repository. It is, for example, not possible to back up only one single repository folder. Administrators will usually not be too happy when you ask them to extract one mapping from one of 440 project folders stored in a backup file. Not to mention that in most cases they will not have a free database at hand (resp. DB schema) where this “partial” restore can be performed.
• Restoring a repository backup file can take a long time. For a file size of 2 GB it is not uncommon that the restore process will take app. 25-30 minutes. During this period no one can work with the repository, meaning all developers are blocked. So no administrator will restore a backup file to any of the repositories you’re working with while anyone is working, they have to set up a fresh DB first.
• In most cases a developer does not need a complete backup of her/his folder, only back-up copies of some important and delicate objects currently “under construction”.
• An average developer will never have permission to create backup files of a repository.

As every administrator should establish a back-up strategy for the whole repository, a developer can be sure that (s)he loses at most one day of work in case of e.g. a hard disk crash. While in most cases this is more than sufficient, even one single day can become a real disaster for developers. Here’s a real-life example:

Imagine you are working hard on one particular part of your project. You have been struggling for days to make it work, you applied the last few changes, and after four days it finally works.  You save the work and go home, knowing that the next morning you have plenty of time to copy over all those objects from your personal development folder to the project folder.

The next morning you come to work. You learn that the hard disk of the DB holding the repository crashed last night, shortly before the backup process was scheduled to commence. The administrators already have restored the backup file from the night before yesterday, meaning all your developments from yesterday are gone. You have to do it all again.

In order to avoid such problems, a personal “back-up strategy” can be very helpful. Nevertheless such a personal back-up strategy must fit the technical environment, so before going into the strategic details I’ll first talk about the technical background.

Informatica uses the term “backup” solely for a full repository backup. There is no way to create a backup file for any individual objects, only for a repository as a whole.

However, Informatica provides a means of “exporting” objects from the repository (that means, to create XML files containing all the metadata for one or more repository objects). There are several ways to create these XML files. Originally these XML files have been designed to be copied to some other environment so that they can be “imported” into the other environment; in other words, XML exports have been the first implementation by Informatica to support an automated deployment from e.g. DEV to TEST and to PROD environments.

Now this feature of “exporting” objects to XML files can be used not only in order to deploy objects from e.g. the development environment to the test environment. These XML files can – because they are nothing but text files in a special format – be copied anywhere. In particular a developer can create a XML export for all sorts of objects from arbitrary folders within one repository and then simply keep this XML file in a safe place (be it on the hard disk of his/her work PC, a network drive, or wherever).

So a “personal back-up strategy” means either a full repository backup or using such XML export. A developer can always “restore” objects from a XML export file (namely import them from the XML file) into a PowerCenter repository as long as the following requisites are met:

• • The developer has been granted access privilege to the repository service.
  • The developer has sufficient permissions on the repository service (e.g. the PowerCenter Developer role).
  • The developer has write permission on the affected repository folder(s).
  • The folder is in Active state (assuming that Enable Version Control has been set for the repository, without version control all folders are always active).
  • The developer has permission to use the respective Windows client tools, meaning the Repository Manager and/or the Designer and/or the Workflow Manager (depending on the kinds of objects you want to import).
  • The XML file has been produced in a code page “compatible” with the repository database (see next paragraph).
  • The XML file originates from the same PowerCenter version as the PowerCenter repository into which these objects shall be imported.[1]

While this list is pretty long and detailed, an average developer will usually have all these privileges, permissions, and so on. If any of these points were missing, a developer could not develop any objects in a PowerCenter repository, so these points (with one potential exception, see next paragraph) are always fulfilled in a DEV environment.

There is one noteworthy issue with this list, namely the last point, the repository version of the XML file. This is a complex matter on its own, and here is why (slightly simplified):

1. Informatica requires that XML files be imported only into a repository of the same version as the repository from which this XML file has been created.
2. From time to time the XSD and DTD files used to define the structure and contents of these XML exports are changed by Informatica. This may or may not, for example, happen with each new software version and/or each new hotfix. Informatica did never and does not provide any information about whether the underlying XSD and DTD files have been changed for a new software version / hotfix or not.
3. Informatica also does not publish any information about the contents of the XML files in one or the other version.

These (and quite a few other) reasons lead to an interesting effect: in many cases a XML export from e.g. version 10.1 can be imported into a repository running in version 10.1.1 Hotfix 1 without hassle. But there is no guarantee that such a “switch” between software and hotfix versions will work fine. The author knows of more than one occasion where e.g. 50 workflows exported to some XML files in version 10.1 could be imported into a 10.2 repository, but for no apparent reason one of these workflows could not be rescheduled, unscheduled, or executed from the Workflow Manager or the Workflow Monitor tools. No chance. Not even a manual change to this workflow worked; no error message was given anywhere, but this workflow could not be rescheduled or unscheduled from any client tool. A standard repository upgrade was the only remedy for this strange behaviour.

From these experiences it is strongly suggested that XML files be only imported into the exact same software version from which they have been exported.

Whenever your organisation upgrades PowerCenter in any way, make sure that you import your personal back-up files before the upgrade and re-export them from the new software version after the upgrade.

In summary, PowerCenter offers the following methods of creating something like a “backup” file:

1. Creating a back-up file for a whole repository,
2. Creating one XML export file for a complete folder (including all shared folders holding objects which are referenced from the folder to be backed up),
3. Creating XML export files for individual objects (such as a mapping or a workflow),
4. Creating one XML export file for several objects in one XML file.

Let’s look at these one by one.

First about backup files. Caring for backup files being generated on a regular basis is an administrative task. In case you are your own administrator:

• You can do that either in the Administrator tool (manual execution) or using the command-line tool pmrep (batch execution).
• When you create a backup file (be it in the Administrator tool or using pmrep), the backup file is invariably created in the backup directory of the current master gateway node of the Informatica domain. In order to find out this directory, log on to the Administrator tool, go to the menu item Manage à Services And Nodes, and look at the properties of the node(s).
• The documentation for pmrep states that the command-line option –o would allow you to indicate the path where the backup file shall be created. This information is incorrect: it is impossible to indicate any other directory path than the backup directory of the node.[2]

Everything about the XML exports can be found in parts two this blog post. Stay tuned!

[1] Actually the repository version of the XML export file must equal the repository version of the repository service into which to import the XML file. More details in https://knowledge.informatica.com/s/article/10436 , this article lists all repository versions since PowerCenter 6.2.

[2] Using pmrep you can create backup files which are not located in the backup directory of the node. You do so by indicating a relative(!) path starting from this backup directory (giving an absolute path to option –o does not work). For example, if you create a subdirectory T20210616 in the backup directory of the node, you can tell pmrep to store a backup file in this subdirectory, like this (in the syntax of a shell script under Unix/Linux): pmrep backup -d MyDomain -r MyRepository -o T20210616/today.rep You can later restore such a backup file using pmrep restore. But you cannot access these backup files in other directories from the Administrator tool; the Administrator tool solely looks at the backup directory.