Forum Discussion

Simon_B_'s avatar
Simon_B_
Level 6
14 years ago
Solved

roll back Backup Exec partition migration

We currently have an issue where an EV partition was activated for migration to secondary storage using the Backup Exec migrator. Using this migrator the journal vault store data (~500GB) was written on tapes.

After upgrading to EV 10 the indexes need to be updated. Needless to say that this is a very time consuming task as every single collection has to be restored from tape (tape library has to load the appropiate tape, seek the position, read the ~10MB, put the tape back in the slot etc). What is much worse: The index upgrade does not go through without errors - there seem to be some items which cannot be reindexed. 

We are currently thinking about ways to undo this migration so that the files (at least temporarily) stay on the primary storage which is several magnitues faster for troubleshooting and reindexing.

Our current approach is to perform a PST export of the archive, which subsequently leads to all the ARCHCAB files being staged on the primary storage. However the files again are restored one by one (one Backup Exec restore job for every migrated cab file) and so the process would take several weeks.

Questions:

  • Is there a way to completely roll back the migration?
  • Is there a way to ensure the staged ARCHCAB files are not deleted after 7 days (which I believe is the normal period for ARCHCAB files which were written back to the primary storage for retrieve purposes)
  • Is there a way to restore all data from Backup Exec in a single restore job (which would allow sequential reading from tape which is much faster)?
  • What if we'd simply manually restore all ARCHCAB files to the appropiate locations on the primary storage - would EV recognize this and use this as data source?

Thanks!

Enterprise Vault
Information Governance
Troubleshooting
Upgrade
  • Jeff_Shotton's avatar
    Jeff_Shotton
    14 years ago

    The process for accessing a dvs file goes dvs > archdvs > cab > archcab > access migrator (offline storage)

    When the data is retrieved from offline storage the whole process starts again, beginning with dvs and going through to archcab, which is then unpacked. Finally on the third try the archdvs is found.

    Because this is always the process followed, if the cab file was to be restored, then the migrator essentially would never be used for the recall process, so to back out you need to restore all cabs and then stop the migrator 'migrating'. The easy way to do this is to set the migrator to only take effect at 99 years. The more involved way then involves changing the collections records and removing the migrator via SQL.

    You might want to check out http://www.symantec.com/docs/DOC5211, page 958 for the partitionrecovery utility, which was written to back out of all this....probably because everyone going to EV10 and using the migrator is going to hit this issue.

    For NBU, reference page 133

    http://www.symantec.com/docs/DOC5179

    Regards,

    Jeff

     

7 Replies

  • JesusWept3's avatar
    JesusWept3
    Level 6
    14 years ago

    What controls the deletion of ARCHCAB is the collections process, you'd have to set the start time and end time to be the exact same minute and second so that no archcabs are deleted

    However the last time i looked at the code, i believe is the ARCH files will be ignored if they're older than a certain amount of days (i think it might be accessed date or create date, can't remember which), so it simply ignores the ARCHCAB and then goes to retrieve the items from tertiary storage (i.e. tape)

    I'm not entirely sure if theres any way to roll back from a migration.
    The only thing i can think of is, is there anyway to manipulate BE to think the backup set is on Disk and not tape and then move all the item from tape to a disk, then set the library to be that disk instead of tape, but i dont even know if thats possible/supported etc

  • Simon_B_'s avatar
    Simon_B_
    Level 6
    14 years ago

    Hi JW,

    I thought about somehow getting BE to read from Disk too - not sure how this can be achieved though.

    Nevertheless - Thanks for your reply!

  • AndrewB's avatar
    AndrewB
    Moderator
    14 years ago

    please keep us posted on what you end up doing for this situation. i'm very curious to know. Thanks!

  • Prone2Typos's avatar
    Prone2Typos
    Moderator
    14 years ago

    I know that we have proposed recovering all secondary stored items from an NBU migrator back to disk. We took some time to figure out how it would happen and then proved we could do it.

     

    I think that we look for DVS>CAB>ArchDVS>ArchCab>Secondary storage CAB in that order. That said... if all cabs were brough back that would be all that would be technically needed...although I think it is more approproiate to clean the DB properly too. I never heard about ignoring ArchFiles after a certian age...but I suppose that could be.

     

    I think it can totally be done...but I would not reccomend trying to do it yourself if you dont know what you are doing. If you would like to talk to someone about the feasibility and costs asociated with having a third party (shameless plug...sorry) like us see what we can do ... let me know and I will get someone in contact with you.

     

    Regards

     

     

  • Simon_B_'s avatar
    Simon_B_
    Level 6
    14 years ago

    Thanks all for your replies. It was decided that the index will stay in 32Bit for now and a new Vault Store with Partitions (w/o migration enabled) will be used from now on for newly archived items.

  • Jeff_Shotton's avatar
    Jeff_Shotton
    Level 6
    14 years ago

    The process for accessing a dvs file goes dvs > archdvs > cab > archcab > access migrator (offline storage)

    When the data is retrieved from offline storage the whole process starts again, beginning with dvs and going through to archcab, which is then unpacked. Finally on the third try the archdvs is found.

    Because this is always the process followed, if the cab file was to be restored, then the migrator essentially would never be used for the recall process, so to back out you need to restore all cabs and then stop the migrator 'migrating'. The easy way to do this is to set the migrator to only take effect at 99 years. The more involved way then involves changing the collections records and removing the migrator via SQL.

    You might want to check out http://www.symantec.com/docs/DOC5211, page 958 for the partitionrecovery utility, which was written to back out of all this....probably because everyone going to EV10 and using the migrator is going to hit this issue.

    For NBU, reference page 133

    http://www.symantec.com/docs/DOC5179

    Regards,

    Jeff

     

  • Simon_B_'s avatar
    Simon_B_
    Level 6
    14 years ago

    Thanks for this hint Jeff - wasn't aware of this utility. Even though we will not be using it in this case it might prove itself valuable in future. 

    Therefore I'll mark your post as solution.