• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Can I restore TSM database from storage snapshots?

vkky2k

ADSM.ORG Member
Joined
Jun 17, 2017
Messages
28
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.
 

RecoveryOne

ADSM.ORG Senior Member
Joined
Mar 15, 2017
Messages
347
Reaction score
81
Points
0
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.
 

Sunhillow

ADSM.ORG Senior Member
Joined
Oct 27, 2003
Messages
392
Reaction score
16
Points
0
Location
Stuttgart, Germany
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.
 

RecoveryOne

ADSM.ORG Senior Member
Joined
Mar 15, 2017
Messages
347
Reaction score
81
Points
0
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.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

DigitalOcean $100 Credit

Support ADSM.ORG and get DigitalOcean FREE credit. DigitalOcean currently offer a $100, 60-day Free Credit for new accounts. Sign-up here:

DigitalOcean Referral Badge

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 20 18.7%
  • Keep using TSM for Spectrum Protect.

    Votes: 65 60.7%
  • Let's be formal and just say Spectrum Protect

    Votes: 13 12.1%
  • Other (please comement)

    Votes: 9 8.4%

Forum statistics

Threads
31,898
Messages
135,992
Members
21,783
Latest member
london
Top