marketing continuously claim that snap restore is instantaneous. yet I have yet to succeeded doing so. "snap restore" of files to a location quite a while and is "copying the files" nothing close to instantaneous. i would be happy to understand what i am missing. the following is a example of a virtual disk that was restored, it took quite a while to "restore"=copy this 80gb file.
snap restore -t file -s nightly.0 /vol/vmsata/vmfs1/lms-client/lms-clinet-flat.vmdk
Avi
What else is the system doing when you're performing the snap restore? How busy are the disks (I personally disagree w/VMs on SATA disks), etc? All it's doing is changing where the pointers are aimed so it /should/ be quick. I honestly dont think *I* have ever told anyone they're instantaneous just "near instantaneous"...
What is "quite a while" too? Did you perform that restore command via an SSH call to the system with "time" before it to see how long the overall command execution took?
Feb 4, 2013 03:28:39 AM, avi@jct.ac.il wrote:
marketing continuously claim that snap restore is instantaneous.yet I have yet to succeeded doing so. "snap restore" of files to a location quite a while and is "copying the files" nothing close to instantaneous. i would be happy to understand what i am missing. the following is a example of a virtual disk that was restored, it took quite a while to "restore"=copy this 80gb file.
snap restore -t file -s nightly.0 /vol/vmsata/vmfs1/lms-client/lms-clinet-flat.vmdk Avi--
A volume level snap restore is near instantaneous as it simply has to change the active bit map table. However, what you are doing is a single file snap restore. There is more work involved in determining what blocks are used by that file. So, what NetApp does is basically a clone then split operation. This gives you access to the file almost instantaneously while it splits off the clone. They can't simply modify the bit map table as they do in volume level snap restores because you may otherwise lose the ability to restore later volume snapshots that also had that file referenced within them.
On Mon, Feb 4, 2013 at 4:23 AM, Avi Ben Emanuel (Wollman) avi@jct.ac.ilwrote:
marketing continuously claim that snap restore is instantaneous. yet I have yet to succeeded doing so. "snap restore" of files to a location quite a while and is "copying the files" nothing close to instantaneous. i would be happy to understand what i am missing. the following is a example of a virtual disk that was restored, it took quite a while to "restore"=copy this 80gb file.
snap restore -t file -s nightly.0 /vol/vmsata/vmfs1/lms-client/lms-clinet-flat.vmdk
Avi
Avi Ben Emanuel (Wollman) (אבי בן עמנואל (וולמן Systems Engineer | Unix Microsoft Vmware Jerusalem College of Technology מחלקת תקשוב בית הספר הגבוה לטכנולוגיה - מכון לב POB 16031 Jerusalem 91160 Israel הועד הלאומי 21 ירושלים Email: avi@jct.ac.il | Office: +972-2-6751036 | Mobile: +972-52-3809107
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Just to clarify, *volume* snap restoore is (almost) instantaneous, *single file* snap restore (SFSR) takes a little time.
But even SFSR isn't copying data blocks, just inode metadata, so it should be faster than actually copying 80GB of data.
On the other hand - in line with what Bill said - did you consider using the *clone* command? Especially since 8.1 (using the sis-engine now) it's really fast and wuld be an alternative to a SFSR with a different target location (but within the volume).
Sebastian
On 04.02.2013 13:39, Bill Holland wrote:
A volume level snap restore is near instantaneous as it simply has to change the active bit map table. However, what you are doing is a single file snap restore. There is more work involved in determining what blocks are used by that file. So, what NetApp does is basically a clone then split operation. This gives you access to the file almost instantaneously while it splits off the clone. They can't simply modify the bit map table as they do in volume level snap restores because you may otherwise lose the ability to restore later volume snapshots that also had that file referenced within them.
On Mon, Feb 4, 2013 at 4:23 AM, Avi Ben Emanuel (Wollman) <avi@jct.ac.il mailto:avi@jct.ac.il> wrote:
marketing continuously claim that snap restore is instantaneous. yet I have yet to succeeded doing so. "snap restore" of files to a location quite a while and is "copying the files" nothing close to instantaneous. i would be happy to understand what i am missing. the following is a example of a virtual disk that was restored, it took quite a while to "restore"=copy this 80gb file. snap restore -t file -s nightly.0 /vol/vmsata/vmfs1/lms-client/lms-clinet-flat.vmdk Avi -- ------------ Avi Ben Emanuel (Wollman) (??? ?? ?????? (????? Systems Engineer | Unix Microsoft Vmware Jerusalem College of Technology ????? ????? ??? ???? ????? ?????????? - ???? ?? POB 16031 Jerusalem 91160 Israel???? ?????? 21 ??????? Email: avi@jct.ac.il <mailto:avi@jct.ac.il> | Office: +972-2-6751036 | Mobile: +972-52-3809107 ------------ _______________________________________________ Toasters mailing list Toasters@teaparty.net <mailto:Toasters@teaparty.net> http://www.teaparty.net/mailman/listinfo/toasters
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Avi Ben Emanuel (Wollman) -
Bill Holland -
Mike B. -
Sebastian Goetze