I just read this post on SANgod.com.
I must admit, you have to have some balls to call yourself a god , but if it works for him.....
Consider a M$ Windows Server 2003 host, booting of a SAN volume.
When we issue a backup of the M$ OS, including the Registry, System State, System Services and all that crap M$ automatically uses VSS to create snapshots of the Registry, System State en System Services files. When booting from SAN and enabling software connection from VSS to the storage, VSS actually goes into the storage system and issues the FlashCopy mechanism to create the copy of those files. But, instead of only cloning the files associated to the M$ services, it goes in and takes a complete copy of the entire LUN. Because the System State en the System Services are not cloned simultaneously, but serially, the boot LUN is actually copied several times.
One could argue that this is not a M$ issue, but more an IBM FlashCopy issue. I will probably agree on this. But still. Why clone a complete LUN, when you only need a couple of files. Even worse... The VSS service waits for the background flashcopy process to completely finish, before actually giving control back to the backup tool. This way, a normal (no VSS connection into the storage) backup of the OS completes in about 5 to 10 minutes. When using the VSS support to perform FlashCopy tasks in the storage box, that same backup takes up 45 to 60 minutes. This setup doesn't "do" it for me.
When the backup completes, the copy-LUNS are disconnected and no longer available for other purposes.
This is a shame. One could put these volumes to good use for other scenarios.