<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>First question:
Are these setting correct for moving tapes to offsite everyday.
REUSEDELAY=7
DRMDBBACKUPEXPIREDAYS=7
Full DB Backup - once a week
The second question.
Are these setting correct for moving tapes to offsite everyday.
REUSEDELAY=0
DRMDBBACKUPEXPIREDAYS=0
Full DB Backup - everyday
Mat (mfinch)</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>
Mat --- Asking this crowd if these settings are OK, is a difficult question to answer because we have no idea what it is your trying to accomplish. However, we can tell you what the impact of these settings will be on your system. So, here we go:
REUSEDELAY -- controls how long the volume will sit in "PENDING" state before it gets returned to you from the vault, etc. The idea here is that if you most recent DB backup is bad or got destroyed then you can go back to a previous day DB backup and be assured that the tapes needed to be in sync with the DB will still be around (ie not overwritten or scratch).
DRMDBBACKUPEXPIREDAYS -- This controls how many DB backups you will have offsite before they expire and come back as scratch.
These 2 particular setting are related to each other, and will have an effect on how many tape volumes you have rotating to/from the vault and how fast that exchange occurs. Since you did not specify which type of media your using, at anything from $30 to $100 per tape volume are you (or more accurately) or management willing to foot the cost of adding additional tapes into the rotation to cover the delay factor you thinking about inserting into the rotation process. The cost being either a little or a lot depending upon your media type, and the parameters you set.
Realistically, the answer to setting these parameters and related questions are dependant on you DR goals and how much data loss you are willing to sustain. For example, if your most recent DB backup tape is bad, and you have to use the prior days DB backup you have already established that the data restored will be more than 24hrs old, probably more like 48hrs old. Is that OK? What if you have to go back further?
All I am saying is if you are going to use these parameters, think about what your trying to accomplish (ie your DR goals), prepare management with some cost expactions and set the values accordingly. Hope this helps,
Andy.