How to use packeger to copy/restore structure of a big repository?

[Veronica Fernandez]

I try to migrate a very big repository to a new fresh install of 6.3, but I'didn't get it because I cannot "cut" it into communities because the import of them return me errors of dependencies at collections administrative groups. 

You cannot restore collections if groups doesn´t exists but how can i get all epersons and groups created ??

If I try to export the entire site I have a lot of problems of memory and timeout. I think a posibility is to export excluding boundles or something similar, the target is to get the same "structural information" in both installations

Has somebody experience with packager and a big repository?

Thank you

[Michael Plate]

Hi Veronica,

Am 08.10.21 um 11:57 schrieb Veronica Fernandez:

[…]

I think you have to split !

I've done this 3 years ago during an upgrade from 1.7.x, and this took a
around a week (on 3500 items) w/o split.

However, I did this lately more often with the beta of DSpace 7, and it
was horrible (~6000 items).

I have a lengthy description on behalf of a part of our disaster
recovery, and its weird.

Try with the sitewide.zip w/o recursive (-a), this should give you the
groups and the epersons (at least they are in the mets.xml).
Then try from top to bottom the first level communities.

If you have added own metadata fields, create them first in the empty
repository, else DSpace 6 will fail (in contrast to DSpace 5, which will
autocreate them).

Hope this helps,

Michael

[Tim Donohue]

Hi,

Just a quick note on migration.  If you are simply migrating your DSpace content from one server to another, you don't need to use the packager or similar tools. Instead, just copy over the following:

* Copy your entire database contents to your new database (e.g. for Postgres, use tools like pg_dump and pg_restore). This copies all metadata/relationships over to the new server

* Copy over your entire [dspace]/assetstore folder (including all subdirectories) to the new location. This copies all files over to the new server.

* Verify your new configs look good in [dspace]/config/ folder (you can copy these over from the old server or start fresh, either will work)

* Optionally, run "./dspace database migrate" to upgrade the database (if you are moving from 5.x to 6.x or similar, this is required)

* Start up your DSpace.

* Finally, run a full reindex of everything into Solr (./dspace index-discovery -b)

This migration process should result in all your content moved over to a fresh DSpace without having to use the packager at all. 

Tim

[Veronica Fernandez]

After trying several options using packager I decided to use traditional migration by copying assetstore and database.

I had to execute migrate and I resolved manually some problems (it try to delete a database object that donesn't exist).

Now my new dspace6.3 is working, I see all the items (I've reindexed them without problems) but I cannot see the the pages of communities nor collections.

I suspect that there is aproblem with the handle of the commumities /collections.

Anybody can help??

thanks

Veronica

[Veronica Fernandez]

I have had to restore manually all the handles of communities/collections from the original database, big repository about 72 communities and 892 collections, and now it seems to be OK.

 I don't know what has happened. We use oracle12 and the column resource_id of table handle was completely full of "null", but, thank goodness, the UUID were correct in the table communities, collections and, of course, in matadatavalue, and I have the original database.

 After my experience I think it's a good idea a packager options to save all objects by type to "copy" old repositories to new ones checking the parent-child relationship at at restore moment.

 I hope this can help somebody, thank you very much.

 Veronica