Well, crap:
"Users can't clone a file or a LUN that exists only in a Snapshot. The file or LUN must exist in the active file system."
So much for 'recovery'... this is great for deployment, however. Wonder if there is a caveat that the file must be cloned to the same flexvol. I _know_ it will mean same aggregate (which kills our deployment from templates already).
Bummer...
-----Original Message----- From: Matt Hallmark [mailto:matt@cosmictoaster.com] Sent: Thursday, January 15, 2009 11:15 AM To: Darren Sykes Cc: Glenn Walker; Fox, Adam; Kumar, Rahul; Sto Rage(c); toasters@mathworks.com Subject: Re: SMVI - Limitations?
http://blog.scottlowe.org/2008/12/03/2031-enhancements-to-netapp-cloning -technology/
Looks like it's single-file flex clone, w/o having to have a snap behind the clone.
I'd thought that I'd seen mention of it on NetApp's Storage Nuts 'n Bolts Blog as well, but I didn't find it again in a few minutes of searching.
We'll see once 7.3.1 is out, which is "Real Soon Now" according to my sources. :)
Matt
On Jan 15, 2009, at 12:50 AM, Darren Sykes wrote:
I thought individual file cloning was not a feature which Netapp had publically announced (so tried to avoid mentioning it!). Maybe I'm behind the times....
On 15/01/2009 05:27, "Glenn Walker" ggwalker@mindspring.com wrote:
Single File Snap Restore (especially with ASIS) is a bit slow \painful. 7.3.1 code (maybe even 7.3) is supposed to make File Cloning a reality, much like you can do with LUNs today - this should help a great deal.
Because of the slow SFSR, we've been using CP from the ESX CLI to get the data back out of snapshots - unfortunately, this means that the VMDKs are thick again and will have to be deduped during the next run.
I should probably preface the above with the fact we're running VMWare storage over NFS. If you were using LUNs, you'd be using the LUN Clone\Split functionality to recover data which is blazing fast - but it also means you're recovering an entire LUN and everything within it (similar to Snap Restore at the volume level)... NFS allows us to recover single VMDKs, but we're suffering a bit due to the newness of the solution set.
Looking forward to the improved functionality - there's no way I'd ever consider ESX over anything other than NFS!
Glenn
-----Original Message----- From: owner-toasters@mathworks.com
[mailto:owner-toasters@mathworks.com
] On Behalf Of Fox, Adam Sent: Wednesday, January 14, 2009 12:37 PM To: Kumar, Rahul; Sto Rage(c) ; toasters@mathworks.com; Darren.Sykes@csr.com Subject: RE: SMVI - Limitations?
I have to admit, I am not an SMVI expert, but I do know a thing or three about WAFL so I was speaking specifically about how snapshots and SnapRestore work at the ONTAP/WAFL level.
As far as dedup (SIS), I'm not sure if I understand how/if it would "interfere" with a SnapRestore. In the case of a volume-level SnapRestore, the volume reverts back to the way it looked at the time of the snapshot used for the SnapRestore, and dedup would be no different there since the block pointers as well as the fingerprint file would be a part of the SnapRestore. I've actually never tried to figure out how it would work with a single- file SnapRestore. The good news is that with the release of the 7.3 simulator, which supports dedup, anyone can try it in their lab without touching their production stuff (on a smaller scale, of course). At most, you might have to re-run a full scan, but I'm honestly not sure.
-- Adam Fox Systems Engineer adamfox@netapp.com
-----Original Message----- From: Kumar, Rahul [mailto:kumarrahul@siemens.com] Sent: Wednesday, January 14, 2009 12:09 PM To: Fox, Adam; Sto Rage(c) ; toasters@mathworks.com; Darren.Sykes@csr.com Subject: RE: SMVI - Limitations?
Adam
So in theory, the snaprestore via smvi does actually do an individual file restores (talking about the a single vm restore) though there may be 100 of vms on the volume.
So that does mean that we need to dedicate/separate volumes according to the usage etc. Also does SIS interfere when vm snaprestores are done by any chance ?
Thanks for making the issue clear.. I am not in grip of the scenario and possible workarounds or new processes to b e followed
Rahul
-----Original Message----- From: Fox, Adam [mailto:Adam.Fox@netapp.com] Sent: Wednesday, January 14, 2009 9:51 PM To: Kumar, Rahul; Sto Rage(c) ; toasters@mathworks.com; Darren.Sykes@csr.com Subject: RE: SMVI - Limitations?
WAFL Snapshots are always at the volume level. If you use the snap restore software on the controller, you can restore either the entire volume or an individual file level.
Hope this helps.
-- Adam Fox Systems Engineer adamfox@netapp.com
-----Original Message----- From: Kumar, Rahul [mailto:kumarrahul@siemens.com] Sent: Wednesday, January 14, 2009 5:07 AM To: Sto Rage(c) ; toasters@mathworks.com; Darren.Sykes@csr.com; Fox, Adam Subject: RE: SMVI - Limitations?
Hi Toasters
A general scene and a question related to it.
We have over 5TB of NFS datastore spread across various qtrees.
We were evaluating SMVI and came to know that it also requires snaprestore to restore the VM's
Now my question is that if e.g there was a qtree with say 50 vms on it and we'd like to snapshot only a few of them. Will this work ?
When a snap is created on the filer it will capture all the VM's thus eating up valuable disk space from the snapreserve as time goes by.
Next when we do a restore of the individual machine, it does a snap restore, however I am not sure if this only restores the individual machine or the entire stuff
Any insight/help into this will be helpful
Thanks Rahul
-----Original Message----- From: owner-toasters@mathworks.com
[mailto:owner-toasters@mathworks.com
] On Behalf Of Sto Rage(c) Sent: Saturday, January 10, 2009 4:52 AM To: toasters@mathworks.com Subject: Re: SMVI - Limitations?
On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes Darren.Sykes@csr.com wrote:
You can tell SMVI (v1.1) not to perform OS level disk quiecing on
those
machines if that's any use to you? You'll then get a completely transparent Netapp level snapshot and
won't
interfere with the VM itself.
Darren
It is SMVI v1.01 BTW, not 1.1 Not sure I understand this correctly, but if you are bypassing OS disk quiesce (VMWare snapshot) and doing transparent NetApp level snapshot, then why do you even need SMVI installed? Can't we just do the regular filer level snap schedule? We just upgraded to 1.01 and noticed the checkbox and were wondering about its potential use. Any ideas?
thanks -G
To report this email as spam click
https://www.mailcontrol.com/sr/ug0PLQWh+NDTndxI!oX7Us7PAc+Gwoki+tHufSOOi ve2d!w
jVlrCgJRg5dmIWyzIG+CHg+eM4kfwq3xXRfv08Q== .
Please read my responses inline below.
On Jan 15, 2009, at 3:39 PM, Glenn Walker wrote:
Well, crap:
"Users can't clone a file or a LUN that exists only in a Snapshot. The file or LUN must exist in the active file system."
So much for 'recovery'... this is great for deployment, however. Wonder if there is a caveat that the file must be cloned to the same flexvol. I _know_ it will mean same aggregate (which kills our deployment from templates already).
You are correct--from everything I have seen, you will have to clone to the same FlexVol.