Forum Discussion

Surfnsnow's avatar
Surfnsnow
Level 1
9 years ago

Migrating away from Enterprise Vault 9.0 to CLoud with Error

I'm working on migrating the data to cloud and the migration tool has been logging errors in finding some archive files in certain mailbox partition folders during migration task. I don't see the folders in the Enterprise Vault Stores location on the vault server but I have a concern that these folders existed and got moved or deleted for some reason because the migration tool initially gathered/collected these folders as locations of archive data. Can you please help to find an explanation behind these missing folders.

 

Could not find file '\\INGDEVAULT\I$\Enterprise Vault Stores\Mailbox Ptn12\2015\03-01\5\11F\511F80F8751F3B70D5370899A8A33F71.DVS'. ---> System.IO.FileNotFoundException: Could not find file '\\INGDEVAULT\I$\Enterprise Vault Stores\Mailbox Ptn12\2015\03-01\5\11F\511F80F8751F3B70D5370899A8A33F71.DVS'.

Thanks in Advance for any assistance!

3 Replies

  • daveoflave's avatar
    daveoflave
    Level 4
    9 years ago

    Hi Surfnsnow,

       You've actually done the most important step - checking if the data's actually there.  Since you know it's not, we can assert that the Vault Store database still thinks it's there and has records for it.

       What happened to the data is an age-old question that has been asked before.  If the entries still exist in the EV databases (specifically the Saveset table in the VS DB), EV wasn't aware of or responsible for its deletion.

    These types of scenarios crop up most when you're using NTFS for Storage.  Since EV is a Windows based app, anyone who can access the storage data could delete it.  Using devices like Centera or other WORM storage can prevent this.

        So at this point you have 2 paths:

    1) Try to recover the missing data from backups

    2) Use EVSVR to lop off the database entries for the stuff that isnt' in storage anymore.  It'd likely be EVSVR > Repair > DatabaseReferences

    Not very heart warming, I know - but you might have luck searching your backups!

    • GertjanA's avatar
      GertjanA
      Moderator
      9 years ago

      Hello,

      When did you run your gathering? As the gathering (using TransVault?) found the data in SQL, it might very well be that the data then also was there. Could it be that items expired, and no new gathering was run? If using TV, there should be information in the logfile in regards to which archive it is. Having that, you might want to try to export the archive (using EV) to PST, and see if everything gets exported. But, if the data is truly not there, use EVSVR (worik with support if they will, as 9 is out of support as far as I know) to try to fix SQL, rerun gathering for the archives having this issue, try migrate again.

      Greetz, GJ

      • daveoflave's avatar
        daveoflave
        Level 4
        9 years ago

        GertjanA makes 2 great points:

        -EV 9 is indeed long outside support life.

        -If you do run expiry, that's definitely a good idea to look into.  You could search your current saveset table in your Vault Store DB for the items in question to rule out or confirm what he's offering as a possibility.  Run this against the vault store DB in question:

        Select * from saveset where idtransaction = '511F80F8-751F-3B70-D537-0899A8A33F71'

        All I did was grab the file name of the dvs you showed in your original post and add some hyphens to make it talk nicely with the database. 

        If you get a row back, it would concrete the idea that data is simply missing.  If you get no rows back, then you could re-run your data gathering from your migration tool like GertjanA mentioned. 

        In the end, you either have stale data gathered that doesn't represent what is truly in the databases, or you have missing data, which would be an EVSVR operation like we both mentioned.