Geoff

Here's a slightly off-the-wall and untested idea.    Since most of your
database remains the same from day to day it is wasteful  to copy it all
every time.
Take a database snapshot daily to a file volume.  Copy or rename this so
that the current version always has the same name.
Run rsync against this snapshot to get it to the other side. Or if you
want to defer the update of the remote side until you need it use rdiff.

Regards

Steve.

Steven Harris
TSM Admin,
Between jobs in Sydney, Australia


Wanda Prather wrote:

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

>
------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.53/2299 - Release Date: 08/12/09 
18:12:00