Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



Traditional Backup & Restore (Database and Files)

AIP Backup & Restore

Supported Backup/Restore Types



Can Backup & Restore all DSpace Content easily

Yes (Requires two backups/restores – one for Database and one for Files)

Yes (Though, will not backup/restore items which are not officially "in archive")

Can Backup & Restore a Single Community/Collection/Item easily

No (It is possible, but requires a strong understanding of DSpace database structure & folder organization in order to only backup & restore metadata/files belonging to that single object)


Backups can be used to move one or more Community/Collection/Items to another DSpace system easily.

No (Again, it is possible, but requires a strong understanding of DSpace database structure & folder organization in order to only move metadata/files belonging to that object)


Supported Object Types During Backup & Restore



Supports backup/restore of all Communities/Collections/Items (including metadata, files, logos, etc.)



Supports backup/restore of all People/Groups/Permissions



Supports backup/restore of all Collection-specific Item Templates



Supports backup/restore of all Collection Harvesting settings (only for Collections which pull in all Items via OAI-PMH or OAI-ORE)


No (This is a known issue. All previously harvested Items will be restored, but the OAI-PMH/OAI-ORE harvesting settings will be lost during the restore process.)

Supports backup/restore of all Withdrawn (but not deleted) Items



Supports backup/restore of Item Mappings between Collections


Yes (During restore, the AIP Ingester may throw a false "Could not find a parent DSpaceObject" error (see Common Issues or Error Messages), if it tries to restore an Item Mapping to a Collection that it hasn't yet restored. But this error can be safely bypassed using the 'skipIfParentMissing' flag (see Additional Packager Options for more details).

Supports backup/restore of all in-process, uncompleted Submissions (or those currently in an approval workflow)


No (AIPs are only generated for objects which are completed and considered "in archive")

Supports backup/restore of Items using custom Metadata Schemas & Fields


Yes (Custom Metadata Fields will be automatically recreated. Custom Metadata Schemas must be manually created first, in order for DSpace to be able to recreate custom fields belonging to that schema. See Common Issues or Error Messages for more details.)

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="8e3c2a28b2b4de9c-11f4eaaa-45ce4ae5-918fbaac-a141923a5966fc769c5fbe23"><ac:plain-text-body><![CDATA[

Supports backup/restore of all local DSpace Configurations and Customizations

Yes (if you backup your entire DSpace directory as part of backing up your files)

Not by default (unless your also backup parts of your DSpace directory – note, you wouldn't need to backup the '[dspace]/assetstore' folder again, as those files are already included in AIPs)



titleMissing Groups or EPeople cannot be created by Community / Collection AIPs

Please note, if you are using AIPs to move an entire Community or Collection from one DSpace to another, there is a known issue (see DS-1105) that the new DSpace instance will be unable to (re-)create any DSpace Groups or EPeople which are referenced by a Community or Collection AIP. The reason is that the Community or Collection AIP itself doesn't contain enough information to create those Groups or EPeople (rather that info is stored in the SITE AIP, for usage during Full Site Restores).

However, there are two possible ways to get around this known issue:

  • EITHER, you can manually recreate all referenced Groups/EPeople in the new DSpace that you are submitting the Community or Collection AIP into.
    • Note that if you are using Groups named with DSpace Database IDs (e.g. COMMUNITY_1_ADMIN, COLLECTION_2_SUBMIT), you may first need to rename those groups to no longer include Database IDs (e.g. MY_SUBMITTERS). The reason is that Database IDs will likely change when you move a Community or Collection to a new DSpace installation.
  • OR, you can temporarily disable the export import of Group/EPeople information when generating submitting the Community or Collection AIP to the new DSpace. This would mean that after you submit the AIP to another the new DSpace, you'd have to manually go in and add in any special permissions (as needed). To disable the export import of Group/EPeople information, add these settings to your dspace.cfg file, and re-export run the submission of the AIP with these settings in place:
    Code Block
    mets.dspaceAIP.ingest.crosswalk.METSRIGHTS = NIL
    mets.dspaceAIP.ingest.crosswalk.DSPACE-ROLES = NIL
    • Don't forget to remove these settings after you re-export import your Community or Collection AIP. Leaving them in place will mean that all your AIPs will be exported without Groups/EPeople/Rights/Permissions in the futureevery time you import an AIP, all of its Group/EPeople/Permissions would be ignored.
Submitting AIP(s) while skipping any Collection Approval Workflows


Issue / Error Message

How to Fix this Problem

Ingest/Restore Error: "Group Administrator already exists"

If you receive this problem, you are likely attempting to Restore an Entire Site, but are not running the command in Force Replace Mode (-r -f). Please see the section on Restoring an Entire Site for more details on the flags you should be using.

Ingest/Restore Error: "Unknown Metadata Schema encountered (mycustomschema)"

If you receive this problem, one or more of your Items is using a custom metadata schema which DSpace is currently not aware of (in the example, the schema is named "mycustomschema"). Because DSpace AIPs do not contain enough details to recreate the missing Metadata Schema, you must create it manually via the DSpace Admin UI. Please note that you only need to create the Schema. You do not need to manually create all the fields belonging to that schema, as DSpace will do that for you as it restores each AIP. Once the schema is created in DSpace, re-run your restore command. DSpace will automatically re-create all fields belonging to that custom metadata schema as it restores each Item that uses that schema.

Ingest Error: "Could not find a parent DSpaceObject referenced as 'xxx/xxx'"

When you encounter this error message it means that an object could not be ingested/restored as it belongs to a parent object which doesn't currently exist in your DSpace instance. During a full restore process, this error can be skipped over and treated as a warning by specifying the 'skipIfParentMissing=true' option (see Additional Packager Options). If you have a larger number of Items which are mapped to multiple Collections, the AIP Ingester will sometimes attempt to restore an item mapping before the Collection itself has been restored (thus throwing this error). Luckily, this is not anything to be concerned about. As soon as the Collection is restored, the Item Mapping which caused the error will also be automatically restored. So, if you encounter this error during a full restore, it is safe to bypass this error message using the 'skipIfParentMissing=true' option. All your Item Mappings should still be restored correctly.

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="45d4d1c0659db09d-0960fea5-48af4999-aa1a9fa4-7ccb91330acbac2b33c53037"><ac:plain-text-body><![CDATA[

Submit Error: PSQLException: ERROR: duplicate key value violates unique constraint "handle_handle_key"

This error means that while submitting one or more AIPs, DSpace encountered a Handle conflict. This is a general error the may occur in DSpace if your Handle sequence has somehow become out-of-date. However, it's easy to fix. Just run the [dspace]/etc/postgres/update-sequences.sql script (or if you are using Oracle, run: [dspace]/etc/oracle/update-sequences.sql).