• 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.

Moving to Containers

Ekaj525

ADSM.ORG Member
I starting a tech refresh for our TSM setup. I am looking to move to containers. I have done my homework, purchased the correct hardware and have laid out a plan. I read in IBM's best practices that if we backup to tape from stgpools that containers isn't the best option. So my question is should I go to containers if I need to have the tapes because of policy? If I understand everything correctly what gets backed up to tape is not the individual pieces of data but the stgpool extents? If I lose all my stgpools can I restore them from tape?
 

marclant

ADSM.ORG Moderator
If I understand everything correctly what gets backed up to tape is not the individual pieces of data but the stgpool extents?
Correct
If I lose all my stgpools can I restore them from tape?
If you lose your container pool, you can repair the container pool from tape, that's not the issue. The issue is that since it's extents on tape, clients can't restore from tape, so in a DR, clients would have to wait until the storage pool is fully repaired before they can attempt restores. And that can take a few days or more depending on the size.

So in the event of a real DR, can your company afford to wait a few days before being able to restore clients at the DR site? In most cases, the answer is no.

So that leaves you with two options:
1 - have 2 SP servers in 2 different locations and use protect stgpool and node replication to keep both sites in sync. So if the primary server goes down, clients can do restores from the secondary server. If the outage is for an extended period, the secondary server can be changed as the primary to allow client backups. You can still do a 3rd copy to tape for legal requirements if necessary. Ideally from the secondary server to relieve the primary server from that workload.
2 - use traditional storage pool(s) with tape copy pool
 

Ekaj525

ADSM.ORG Member
That makes sense. Thank you for the info. We have a multi-server setup. So I can move to container pools and replicate.
 

RecoveryOne

ADSM.ORG Senior Member
So that leaves you with two options:
1 - have 2 SP servers in 2 different locations and use protect stgpool and node replication to keep both sites in sync. So if the primary server goes down, clients can do restores from the secondary server. If the outage is for an extended period, the secondary server can be changed as the primary to allow client backups. You can still do a 3rd copy to tape for legal requirements if necessary. Ideally from the secondary server to relieve the primary server from that workload.
2 - use traditional storage pool(s) with tape copy pool
What marclant is saying is 100% spot on.
I jumped the gun so to speak by moving to container storage pool from the legacy file pools. Some days I think it was the best thing ever. I backup the container's to tape, I backup more than IBM recommends to tape from the container's. Everyone knows that if we lost the main disk unit, it would be days, if not weeks to restore all the data back to a new disk unit before we could facilitate client restores. I'd like to say my situation was a bit unique, as I was able to leverage the better data reduction capabilities of the containers vs legacy to help me meet retention requirements, but it was a trade off for recovery in the event of a TSM failure.

And yes, follow the blueprints!
 

Advertise at ADSM.ORG

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

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

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: 18 18.4%
  • Keep using TSM for Spectrum Protect.

    Votes: 60 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 12 12.2%
  • Other (please comement)

    Votes: 8 8.2%

Forum statistics

Threads
31,716
Messages
135,198
Members
21,721
Latest member
abucci63
Top