The document was migrated from one volume to another and is accessible in the repository, i.e. users can open the document and view its metadata, but none of the images are visible. See screenshots. Archive2012 volume doesn't have any documents. They may have been moved to another volume because none of tiffs were deleted from server. When I search by the tiff names in other volumes, the tiffs in results don't match with the metadata so those are tiffs for other documents. So used audit database to see migrate entry event. Wondering if there is a way to know what new tiff path or name is.

So under G:\ARCHIVE2012, there are no files or folders there? Was the repository moved from one server to another, but perhaps the volume files didn't get moved over? Was the ARCHIVE2012 volume previously set to a different path and then recently moved to G:\ARCHIVE2012, but perhaps the volume files didn't get moved over?

From your screenshots, Laserfiche is expecting the pages to be located in G:\ARCHIVE2012\00\00\08\00000887.TIF and G:\ARCHIVE2012\00\00\08\00000888.TIF respectively

Repository was not moved. 

Volume was not set to different path. 

Documents were migrated from default volume to Archive 2012 and then probably from archive 2012 to Archive2013. But I can not be certain about 2nd migration because I can't find tiffs in default or archive2013 volume. Also Archive2013 has about 3000 docs which are visible properly with images.

Yes no documents are available on that path. Also 00000887.TIF in other voumes have different pages. No matching page to document. Because new tiff name is created when it's moved to different volume.

When were the documents to have been migrated from the DEFAULT volume to ARCHIVE2012? Was there confirmation that this took place successfully? At this point, if you can't locate the corresponding files, then you may need to restore the database and volumes from backup. Since Laserfiche is reporting that the documents are still part of the ARCHIVE2012 volume, you can try just restoring that single volume first, but it's unclear what inconsistencies there may be when doing so. That's why a restoration of the database and volumes from the same point in time may be needed.

If you need further assistance with this process, please contact your Laserfiche reseller.

thanks. Infrastructure doesn't have backup of that folder. How can we restore volume? They have backup of drive having original default volume but not of G drive. 

What database are you referring to? Do you mean sql database or some other database?

So there are no backups of the ARCHIVE2012 volume (or any volume that had been on the G drive)? You'll need to then restore a backup of the DEFAULT volume from before those documents were migrated from DEFAULT to ARCHIVE2012. You'd also need to restore the Laserfiche repository database from the same time that the backup of the DEFAULT volume was taken. See if you can load that to an isolated Laserfiche Server system in your Rio environment. Locate those documents from there and export them so that you can import them back into the production repository.

Thanks. I will look into this approach.

So there is no way to figure out old and new tiff names by searching audit data, correct?

The file name of the TIFF is based off of the store ID of that particular page in that particular volume. That information is not audited when migrating documents from one volume to another.

Thanks.

Is original path of tiff saved anywhere in master database? The database having volume and toc and doc tables. If we can find the original path, we can find tiffs from backup. I see img_etag column but not sure how to use it.