By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,004 Members | 1,296 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,004 IT Pros & Developers. It's quick & easy.

db2 standard backup practices

P: n/a
I've been working with db2 8.2fp14 for over a year now and was
wondering what is a "standard" way of doing a backup to provide 24/7
operations with disaster recovery capabilities?
My thoughts were an offline backup once per quarter, followed by a
monthly online backup, followed by daily backups of the logfiles.
BUT it's the details of each that I'm wondering...
1- how can i tell what logfiles need to be backedup? is there a way to
"trim" them without damaging the "disaster recovery" capabilities?
2- when restoring a database to a new server (say test environment or
disaster recover) do i need the offline db restored first, then just
roll into the latest online or should i have all onlines and logfiles
from the offline to to point of recovery?

Two big questions, I know... but I appreciate any help that people can
pass on... Thanks in advance!!

Sep 7 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Sep 7, 3:34 pm, clilush <bill.shan...@gmail.comwrote:
I've been working with db2 8.2fp14 for over a year now and was
wondering what is a "standard" way of doing a backup to provide 24/7
operations with disaster recovery capabilities?
My thoughts were an offline backup once per quarter, followed by a
monthly online backup, followed by daily backups of the logfiles.
BUT it's the details of each that I'm wondering...
1- how can i tell what logfiles need to be backedup? is there a way to
"trim" them without damaging the "disaster recovery" capabilities?
2- when restoring a database to a new server (say test environment or
disaster recover) do i need the offline db restored first, then just
roll into the latest online or should i have all onlines and logfiles
from the offline to to point of recovery?

Two big questions, I know... but I appreciate any help that people can
pass on... Thanks in advance!!
Do not randomly chose what backups and how frequently you want it.
Take into consideration the following things.

1. Would be able to afford downtime during the backup? A large
database (600-700GB) might take as much as 4-5 hours (depending on
media) for an offline backup? If no downtime can be afforded, go for
online backup. If only certain day(s) of the week can sustain a
downtime, use a mixture of both online and offline.

2. How frequently? That would depend on your restore strategy. If you
ever needed to restore from a backup image, how fast do you want the
operation to complete. Restoring from an offline backup without
rolling forward is the fastest. More logs to roll-forward = more time
it takes to restore the DB.

3. Log files. If you are performing online backups, you 'll need all
the log files since the backup was taken. If you are using TSM, set
the LOGARCHMETH1 to TSM to automatically archive log files. (IMHO,
this is the best way). You can see the status of automatic log
archiving using the db2pd command with -logs option. If you do not
have TSM, you can backup them up manually. If you want them to be
moved to a specific directory (let's say in Windows) you can set
LOGARCHMETH1 to DISK:D:\Logs. Design your log archive strategy in such
a way that you don't lose any of your logs and they are readily
available during a restore.

4. You can restore a database from any full backup (offline or online)
without having anything to do with any previous full database backups.
You 'll need to be concerned about a previous full backup, only when
you are restoring from a delta or incremental backup image.

5. How do I know which log files are needed for recovery? The minimum
log files needed for a restore from an online backup can be included
in the backup image by using the 'INCLUDE LOGS' option. However, this
will only include log files that would recover your database to a
point of consistency just after the completion of the backup. If you
are trying to restore after a couple of days of the backup was taken,
you 'll need all the logfiles to ensure you don't lose any valuable
data.

Hope this helps.
Cheers,
Sanjuro

Sep 10 '07 #2

P: n/a
On Sep 10, 4:19 pm, Sanjuro <ashru...@gmail.comwrote:
On Sep 7, 3:34 pm, clilush <bill.shan...@gmail.comwrote:
I've been working with db2 8.2fp14 for over a year now and was
wondering what is a "standard" way of doing a backup to provide 24/7
operations with disaster recovery capabilities?
My thoughts were an offline backup once per quarter, followed by a
monthly online backup, followed by daily backups of the logfiles.
BUT it's the details of each that I'm wondering...
1- how can i tell what logfiles need to be backedup? is there a way to
"trim" them without damaging the "disaster recovery" capabilities?
2- when restoring a database to a new server (say test environment or
disaster recover) do i need the offline db restored first, then just
roll into the latest online or should i have all onlines and logfiles
from the offline to to point of recovery?
Two big questions, I know... but I appreciate any help that people can
pass on... Thanks in advance!!

Do not randomly chose what backups and how frequently you want it.
Take into consideration the following things.

1. Would be able to afford downtime during the backup? A large
database (600-700GB) might take as much as 4-5 hours (depending on
media) for an offline backup? If no downtime can be afforded, go for
online backup. If only certain day(s) of the week can sustain a
downtime, use a mixture of both online and offline.

2. How frequently? That would depend on your restore strategy. If you
ever needed to restore from a backup image, how fast do you want the
operation to complete. Restoring from an offline backup without
rolling forward is the fastest. More logs to roll-forward = more time
it takes to restore the DB.

3. Log files. If you are performing online backups, you 'll need all
the log files since the backup was taken. If you are using TSM, set
the LOGARCHMETH1 to TSM to automatically archive log files. (IMHO,
this is the best way). You can see the status of automatic log
archiving using the db2pd command with -logs option. If you do not
have TSM, you can backup them up manually. If you want them to be
moved to a specific directory (let's say in Windows) you can set
LOGARCHMETH1 to DISK:D:\Logs. Design your log archive strategy in such
a way that you don't lose any of your logs and they are readily
available during a restore.

4. You can restore a database from any full backup (offline or online)
without having anything to do with any previous full database backups.
You 'll need to be concerned about a previous full backup, only when
you are restoring from a delta or incremental backup image.

5. How do I know which log files are needed for recovery? The minimum
log files needed for a restore from an online backup can be included
in the backup image by using the 'INCLUDE LOGS' option. However, this
will only include log files that would recover your database to a
point of consistency just after the completion of the backup. If you
are trying to restore after a couple of days of the backup was taken,
you 'll need all the logfiles to ensure you don't lose any valuable
data.

Hope this helps.
Cheers,
Sanjuro
to add my 2 cents worth, I suggest you practice doing the restores, so
that when needed for a real emergency, you are sure you know how to do
it.

Sep 10 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.