Question

Exporting Volumes to a new Server - Concerns?

Version 10 Laserfiche Installation and Upgrades

Updated April 20, 2018

asked on April 3, 2018

We are moving from Oracle to a SQL based Laserfiche server. If we export all the volumes from the Oracle server to the SQL server, what are the things I should be aware of?

I know I need to re-create access/security.

What about the entry IDs? If they change, then are there any tips for creating a cross-reference list of old IDs and new IDs? How can I recreate the audit history if its needed after moving to the new server?

Do we need to create a new Workflow server and database? Or can we hook up the existing server to the new SQL server without an issue?

What's the fastest way to export the volumes? We have 1 app server and 1 database/image server. I'd like to export the volumes back to the image server without the files being transferred around the network between the 2 servers and copy directly to the image server to speed it up.

If you can answer any of these questions, I appreciate what you are willing to provide. Thanks!

1 0

Answer

SELECTED ANSWER

replied on April 20, 2018

Exporting the volume to its existing location cuts the time in half! Then, its only building the XML files rather than copying files as well.

I tested it with a 160 GB, 120k doc volume and it took less than 4 hours vs my estimated 8.5 hours if I chose a new location to export to.

1 0

Replies

replied on April 4, 2018

You can reconfigure the Workflow server with the new monitored repository. If the repository name stays the same and the user specified in the connection profile has the same password, the change will be mostly transparent to Workflow. Obviously, since it's not the same repository, you shouldn't expect instances running before the change to complete correctly. It's best if you terminate those and shut down workflow before the move.

If the repository name or the username/password change in the move, you can put in redirects to handle the change while you update and republish the workflows.

1 0

replied on April 4, 2018 • Show version history

I have done this several times. Just make the move and test it thoroughly. Keep the old data in case you need to revert, but it is just a matter of updating the path to the new repository location. I have never had entryIDs change. I would backup your database before the move as well. Reach out to your VAR if you need a back-seat driver while you do the work.

You can have multiple locations where you keep the images, text files, etc.

One thing to consider is that if you have a lot of data, it will take time to back it up, move it and test it. You may be offline for several days. The more I think about this, you probably are going to want assistance from your VAR because it could be done several ways.

Good luck!

0 0

replied on April 4, 2018

Can you expand on this?

Are you saying I can build the new server and attach the existing repository or volumes?

Or, do I have to export the volumes and re-import them to the new server still AND the entry IDs will stay the same?

0 0

replied on April 5, 2018 • Show version history

I would go with what Miruna is recommending. That being said, I would find out for yourself (hands on) exactly how this is going to work. Setup both servers. Take one single volume from the old location and bring it into the new location. See what happens.

This would be a great way to easily setup the Workflow to take the old entryID and populate in a metadata field. You will want to do this BEFORE you import to the new location.

If you have linked docs, you will probably want to store in metadata what the linked doc entryID is as well. Is that why you were asking about entry IDs changing?

Start small. Once you see how it works, I think everything will become clear on what you need to do.

Again, depending on how much data you have, this could take days to do. One trick would be to lock all the security groups so they are read only. That way, no changes can be made to alter the entries.

Good topic!

0 0

replied on April 5, 2018

Thanks for the feedback! This is very helpful.

My concern about entry ID is that it seems pretty pivotal and don't know where ID is relied on so I can monitor possible issues. Linking is one concern. Audit history tracking. There are a few processes around here where specific documents are searched for by Entry ID in web access URLs or in a workflow.

0 0

replied on April 4, 2018

As far as audit history goes, you can't recreate it in the new repository. But you can archive the audit logs for the old repository and still query them by configuring a folder instead of a repository in Audit Trail.

0 0

View 2 previous replies

replied on April 4, 2018

Will the entry IDs change? If so, how can I connect the old history with the new docs?

0 0

replied on April 4, 2018

The entry IDs will most likely change in the new repository (since you're technically creating new entries in a new repository).

I'd probably add a metadata field in the current repo, default it to %(ID), make it read-only to all users but one and use that one user to set this field on all entries. You could do this through Workflow, but do it in batches of 500 entries or so at a time.

2 0

replied on April 5, 2018

@████████, could he export a volume as a briefcase and retain entryIDs? If not a volume, some other increment? There are not size restrictions on briefcases, right?

Just a thought.

0 0

replied on April 5, 2018

No, neither a volume nor a briefcase import will preserve the entry IDs.

2 0

replied on April 5, 2018

@████████

Is there a recommended maximum size or entry count or some other limit for safely exporting a volume? We currently have 1 large volume of about 830k docs, 4.5M pages and 420 GB of storage.

Do I need to slice this up to smaller volumes? If so, what guidance can you give on size?

1 0

replied on April 5, 2018

My next questions are about how to speed up the volume export process. Where are the bottle necks? How does the export process work at a low level so I can figure out what components are involved and how to optimize those.

Any tips?

0 0

SELECTED ANSWER

replied on April 20, 2018

Exporting the volume to its existing location cuts the time in half! Then, its only building the XML files rather than copying files as well.

I tested it with a 160 GB, 120k doc volume and it took less than 4 hours vs my estimated 8.5 hours if I chose a new location to export to.

1 0

You are not allowed to follow up in this post.

Question

Question

Exporting Volumes to a new Server - Concerns?

Answer

Replies

Sign in to reply to this post.