Backing Up and Restoring with Packages

Although the package resource is the mechanism used to distribute ESM security use cases and Solution CIPs, packages are also designed as a backup mechanism for resources on running systems.

Resources can be part of more than one package. Therefore there are some behaviors associated with packages that may seem counter-intuitive and bear consideration.

ID Checking During Import

When a package is imported, there are some automatic ID checks:

1. The system looks for any other existing packages in the system with the same resource ID. This is the ID the system gave to the package when you created it.

   • If there are none, it imports the package and the process ends, unless there is a package in the same group with the same name.

   • If there is another package with the same resource ID, the evaluation goes to step 2.

2. The system compares the package version IDs for the importing and existing packages that share the same resource ID. The version ID is the ID the system gave to the package when the package was exported.

   • If the package version ID being imported matches the package version ID currently installed on the system, the package import process stops, because the system assumes that this package is already imported.

   • If the version IDs do not match, the evaluation goes to step 3.

3. The system checks each resource within the package to see if each version ID matches an installed resource with the same resource ID or URI (path and resource name).

   • If they match, the matching resource is not imported and the system checks the next resource.

   • If the version IDs do not match, the existing resource is over-written with the one in the package being imported, unless you choose to import the package without installing.

   If you import the package without installing it, the new package resource information is saved in ESM as an update and the icon changes to a small white up arrow in the lower left corner ().

Package Modifications

A package archive is a system data structure that contains the information defining a package and its resources. As you change a package and its resources, this file is not updated until you export the package. This enables the package to support the Compare Archive with Current Package Contents feature (from the package’s right-click menu). This command allows you to see the packaged contents, for both the package last exported (the archive), and the current contents. The "Change Since Archive" column shows whether a given resource has been deleted, removed or modified.

When you export a package, the package’s version ID is regenerated, regardless of whether the package attributes or any of its resources actually changed. This is not the case with the included resources; their individual version IDs only change upon export if the resource itself changed.

When you create a package, there is no version ID until you export it. Whenever you see a package with no version ID, that means there is no exported backup.

List Data

Active lists and session lists have two different uses as part of a package, and these affect how you would export the lists for backup purposes:

• The other resources in the package use the list to store data. The data is generated and used at run time. If, when you export the package, you do not need to save the data that accumulated in the list from the last run, use the Export package format.

• The list contains data that other resources in the package, such as rules, need specifically. If, when you export the package you must save the content of these lists, use the Default package format.

If you have a package containing some lists used only as containers and others with specific necessary data, use the Default format. The container lists would import again with data you do not need, but it is better than losing data you do need. Alternately, you could put the lists with required data into a second package using the Default format, and make this new package required for the first package, which uses the Export format.

Backup and Restore Summary

The version ID changes affect the results when importing a package in an effort to restore an existing package to a previous state.

• The system does not import a package backup if the version IDs of the package resource match.

• To make the existing system have a different version ID than the backup, you must export it again (being sure not to overwrite the backup you want to restore).

• If the existing package is bad and you have a good backup, you can always delete the existing package and then import the backup package.

• If you create a package that includes a top-level resource group (All Actors, for example), so you can back up the entire group, export the package often enough that all the recent changes are captured. If you ever delete such a package, it deletes the top-level group and every resource that has been added to the group, regardless of whether those new resources were added to the package. Be careful. Consider using the Children Only option.

• Generated version IDs do not identify which version ID is newer. For packages with the same resource ID, the system can only tell whether their version IDs are the same or different.

• To revert back to the last version imported, you must either delete the existing package or export it to some other location. Doing so sets a new version ID and places the export so as not to overwrite your backup. The backup package can now overwrite the existing package when you import it.

• Changing the name of an .arb file does not change the name, resource ID, or version ID of the package.

• If you currently have a package with version 1.1, and you want to import the backup package with version 1.0, there may be conflicts or other issues. See Resolving Package Conflicts.