So I generally write my posts a day ahead and schedule them to be posted mid-morning when I think people would be around to see the tweets or other indications there’s a new post. But I was sick yesterday. So it probably looked to my employer like I was posting on my blog when I was too sick to work, but whatever – I actually schedule multiple days ahead when I get a writing bug. So today’s a quickie that I can write on my lunch break.
DB2’s data integrity, including that of backups, is rock-solid. As I learn more about Oracle and other database management systems, I am more in awe of how well db2 does in this regard.
However, there are times you want to make absolutely sure that a backup is rock-solid. Recently I simply had a session that I was taking a backup from hang, and wanted to make sure that the image on disk really was good, even though I didn’t get my “Backup successful. The timestamp for this backup image is :” message back. In this scenario I was about to start a restore using that image on another server, and would rather not transfer it over and start the restore (with down time) only to find the backup I was working from was bad. I would also use this for a backup prior to a full version upgrade, because I would want that backup to be 100% certain. But full Version upgrades only come up every few years, and frequently Commerce customers decide to rebuild instead of migrate.
So the simplest form is:
db2ckbkp <backup_image_name>
e.g.
db2ckbkp SAMPLE.0.db2inst1.NODE0000.CATN0000.20110115163653.001
or
db2ckbkp /db_bkup/full/SAMPLE.0.db2inst1.NODE0000.CATN0000.20110115163653.001
You have to either be in the same directory as the backup image when you run it, or specify the full path to the backup image.
This utility can take as long to run as the original backup took, so don’t be expecting an immediate answer. Depending on the OS, it may output hash(pound) signs while it’s running. Once it says that it is successful, you know that your backup image is OK. I’ve even seen this coded into backup scripts – it isn’t a bad idea, but I don’t believe it’s needed on an ongoing basis unless you have issues with corrupt backups. I can’t actually recall a case of a corrupt backup in my career, but it seems that a colleague ran into it and was very happy to have an older backup around to use instead.
There are a few other nifty functions db2ckbkp can perform – most notably pulling out tablespace container paths/files and/or AST paths – something very important if you’re restoring from a backup where you don’t have access to the system the backup came from.
It’s very different, but there’s also a db2ckrst – it checks to make sure you have all the files you need to do a restore when you’re working with incremental or delta backups. This tool can be invaluable if you are somehow forced to do a manual incremental restore.
References:
nice info….