Question

Migrating documents from one volume to another

Laserfiche Version 9

Updated February 21, 2020

asked on March 26, 2015

When migrating entries to another volume in the repository it goes through the entire process. I checked to see if there were any files left through the admin console however when I checked the physical location of where the older volume was stored there were still documents within this folder. I was wondering if it would be fine to delete this folder given that Laserfiche cannot detect the files anymore. I was wondering if this is normal or not?

0 0

Replies

replied on March 26, 2015

You may want to run the volume consistency checker to find out what those files are. Perhaps they are associated with files that may have been in the recycle bin. Or maybe they are linked to files that the user didn't have rights to so when they migrated documents from one volume to another, not all documents were actually migrated.

In general though, migrating documents from one volume to another shouldn't leave them in the original volume. Perhaps there's just a slight delay in the server cleaning up those files. See if the files are still present after 30 minutes or so.

0 0

replied on March 26, 2015

Alex,

One set of volumes did not transfer over completely. I will run the volume consistency checker. Is it suggested to run this on the volume it was transferred to or the volume that it was transferred from?

0 0

replied on March 26, 2015

Please explain in more detail what's being done and what's being seen. Are they trying to migrate every document from one volume to another? If so, what's the process being done? Are they just doing a search for all documents in one volume, then selecting all those documents and choosing to migrate them to a new volume?

Also, when you say one set of volumes did not transfer over completely, do you mean that the process was interrupted somehow so out of all the documents that were selected to be migrated from one volume to another, only some got migrated while the rest still remain in the original volume? Or are you saying that the Laserfiche Server indicates that all documents should be in the new volume, but that's not the case when looking at the physical files in the volume location?

If you can provide the exact context of what's being done and what's being seen, then a more detailed suggestion can be provided.

0 0

replied on March 26, 2015

The initial problem for the customer was that they had multiple physical volumes that needed to be migrated to logical volumes. The reason for this is that they would receive a message stating the volume was out of space. In order to migrate from the physical volumes to the logical volumes I first created the logical volume. I then went into the Laserfiche client and searched based on the physical volume and highlighted all documents then went to task and migrate entries. I migrated the entries to the logical volumes. There were no interruptions that I know of and there had been nothing recorded in the event viewer. Within the admin console it had read that there were no pages or data for the volume that was migrated from.

I did do a search within the volume and a find pages of any document containing an image with exactly 0 kb. There were no results returned. I will run the volume consistency checker to make sure I didn't miss anything. I will update the results once this has been completed.

0 0

replied on June 24, 2016

I can see that the described situation happens within Laserfiche on some occasions, I cant figure out when.

Some documents are migrated properly and I can see them on the destination volume, but some of the tiff files from some of the migrated documents remain duplicated on both, the destination and the original physical path.

Meaning that during the migration process Laserfiche succesfully migrated the documents to the destination Volume but failed to deleted the files from the original physical path.

0 0

View 2 previous replies

replied on August 11, 2018

I have this problem. How did you clean it up?

0 0

replied on August 13, 2018

Note that the Laserfiche Server cleans up old volume content in an asynchronous manner to avoid heavy load on the system at any one time. This includes content that has been migrated to a different volume.

0 0

replied on August 13, 2018

@████████, It seems to clean up pretty slowly.

1. Is there a way to speed it up or call it manually?

2. Why doesn't the Laserfiche server MOVE the files to the new volume instead of copying then later delete?

0 0

replied on August 13, 2018 • Show version history

Hi Kenny,

I can't say for sure on the 'why', although I expect it's to safeguard in case there are errors or interruptions during the process.

The ability to configure the maintenance window was added to the Laserfiche 10.3 windows administration console. By default it only runs from 1-3am every day, so it could take a while to get through everything following a large volume migration.

If you aren't on 10.3, I found this from a related support case (although I wouldn't personally recommend actually setting it for 'all day'):

Create DWORD registry values named MaintenanceWindowStart and MaintenanceWindowEnd under HKEY_LOCAL_MACHINE\SOFTWARE\Laserfiche\Engine\8.0\Repositories\[repositoryname]. Set them to 0 and 86400 and restart the LF server service. This tells LFS to make the maintenance window all day, instead of the default of 1am-3am.

4 0

replied on August 13, 2018

Justin, this is it! Changing the maintenance window (we are on 10.3.1) to now or before kicks off the process to clean up the files that were migrated and it was going pretty quickly at first.

Not sure how to "pin" this sub-thread, but exposing the maintenance schedule and increasing it beyond the default 2 hours is a big help for an immediate need to clear the old data out of a drive that's almost full.

Thanks!

1 0

replied on February 21, 2020

Thank you! I had the same questions/fears. Also, this default maintenance window caused a tremendous problem when I had to migrate for an emergency freeing up of storage. Until finding this post, I hadn't figured out whether to blame our new virtual servers or our new RIO software (We had United before, and never had this problem.). [Of course, the new virtual server is not off the hook, either, due to communications lag between the repository server and the database server; but that's another post.] Thank you, again.

0 0

You are not allowed to follow up in this post.

Question

Question

Migrating documents from one volume to another

Replies

Sign in to reply to this post.