Can I restore TSM database from storage snapshots?

vkky2k

ADSM.ORG Member
Joined
Jun 17, 2017
Messages
36
Reaction score
0
Points
0
If I take storage snapshots on TSM database located on a storage NFS volume, and the storage will take snapshots regularly as backups of the database. When I have any issues with DB, can I restore from one of snapshots?

Thank you in advance for your inputs.
 
I've never attempted to restore the TSM database from snapshots. I'm going to say you can try, but IBM may not support it. I didn't see anything in the documentation saying that's a supported way either.

The thing is, its not just the database. Its the active logs, the archive logs, and even the data in sqllib of the tsminst1 user. Since the storage snapshot is taking a point in time of the database, not having all those things in sync might be a real pain in the rear.

I would honestly stick with the tried and true method of letting the server manage its backups via admin tasks. This way you have the volhist, devconfigs and a consistent database backup.

Nothing is stopping you from trying to get the system up and running from a storage level snapshot, and if you have cycles and resources to burn give it a shot (IN A NON-PROD ENVIRONMENT)! May learn something alone the way.
 
In almost all cases the TSM DB survives an abrupt hardware power off. So I assume (!!!) it will also survive a restore from snaps. Including all log filesystems of course!
But as @RecoveryOne already stated, this is highly experimental and noone from IBM will help you when you do it this way.
 
In almost all cases the TSM DB survives an abrupt hardware power off. So I assume (!!!) it will also survive a restore from snaps. Including all log filesystems of course!
But as @RecoveryOne already stated, this is highly experimental and noone from IBM will help you when you do it this way.

Right, but that abrupt poweroff would likely also affect more than just the DB, it would affect any storage volumes. So, we we are just talking about what would happen if just the DB was restored from hardware based snapshots, what of all the new storage volumes or changes that occurred to said volumes. Now you have volumes and a database out of sync. Where the abrupt poweroff everything is (for lack of a better term) in sync.

Having tested first hand what an alt_disk_upgrade looks like with the /home/tsminst1 on the rootvg, then cloned to hdisk2 while the dsmserv process was running, it wasn't pretty. AIX upgraded fine to the alt_disk, but since /home/tsminst1 was 'changing' during the alt_disk operations, then rebooted from alt disk, db2/dsmserv didn't like all the 'old' data in the alt_root_vg of hdisk2 upon boot. I'd imagine you'd run into a very similar situation. Sure, one could have then halted dsmserv, then run a syncvg -l operation for the hd1 logical volume (or custom logical volume if you have one for /home/tsminst1) and that may have worked. I didn't have time to fully test that however.

That said, try things out in a non-prod environment! Sometimes that is really the best way to learn! Some examples that a non-prod even if not even close to like for like that helped me:
Proved that the SAN infrastructure between my TSM server and storage array wasn't upto snuff.
Proved that the SAN infrastructure between my TSM server / storage array/ tape drives also wasn't up to snuff.
Proved that the Cisco Etherchannel config my NA team originally had in play, was only running at I think 2G instead of the theorized 4G. Going from memory we had 6's so load balancing was 2G with backup of 1G. Think this doc explains it all! https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html - OLD setup by the way.
And well, so much more.
 
Back
Top