Is there a documented procedure for restoring data from a snapshot for the Compellent SC4020 as I cannot see any options on the snapshot or volume.
One possible way would be to:
This is very convoluted and means the server now sees a new set of LUN ids - surely there is an easier way to do this - all other snapshot technologist I have used simply have a "restore data from snapshot option"
Linked above is the Admin guide for Dell Storage Manager, which should have the functionality you're looking for. Page 116 goes into detail on making recovery volumes from snapshots.
The important thing to note is you'll want to unmap the Recovery (View) Volume once done using it, or the snapshot it was taken from won't expire.
This method provides a way to restore data in a side-by-side manner where you won't have to do anything with the original LUN ID. Let me know if that helps clear things up, or if you have other concerns.
Thanks for your reply.
There are 2 reasons to take a snapshot:
When you create the snapshot - the process is the same for 1 and 2, and hence the section you refer to has an option "Create Volume from Snapshot" with NO reference to "recovery", which is correct as this could be used for purpose 2 above which is NOT for recovery. So the option in the GUI does NOT say "Create a Local RECOVERY Volume from Snapshot, so I don't know why the the title of this section does.
What usually differentiates when a snapshot is used for recovery is the way you "use" it, not the way you "take" it, so normally you are able to roll back the volume to the PIT that the snapshot was taken and there is no need to create a view in this process. But I cannot find the process of using the snapshot for recovery in this guide - therefore I can only assume the process is as outlined in my opening post (but in step 3, you don't have to delete the original volume, you can JUST unmap it - if you have enough space, you can keep it for a bit).
The downside of this approach is it has more steps than simply rolling back the volume and seemingly this process is undocumented which is what you don't want when your data is corrupt and your system is down and you need to roll back to your snapshot.
In addition to this, the snapshot will have different LUN ids, so on the host side you will have to do extra steps of not just umounting the filesytems, but also deporting volume group and removing devices and re scanning and then the bigger problem is that with different LUN ids, there is no guarantee the O/S devices are created with the same names as before, in fact, if you say have 20 volumes, then unless you took the snapshot of each volume in the order you created the initial volume, the you are guaranteed to have different disk device names on the host and this means you have to map the old LUNid to the new LUNid and update the new disk device name to be able to access the right data - not something you want to be doing when your system is down and you are needing to recover quickly.
So am I correct in my opening process, that this is the process for recovery and is this process documented - i.e a specific procedure of how to recover your data using a snapshot
I followed up and spoke to a few Compellent support reps who have said the information I provided is correct. You can certainly try the process you laid out, but it isn't what they recommended. If your way does work, then that'll be good to hear.
If you'd like, you can send me your service tag (or serial number) and I can check the warranty status and find the phone support number for your region.
I'm sorry, I'm confused, I thought you were suggesting my procedure which is very similar to the procedure you reference:
Let's give an example with a single LUN:
LUN is called ORIG and has serial number 0 and this is mapped to host and the host sees disk0 belonging to VG0 and is mounted as /data
Snapshot LUN of ORIG is called SNAP which when volume is created gets given serial number 1
I umount /data ready to restore data from snapshot
So in the procedure you reference:
Step 5: Create Volume from Snapshot which is also called creating a view on a volume - i.e it is not a full volume - it is a view which relies on BOTH ORIG and SNAP - this is Step 1 in my procedure
Step 8: Map recovery volume to server - this is Step 4 in my procedure
So now on the host, the VG0 on ORIG is still there. If this host is Linux then you now have second VG called VG0 on SNAP and most systems can't cope with this so you may have just corrupted your data. If this host is HP-ux (which mine is) then the new SNAP disk does not have a VG name because VG name is stored on the host and the host does not know what serial number 1 is. The disk device name for SNAP in the host cannot be called disk0 as this already exists, so I now have a new disk1 and I can't create a VG0 as this already exists. If I create a new VG1, then this will change the block device so then I would have to update fstab to reflect this.
So I think you can see here, that you need to unmap ORIG before mapping SNAP which is what I did in step 3
So if you unmap first, then SNAP may still get assigned a disk device other than disk0 and if you have 20 disks, then these WILL have different device names unless you create the snapshots in the exact same order you created the original volumes and even then there is no guarantee that you will get the same device name (the only guarantee is if the disks have the same serial number)
So now I have a mapping exercise to map the old serial numbers to the new serials number and correlate this with the new disk device names.
So if I do all this, then I can now mount /data, and if I am happy with the restored data then I now want to remove ORIG, but I can’t do this as my view volume relies on this, so I need to copy the view volume into a new volume – this is my step2.
So the procedure you reference is the same as mine except it is missing step 2 and step 3 which need to be done at some point so, unless I am missing something here, the procedure in the manual has to do the 2 extra steps I do at some point and presents “recovery” LUNs with different serial numbers than the original and this causes a lot of work.
In other technologies, you simply roll back ORIG to SNAP and so you are not changing any serial numbers so you don’t have to do any unmapping and mapping of serial numbers and on the host you just mount the data. So I just want to make sure that this method of keeping the original serial numbers is NOT possible before we test recovery in a couple of weeks, where the current plan is the convoluted procedure I have outlined.
If I am wrong and there is an easier process, then great, please share this.
Just to add this would be no different if the host was Windows, so then if you have 20 LUNs with drive letters 😧 to W: then if you present 20 new LUNs with different serial numbers, then your drive letters are not guaranteed to be the same as before
Good morning Mike,
It may be the case that we misunderstood each other (much more likely to be on my end). With my reply, I'd just been trying to say something akin to "the supported process looks like this, per Compellent," not send a message saying "No, you're wrong." If I came off rude, I certainly apologize, that was absolutely not my intention.
The core of what I needed to confirm with Compellent support is that snapshots weren't designed to restore data, but for data progression down the tiers in a Compellent system.
It has been recommended to me to help get you to one of our phone teams, though. I wouldn't recommend posting your service tag (or serial number) in the public forum, but you can send it to me in a private message and I can see what options there may be, or I can get you the number to support and you can go ahead and call into the queue. If there's anything I can do to facilitate, please let me know.