Hi all,

I wonder if it was possible to use a system snapshot as a backup strategy to make Db2 backups.

The idea is to keep DB2 online and just make a system disk snapshot (ex of linux command: lvcreate --snapshot) of the Db2 data and log directory (isolated in a dedicated Volum group).

The snapshot can be then saved elsewhere without disturbing the DB.
The restore of this backup will require an automatic database recovery from the logs (included in the backup).

Have you tried such approach? have you got some information about thsi?

thanks

This might help you.

http://www.ibm.com/developerworks/db.../dm-0508quazi/

Andy

Thanks Andy!
I would expect some thing named "snapshot" but the "Split Mirror" is really what I was searching for.

thanks

If all you want is to take a backup while the database is still available it is much easier to use the "ONLINE" option of the backup command. Remember to use the "INCLUDE LOGS" option too : it doesn't become the default until V9.5 I think.

This is much easier both to set up than split mirror. You can throttle the backup so that it doesn't interfere with your online performance too.

I assume you already have set up archive logging to write logs to an off-server location automatically ?

If you have backup servers such as TSM or Veritas NetBackup at your disposal then you can write backups and logs directly to these automatically. Schedule the backups either using the built in DB2 scheduler or your scheduling tool of choice and it becomes basically "no further action required".

HTH

Phil

Yes Phil, I already use a backup online with TSM but I look for an alternate way of taking an immediate copy of the database to populate easily other databases without consuming resources from TSM.

The Split mirror is a good alternative here.

I used to do similar strategy for mysql database backups and it works really great.

Vincent

... just wanted to ensure you weren't putting yourself to more work than is necessary.

We do all our restores into development from TSM : we've managed to work out how to switch between our production and development TSM servers at will and probably know more about TSM than we ever wanted to know :-(

We're going to have to start looking at alternative ways of producing copy databases, since some of our production databases are now bigger than the capacity of our development servers. Optim looks like one potential solution, and also gives us added benefits in terms of data scrambling and security.

Phil