So several issues came to light through this excersize.
Our last vol move of a 100TB volume, on a tight aggregate, appeared to work; the volume was copied to a new aggregate and transfered. No errors were reported.
However, immediately on Monday after cutover (auto-triggered), users started reporting their files had reverted to an earlier version; The date was the date of the original volume move start operation.
There are several issues with troubleshooting this issue:
- This is a restricted site, so no auto-supports go to NetApp
- My server which triggered weekly auto-supports to email, had been turned-down (new one not up yet)
- Log limit on the array's mroot removed original logs which applied to the trigger operation
- Do not have a Syslog server to send "ALL" logs to; not sure that can be done either
- Volume Move does not add to the "volume recovery-queue" so I cannot undelete the original source
I ran a test on a small volume, populated with 0 byte files in nested directories. I watched the snapshots and updates "volume move" made and they worked fine. The only difference between my troublesome moves and the test, was that the trouble was on volumes with dedicated aggregates, with minimal free space. (Don't ask why...) The same with the other two large volumes which had problems.
All of the smaller volumes which I had moved appear to have worked okay.
So my conclusion is that this happened because of the lack of free space, for one reason or another, but of course I can't prove it.
I would like to request the following from NetApp:
- Please add an option to volume move to keep the original volume around if there is an issue (I forgot, in my case my backup was to a smaller model array, which has a smaller volume size.)
If anyone knows how to setup a network syslog type server which can keep all of the Ontap logs, please let me know.
In the final analysis, I had to ask that the case be closed, because I could not provide logs proving or disproving user allegations. I believe that volume move will work correctly, so long as there is enough space to do what it needs. Of course, this is all conjecture on my part, and I apologize if it is wrong. In the meantime, I've had to revert to SM, which appears to be a little slower than vol move.
TasP