The Complete Geek

The simple answer is no, the more complex answer is it depends.

 Point in time copies (snapshots) can drastically increase your time to recovery. And can be incredibly useful for data restoration due to an application/operating system/ file system/ user problem.

That being said, really the idea of a true backup is to handle DR and the failure of systems, disks and other problems. Being that your data and copies reside in the same hardware/location it does not protect you against such failures.

Now the reason above I stated is "it depends" is because some vendors are offering the replication of existing point in time copies to a remote system. So the idea is that when it resides on the same system it is not fully useful as a backup media but once it gets transfered/archived and if that archive container the sum total of the original data as well (So a mirror or replication) it can act as a full backup.

Current Problems
There is some possibilities here,  If you are simply looking for a point in time to be able to restore to for DR for the short term you can fulfill this with a large archive of remote point in time copies (replicas) but with current vendors these technologies fall flat in two area's

1) Long term storage
A lot of vendors are trying to make improvements in this area but still fall short. While it may be feasible to store weeks or even months worth of daily snapshots is doable with some of todays vendors really keeping a lot of these around for years is non feasible. This storage space is also relativity expensive per GB compared tape and other media. At best it can be used as a "Mid Teir" place to store info to reduce your "race to daylight"

2) Archival, cataloging
No solution that I am aware of (and if you know any different please share!) really handles the cataloging on a file level that is available to some other server side tools. What happens when you have a user that asks "I deleted a very important document from 2 months ago, I don't remember its name exactly but it was financial something or other and was an excel spreadsheet" or "I have not looked at my important financial document in a year but someone changed it in the last year, I want the one that was modified in 2008"

With E discovery tools available to some backup solutions this is easy to do I just search for *financial*.xls?  but with block level point in time copies this is not as easy.

Some vendors are making strides (specially if they also do file level shares) and are going in the right direction but are not there yet.

Long term storage


A nice trend I am seeing in industry is the ability to ship point in time copies off to alternative media, this is a great idea. Quite a few vendors are making an effort to be able to do things like use standard NDMP to be able to export the data directly from the SAN to something like a data domain or a VTL or directly to tape. This makes long term storage more feasible and  economical.

My take on it
Point in time copies are a great way to prevent against many different types of non storage layer problems, and replicas can even help with that. But in the end without cataloging the usefulness and ability to do file level recovery and E-discovery is non existent. It may be perfectly fine for your industry but in some that is a challenge.

Labels: Backups, Point in time, SAN, Storage

I am approaching this from the point of view of our EquaLlogic SAN some of these (namely number 4) may not be as big of an issue. Also discussing in the 3.5 world for most of this will address what 4.0 changes in the end

Pro

1) One place that VMDK’s are a good choice to use is where you have questionable System administrators with local administrative accounts. In some cases we have vendor or client administer accounts (they are the exception) so they can handle specific processes. The problem is if the virtual actually has adapters on the SAN network they have a more direct avenue for causing problems weather on purpose or accident. Anything from re-addressing adapters or some mal-ware that could get installed as they are an admin (not likely in a controlled environment but still possible)As such VMDK’s protect that network from those admins.

2) VMDK’s also behave nicer in the case of SAN failure or performance issues, if a virtual looses connectivity to its VMDK it pauses rather than dropping the volume.

3) Svmotion, while moving volumes between pools is easy moving them between groups and or different SAN vendors is much harder. There are processes but if your data is in VMDK it is a snap. Simply mount the new SAN or volume in a new group and fly, no downtime necessary for what would have been a major move. Virtual storage is the best thing for storage administrators.

4) Not having to administer separate SAN volumes and configuration. This cuts deployment time for a SAN volume to a fraction of the time separate volumes take. Not having to setup ACLS, MPIO configurations … install HIT and configure adapters. It cuts deployment time from a half an hour to 2 Minutes and moves the knowledge out to system administrators rather than storage administrators.

5) We have run across a number of situations lately that either required a host integration tool upgrade or MSISCSI version upgrade to overcome the loss of connectivity to volumes. This is a BIG deal when that means touching 200+ servers. Reducing update and hand maintenance tasks is a huge money saver from the point of view of labor costs.

6) And the last advantage Ill discuss is administration security, unfortunately the granularity of permissions for EqualLogic is lacking. You may not want all your system administrators to be group admins just so they can expand a SAN volume. We have in the past written custom interfaces to achieve this without giving them direct permission but VMDK’s also achieves this. No longer does a sys admin need to be a group administrator on your SAN just for creating new volumes or expanding drives.

Con:

1) Performance: This is the biggest concern with 3.5 not supporting MPIO on its software initiator the performance is just not as good in the equallogic world where MPIO has a huge impact on performance.

2) Not able to take advantage right now of some of the advanced features the Host integration toolkit provides you. Most people are not using these features so it is not as large of a concern

And I am not pleased to say that we are seeing awesome performance (especially with the new beta driver) out of vsphere4 as the software initiator now does have MPIO support. We are likely to evaluate it as our default configuration (presuming successful testing in production) because of the advantages.

Labels: EquaLogic, ISCSI, Storage, VMDK, VMFS