...

Again, this would export the DSpace Site AIP into the file "sitewide-aip.zip", and export AIPs for all Communities, Collections and Items into the "/path/to/children-aips" directory.

Ingesting / Restoring AIPs

Again, like export, there are two main "modes" you can run the AIP packager in:

...

Restoring an AIP Hierarchy

...

Restoring is slightly different than just re-ingesting. When restoring, we want to retain the old Handles and Parent Objects within the Hierarchy. So, it's similar to the Ingesting an AIP Hierarchy instructions above, but it doesn't specify the ignoreParent or ignoreHandle parameters (as we obviously want to retain this information

There are currently two main restore modes:

1. Default Restore Mode (-r) = Attempt to restore object (and optionally children). Rollback all changes if any object is found to already exist.
2. Restore, Keep Existing Mode (-r -k) = Attempt to restore object (and optionally children). If an object is found to already exist, skip over it (and all children objects), and continue to restore all other non-existing objects.

Default Restore Mode

By default, the restore mode (-r option) will rollback all changes if any object is found to already exist. The user will be informed if which object already exists within their DSpace installation.

For example:

 /dspace/bin/dspace packager -r -t AIP -e admin@myu.edu \
                             -c /path/to/children-aips/ aip4567.zip

Notice that unlike -s option (for submission/ingesting), the -r option does not require the Parent Object (-p option) to be specified if it can be determined from the package itself.

In the above example, the package "aip4567.zip" is restored to the DSpace installation with the Handle provided within the package itself (and added as a child of the parent object specified within the package itself). In addition, any child AIPs referenced by "aip4567.zip" in the folder "/path/to/children-aips" are also recursively ingested. They are also restored with the Handles & Parent Objects provided with their package. If any object is found to already exist, all changes are rolled back (i.e. nothing is restored to DSpace)

Restore, Keep Existing Mode

When the "Keep Existing" flag (-k option) is specified, the restore will attempt to skip over any objects found to already exist. It will report to the user that the object was found to exist (and was not modified or changed). It will then continue to restore all objects which do not already exist.

One special case to note: If a Collection or Community is found to already exist, its child objects are also skipped over. So, this mode will not auto-restore items to an existing Collection.

For example:

 /dspace/bin/dspace packager -r -sk -t AIP -e admin@myu.edu -p 4321/12.edu \
                             -c /path/to/children-aips/ aip4567.zip

In this casethe above example, the package "aip4567.zip" is restored to the DSpace installation with the Handle provided within the package itself (and added as a child of the parent object specified within the package itself). In addition, any child AIPs referenced by "aip4567.zip" in the folder "/path/to/children-aips" are also recursively ingested. They are also restored with the Handles & Parent Objects provided with their package. If any object is found to already exist, it is skipped over (child objects are also skipped). All non-existing objects are restored.

...

Restoring Entire Site

Details Coming Soon! In all likelihood it will take the same parameters as the "Exporting entire Site", except that you'll be running the packager in -sr (submitrestore) mode.

Discussion / Use Cases

...