Nic

Would your situation be a good reason for a separate domain
and offsite pool that would keep everything on their 'own' tapes??

         ... joe.f.

Joseph A Faracchio,  Systems Programmer, UC Berkeley
Private mail on any topic should be directed to :
         joef AT socrates.berkeley DOT edu
 (510)642-7638 (w)  (209)483-JOEF (M)
                             5633

On Tue, 18 Dec 2001, Nicholas Cassimatis wrote:

> The one topic no one is mentioning is Disaster Recovery.  It's very hard to
> collocate an offsite pool.  The only way to reduce the number of tape
> mounts is to do some type of full backup periodically (either backup or
> archive).
>
> I started doing "full backups" of SAP filesystems after doing a DR with two
> 3590-B11's as my 3494 tape library.  After 1800 tape mounts to restore
> /saparch, something had to be done.  Watching TSM restore 1 file from each
> tape made it imperative.  "Full backups" was the something (Note the quotes
> - see below).  Taking "full backups" periodically drastically reduces the
> number of tape mounts needed to restore at a DR, since the data should not
> spread across more tapes than the number of days since the last full
> backup.  So our 1800 mounts above comes down to 7, if weekly fulls are
> taken of the systems.
>
> Now comes the argument of "That's duplicating a lot of data!"  Yes, it
> does.  So figure out what needs to be restored in this way (the answer is
> "Not all of /saparch" for you SAP accounts out there) to bring the system
> back up in case of a disaster.  Work with data owners to see what they need
> back immediately, and what can wait until after the system is back online
> and running.  There's more in that second list than you may think!
>
> My "Full Backups" are therefore weekly archives of critical path data,
> which are kept for 2 weeks.  At a DR, I do a retrieve, then a restore of
> the incremental data since the archive (then I script the retrieve and
> restore, just to speed it up even more, but that's a different thread).
>
> Nick Cassimatis
> nickpc AT us.ibm DOT com
>
> Today is the tomorrow of yesterday.
>