backup & filesystem snapshot question

[william.david.anderson]

Hi there,

I have a newbie question about backing up our database on our
Solaris
system. I was reading the "Data Recovery and High Availability
Guide
and Reference", but didn't see any references to using filesystem
snapshots
to backup a database.

Is using a filesystem snapshot (and then backing up that snapshot
to
tape or other media) a reasonable approach to backing up a DB2
database?
I was thinking of using the "set write suspend" command to quiesce
the
database before the snaphot is taken.

If this is a reasonable approach, how would one make sure that any
unwritten
system memory buffers are written to the disk subsystem before the
snapshot
is taken? The "sync" command would flush the buffers, but I think
it's an
asynchronous operation and returns before guaranteeing that the
buffers have
been flushed.

Thanks for any help,

Bill

[aj]

This is cool stuff. I can't really answer your questions, since my SAN
doesn't want to do this for me.. However, here's a good article:

http://www-128.ibm.com/developerwork...azi/index.html

hth

aj

wi************* *******@gmail.c om wrote:

Hi there,

I have a newbie question about backing up our database on our
Solaris
system. I was reading the "Data Recovery and High Availability
Guide
and Reference", but didn't see any references to using filesystem
snapshots
to backup a database.

Is using a filesystem snapshot (and then backing up that snapshot
to
tape or other media) a reasonable approach to backing up a DB2
database?
I was thinking of using the "set write suspend" command to quiesce
the
database before the snaphot is taken.

If this is a reasonable approach, how would one make sure that any
unwritten
system memory buffers are written to the disk subsystem before the
snapshot
is taken? The "sync" command would flush the buffers, but I think
it's an
asynchronous operation and returns before guaranteeing that the
buffers have
been flushed.

Thanks for any help,

Bill

[william.david.anderson]

Thanks for the info. I appreciate it.

Bill
On Feb 8, 10:23 am, aj <ron...@mcdonal ds.comwrote:

This is cool stuff. I can't really answer your questions, since my SAN
doesn't want to do this for me.. However, here's a good article:

http://www-128.ibm.com/developerwork...rticle/dm-0508...

hth

aj

william.david.a nder...@gmail.c om wrote:

Hi there,

I have a newbie question about backing up our database on our
Solaris
system. I was reading the "Data Recovery and High Availability
Guide
and Reference", but didn't see any references to using filesystem
snapshots
to backup a database.

Is using a filesystem snapshot (and then backing up that snapshot
to
tape or other media) a reasonable approach to backing up a DB2
database?
I was thinking of using the "set write suspend" command to quiesce
the
database before the snaphot is taken.

If this is a reasonable approach, how would one make sure that any
unwritten
system memory buffers are written to the disk subsystem before the
snapshot
is taken? The "sync" command would flush the buffers, but I think
it's an
asynchronous operation and returns before guaranteeing that the
buffers have
been flushed.

Thanks for any help,

Bill

[=?ISO-8859-1?Q?Rasmus_M=F8ller?=]

Warning: Windows server 2003 specific information.

We use this approach in production since a few years for backup of DB2/
UDB (SAP central inst w. DB on Windows server 2003)

You need enough free space on each drive for this to work with Windows
2003 Volume Shadow Copy.
Alternatively you could have a single drive with enough freespace for
the /on parameters below.

We use a script like db2cmd -c -i -w snapshot.cmd where snapshot.cmd
contains

for %%a in (C D E F G) do vssadmin add shadowstorage /for=%%a: /on=%
%a:
db2 connect to mydb
db2 set write suspend for db
vshadow -p -script=set_vol_ var.cmd C: D: E: F: G:
db2 set write resume for db
call set_vol_var.cmd
.... mount VSC snapshot id's as drives or subdirs ...
.... backup mounted drives/subdirs at your leisure ...

Feel free to inquire more details here or by email:
an************* **************@ spamgourmet.com