I've forgotten what hardware platform you have, so modify the suggestions
based on what you have available;

I have different customers using different means; several things work.  Just
remember to TEST the results at your DR site.  And now matter what your
method, it's going to depend on having the bandwidth to get the job done.

-If you have any hardware replication capability (say EMC SRDF, or SVC), put
your DB on a LUN with replication and have the hardware replicate the DB and
log, they have to be in a "consistency group" (meaning the I/O's must be
replicated in order).  Nice thing about this, you don't have to reload the
DB at the DR site, it's ready to go.

-If you don't have any replication capability, you can back up the DB to a
file device class.  The resulting .dbb file is "just a file".  You can use
gzip or tar to compress that file, which will help, and use secure FTP to
send it to your DR site.   Works just fine.  Uncompress and restore the DB.
(You can even script the DB reload daily.)

Gotcha:  you'll probably need to adjust your recovery procedures at DR.
People who send their tapes offsite daily, have the DB and copy pool tapes
going out together.  That means at your DR site, you'll have all the copy
pool tapes the DB knows about.

If you back up your DB overnight, send it to DR, and send out your copy pool
tapes the next day, depending on the timing of a disaster, you may end up
with your DB from Tuesday at the DR site, but the copy pool tapes from
Monday, without the copy pool tapes from Tuesday having made it to the
vault.  So the first thing you need to do after reloading the DB, is a
manual audit of the copy pool tapes, and delete from the DB any you don't
actually have.

W


On Wed, Aug 12, 2009 at 8:28 PM, Gill, Geoffrey L. <GEOFFREY.L.GILL AT saic DOT 
com
> wrote:

> I'm looking at different ways to try and get the most current db backup
> to a DR site by the quickest and easiest means, and hopefully on a daily
> basis. (might be wishful thinking) At the moment I'm not sure what sort
> of link we'd have for data throughput. Even if I do get something in
> place it would be in a testing stage to see what sort of times it would
> take to get it there over the wire. The distance will be significant and
> the db size currently is 122GB about 58% used. Currently db backups are
> to tape and sent offsite.
>
>
>
> I was wondering how others have attempted to keep their db backups up to
> date at a DR site and what sort of success you've had. What did you end
> up implementing and how is it working out?
>
>
>
> Thanks for any suggestions and information.
>
>
>
> Geoff Gill
> TSM Administrator
> PeopleSoft Sr. Systems Administrator
> SAIC M/S-B1P
> (858)826-4062 (office)
>
> (858)412-9883 (blackberry)
> Email: geoffrey.l.gill AT saic DOT com
>
>
>