2010-03-15 07:52 AM
It would be nice to have the Snapmirror/Snapvault update depending on the policy.
So parameter NTAP_SNAPMIRROR_UPDATE and NTAP_SNAPVAULT_UPDATE should be extended to allow definition based on policies, so for example:
NTAP_SNAPVAULT_UPDATE=Y (Snapvault update is run on all policies)
NTAP_SNAPVAULT_UPDATE=N (never do a snapvault update on any policy)
NTAP_SNAPVAULT_UPDATE=daily (Snapvault update is run on policy "daily" only, not on other policies)
NTAP_SNAPVAULT_UPDATE=daily,weekly (Snapvault update is run on policy "daily" and "weekly" only, not on other policies)
same for Snapmirror
For example my customer would like to snapvault update only on daily and weekly, but not on hourly. This would require two different configs. With the new approach everything could be defined in one config.
2010-03-29 03:11 PM
Thanks for your work on this (and to your colleagues too). I'd like to request the ability to execute snapvault restores for qtrees via snapcreator, as one of the "--action restore" options.
Although we can obviously copy individual files out of the .snapshot directory being able to manage the baseline and incremental qtree restores via snapcreator would be helpful.
A couple reasons this would help us:
-Accessing the snapvault target qtree via NAS protocols may be challenging due to network/security restrictions.
-Incorporating snapvault qtree restores into snapcreator extends the snapcreator functionality umbrella, which is helpful if we have to operationalize SnapCreator for admins that don't have a full understanding of the underlying NetApp technology.
2010-03-30 03:02 AM
This is a great idea but tricky, lets get into details. So if I understand you want to be able to within a secondary snapshot select individual qtrees and only restore them back to primary?
We are definately going to add ability to do a snapvault restore which will bring the secondary snapshot back to primary but from there you would need to grab the individual qtrees you need or do a snapshot restore. Would this be enough, the theory is then you would have access to the snapshot since they are on primary again.
If you indeed need to do qtree level restores then do you have any ideas on how it should work. I am thinking we need to do OS based commands for example (unfortunately we cant manipulate qtrees from OnTap):
1. snapvault restore (snapshot now recovered on primary)
2. ls -l /mnt/.snapshot/<snapshot>
3. Choose qtree to recover?
4. cp /mnt/.snapshot/<snapshot>/<qtree> /mnt/<qtree>
Is this what you are wanting? This is just an example, I know the cp command needs some help with proper arguments ;D
Let us know we can certainly improve this greatly for 3.3 with your help
2010-03-30 10:06 AM
I'm specifically talking about step 1 that you mention. The way you explain is a little confusing -- based on what I read here:
and what I tested yesterday, a snapvault restore does restore the whole qtree -- that's the only kind of snapvault restore that exists (if you are snapvaulting qtrees). I may be missing something...
So, let's say someone wanted to use SnapCreator to do a qtree restore. They would first need to know:
-The primary qtree to restore and the secondary qtree it is being restored from. These would need to be the absolute paths on both the primary and secondary arrays
-The snapshot on the secondary array to restore from. The available snapshots can easily be seen with the --action snaplist option.
As part of the SnapCreator --action restore process, it could just have a section for snapvault qtree restores where it queries the user for the snapshot and qtree. SnapCreator could list out the volumes it knows to act on based on the config file and then the qtrees involved in a snapvault relationship.
I can envision the tool asking the user to then provide the primary qtree restore target (with providing an alternate as an option), the secondary qtree source, and the name of the snapshot on the secondary. SnapCreator could then attempt an incremental restore and if that fails initiate a baseline restore.
Then the restore runs. At this point it might be helpful if there was a 'snapvault status' option for SnapCreator so the restore progress could be monitored (nice to have but not mandatory). Once completed the user would then have to restart the snapvault relationship outside of SnapCreator, much like the requirement for initiating the relationship before SnapCreator took over the snapvault schedule initially.
Does this make sense? Thanks!
2010-03-30 04:22 PM
Thanks for the details...yeah I was on another planet so disregard my comments but I wanted you to explain how you thought the process should* work. I will talk about this with the team but just so I have the steps right:
1. prompt for secondary restore
2. select secondary snapshot
3. select secondary qtree (restore source)
4. Select primary qtree (restore destination)
5. start snapvault restore
6. Provide some status
2010-03-30 04:40 PM
This is perfect. It doesn't necessarily have to work exactly this way but I just thought it might make sense like this.
If you guys decide to add this functionality I'm sure you'll tweak it out appropriately.
2010-04-01 09:36 AM
How about this? Does this meet your requirement (btw this isnt a mock but actual code). We felt it was absolutely critical to get snapvault restore into 3.2...I am hopeful that will happen, need to do some more debugging and testing, but it looks good
2010-04-02 10:23 AM
Sweet man, you nailed it! This is exactly what I was thinking.
The tool just walks you through each step and tells you exactly what's happening. The only thing I might add (and this is minor) is a warning before the qtree restore begins that suggests unmounting the qtree if it an NFS or CIFS share itself lest we encounter a stale file handle. Beyond that this would make me very happy!