Move stuck at step 4 of 5

[Johnha1981]

Hi, 

I know this has been asked before but I don'tseem to have the answer still. I have moved a users vault and the move is stuck at waiting for destination backup. We do not back up the ev servers therfore this will never work. I have tried changing the ini file and restarting the services and this has ot affected it. Is there a way I can delete the move? 

Thanks 

[daveoflave]

Hi Johnha1981,

    Well updating the EVMoveArchiveTask.exe.config should prevent us from trying step 4, though I'm not sure how well it works if it's already on step 4 when the change happens.

    To me, the easiest thing would be to set IgnoreArchiveBitTriggerFiles on the destination partition roots, and set/clear backup mode.  That would force EV to think it was all backed up anyway, and allow the Move to progress.  Meaning, the destination Ev server has to confirm that all savesets moved there have cleared the Watchfile table and are secure.  Using those trigger files should achieve that, independent of actually doing backups.

     But, if you don't want to mess with all that; you could delete the Move.  The console for MoveArchive should have a delete option, but also you could delete the row from the source Directory DB > Subtask table.  It clearly names each row for each MoveArchive subtask, so it's easy to see which is which.  However, I'd only do this if you're 100% sure the report for that MoveArchive subtask had no errors during step 1, and (I know you're talking about step 4) but be 100% sure it successfully completed steps 2 & 3.  Hope this helps!

[Johnha1981]

HI, 

Thanks for the info. is it possible you can direct me to how to do either of the below solutuions?

"

  To me, the easiest thing would be to set IgnoreArchiveBitTriggerFiles on the destination partition roots, and set/clear backup mode.  That would force EV to think it was all backed up anyway, and allow the Move to progress.  Meaning, the destination Ev server has to confirm that all savesets moved there have cleared the Watchfile table and are secure.  Using those trigger files should achieve that, independent of actually doing backups.

     But, if you don't want to mess with all that; you could delete the Move.  The console for MoveArchive should have a delete option, but also you could delete the row from the source Directory DB > Subtask table.  It clearly names each row for each MoveArchive subtask, so it's easy to see which is which.  However, I'd only do this if you're 100% sure the report for that MoveArchive subtask had no errors during step 1, and (I know you're talking about step 4) but be 100% sure it successfully completed steps 2 & 3.  Hope this helps!"

[sandrine_goetha]

Hi Johanna,

I ran in the exactly same problem on Tuesday , I just put ( via the console) the destination store in Back-up mode and few minutes later removed it ( I know contra intuitive when you don't have backups) and tada.... 30 minutes later the task was completed.

I hope this helps.

[Johnha1981]

Hi, 

This sounds like it may work for me. If I put the store into backup mode what is the affect on the store? Does it need to be done out of hours or will users have access to their archive as usual? 

Thanks 

[GertjanA]

setting backup is only preventing items being added to the store. Searching and retrieving are not affected.

[daveoflave]

Hi Johnha1981,

   Take a look at this:  https://www.veritas.com/support/en_US/article.000101410

Basically setting/clearing backup mode means you're putting our EV vault store Database into read-only mode, then out of it and back into normal mode.   When we see that our DB has gone back into normal mode, we kick off a "storagefilewatch" (SFW) scan. That's one of our processes that ensures the savesets we've archived are "secured" or backed up.

   That's the whole point of this - you're setting/clearing backup mode to force SFW to initiate a scan.  This is what would "secure" the items that were moved in your Move Archive (MA) subtask. 

    The mention of the trigger file is discussed in the article above.  You place a trigger file in the root of each partition that you want to secure, and in the properties of each of those partitions > backup tab, select the Trigger file radio button.

     Worth mentioning that restarting storage has the same effect of starting an SFW scan as setting/clearing backup mode on your vault stores.  So if you have fresh trigger files, set your partitions to use trigger files, and then either restart storage or set/clear backup mode, an SFW scan will begin, and mark the files for those partitions as "secured," allowing your MA subtask to pass step 4.

Alternatively, the method of deleting the subtask might be a little more dicey.  So let's stick with this, as it's a supported method.  Hope this helps!

[Johnha1981]

I set the destination server into backup mode and then back out again. I've waited a little while but there is no change in the move job. Looks like it may not have worked. 

[daveoflave]

Hi Johnha1981,

  A couple things to consider:

-Setting/clearing backup mode is definitely a necessary part of this, but not the only one.  The partitions within that vault store have settings to either use a trigger file or archive attributes to mark items secured.  If you set the partitions to use trigger files, there has to be a fresh trigger file in the root of each partition when backup mode is clear.  Or, if the partition is set to use archive attributes, then your backup software must truly remove the "A" attribute from each saveset in the partition when it backs it up.  When one of those requirements is met (with the matching setting chosen on the partitions), EV will "secure" those items with SFW, the next time an SFW scan occurs.  It's immediate if you clear backup mode or restart the storage service.

-The other thing to consider is how often the Move Archive (MA) subtask actually polls to check.  By default it's 30 minutes; but this can be changed using evmovearchivetask.exe.config, and evtaskguardian.exe.config, but that's a whole other story.  The report for that MA subtask will tell you the last time it tried, and if you haven't changed any default settings, it will try again 30 minutes from that.

So considering all of that:  Were the partitions set to use trigger files? Were there fresh trigger files in the partition roots?  Since you cleared backup mode, did the MA subtask actually check to see if the items were secured again?

[sandrine_goetha]

Hi Johanna,

If this didn't help you could also change the configuration file as to the tech note 9416

https://www.veritas.com/support/en_US/article.000009416

I really hope you manage