Since ADSM is a file backup tool, the client that is using the EMC space
must be involved in the backup of that space.  It is certainly possible to
have another OS come along and backup up the container, but this defeats the
purpose of file level restore.

This is a very misunderstood problem with generic SAN implementations.
Tivoli is addressing this with the notion of backups not requiring the
client.  But as you can imagine this is a hard problem.  Ideally, the SAN
controller will ultimately have some view into the filesystem within the
container.  Until that happens (and in some standardized way) the ability to
provide file level backup will stall.

Backing up the containers is interesting but not useful.  Remember 99% of
restore requests are for a single file.  If you have to restore the entire
container to get a single file you will be hating life.

The idea of SAN is going to make backup/restore worse for awhile, IMHO.  I
believe the ADSMs of the world will begin to address this, but it makes more
sense to continue to apply reason and logic the problem now.  Don't create
something you can't backup and restore!  The issue usually boils down to a
couple of things: the LAN is too slow/overutilized, etc., and emotionally, I
want to use this high speed fiberchannel interface to do this.  Well, if the
LAN is to slow, overutilized, etc., add more LAN.  As to the emotional
problem: get over it.  Once we get IP on the fiberchannel pipe, we can run
normal ADSM on this "network".  Until then, business as usual.

This is a classic case of the hardware outpacing software.  Continue to try
to solve the business problem and don't get caught up in the technology.
Just because you can doesn't mean you should.

Now, what was the original question?

Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80919
(719)531-5926
Fax: (719)260-5991
www.storsol.com
lipp AT storsol DOT com