Business Copy on EVA

[raadek]

Hi All,

I've done my homework, i.e. read through other threads, QuickSpecs, etc., but I still have some outstanding questions re how snapshots actually work on EVA box.

Basically Vsnaps look like a way to go: in my opinion space-efficiency is an essential part of good snapshotting implementation.

But looking at Business Copy QuickSpec I found this:
"Instant Restore: With the EVA4000/6000/8000 arrays, users can restore a source volume using a normalized Snapclone, MirrorClone*, Snapshot* or any other Vdisk of the same size."

Does above mean it is not possible to do a quick restore from a Vsnap?

And are there any other considerations / caveats with Vsnaps?

As usual all your help is much appreciated (& rewarded with points).

Rgds

[Bill Costigan]

It depends on the version of firmware.

Before version 6, there was no way to simply restore the parent LUN from a snapshot.

Software such as Data protector got around this by using clones which are not connected to the parent once created.

If the clone was on the same performace disks one could blow away the original LUN, rename the clone to the original's name and re-present it to the host with the same LUN number.

If the clone was on slower disks (e.g. FATA) you could still blow away the original and then use the clone as the source to create another clone on the faster disks using the original LUN's name and present it to the host. (this of course would work even if the disks were of the same performance type)

With version 6.0 there are new options including mirrors. The parent can now be restored from either a snapshot or mirror. I'm not sure if Data Protector has been updated to take advantage of the new features.

As far as I know Vsnap and snapshot are just two terms for the same thing.

[raadek]

> As far as I know Vsnap and snapshot are
> just two terms for the same thing.

Bill,

I think you are incorrect - BC QuickSpec says:
"Snapshots: A standard snapshot (full allocated)...
Vsnaps: Virtually capacity free snapshots (demand allocated)..."

Hence my question, i.e. if they are different, do they behave differently, especially in the terms of a quick restore?

Rgds

[Bill Costigan]

I was aware that there were two flavors, I didn't realize that they both were not called Vsnaps.

As far as I know, if 10% of you blocks changed then only 10% of the blocks are duplicated in either flavor. The reason for having the fully allocated space version is to avoid the problem of running out of space if too much of the LUN changes.

I cannot see a reason why there would be a difference between the two in terms of restoring the original. But then again I often find things do not work for reasons I cannot explain.

[chris callihan]

snapshot (or VSnaps) will always be space efficient, but "fully-allocated" will immeadiately lower the remaining available space for new volumes (by the amount of the source volume size plus the raid overhead). for "demand-allocated" that free space available will only be decreased as the snapshot does the copy-on-writes as the source is written to, or to direct writes to the snapped volume. Using "demand-allocated" you can actually overprovision the array, but could lose a snapped volume if you run out of free space. "fully-allocated" prevents that potential loss.

[raadek]

Chris,

I understand the whole idea of copy-on-write, allocating, over provisioning, etc.

What bothers me though, is the question whether it is possible to quickly roll back from an EVA Vsnap or not (see my initial post in this thread quoting BC QuickSpec).

Rgds

[avik]

vsnap is a temporary snap of your production vraid, you may be able to mount it & access but there is a cons. of overcommit. I dont think you can make this vsnap the primary-copy.

I know that this is possible in NetApp with an additional license of SnapDrive which gives you the capability to make snapshot of a volume as primary copy.

[Uwe Zessin · Accepted solution]

I didn't have time to try it, but the SSSU V6 documentation lists the RESTORE option for the "SET VDISK" command:

""Restores data from the mirrorclone or snapshot to the source virtual disk. Data on the source virtual disk is overwritten even if the source virtual disk is write-protected. Only unpresented mirrorclones and snapshots are eligible for restoration.""

[raadek]

Thanks Uwe.

It basically confirms what QuickSpec says (at least I understand it this way) - i.e. a quick restore directly from Vsnap is not possible.

Gruà .

[Uwe Zessin]

No, I understand that it is possible.

I don't beleive that the restore mechanism distinguishes between a fully-allocated snapshort and a demand-allocated snapshot.