Advise for primary STG definition

Matti

Active Newcomer
Joined
Aug 26, 2014
Messages
9
Reaction score
0
Points
0
I could not quite decide where to put my questions

We built up a new TSM Server from scratch. We have got two primary stg pools on two different iscsi-targets. I just have one big copygroup and I want to use both primary storages for pretty much all of my backup nodes.

So I planned, to run it like this:

* primary-stg-one (10TB) ist the standard copy-destination for all my backup-nodes
* The next stg is primary-stg-two (25TB)
* highmig is 75% to leave some space for any occurring issues
* lowmig is 15% might even be 0%

----
Now all backups are being sent into primary-stg-one and someday will then be migrated to primary-stg-two.

If all data from prim-stg-one is beeing backed up to tape, while migration is beeing processed, will this lead to any problems?

The maintenance script I created will:

backup prim-stg-one to tape
backup prim-stg-two to tape

I guess this will slow down the server severely, if data is migrated from the storagpool that is beeing backed up at the same time. There will be up to 7TB being migrated all at once, which will take some time.
---

Secondly I am not sure if my approach is the right one, integrating the two stgs, fundamentally.


Thank you very much for your opinions
 
I would approach this differently.

If the nodes have different purposes (SQL, Oracle, File data, Web, etc) I would create multiple primary storage pools and assign node classifications on each primary storage pool. Say group DB backups into one, File data and OS backups on another, and APPS in another, etc. This leads to a faster backup.

The sizing of the primary storage pools will be determined by the amount of data being backed up nightly by the collective node groups.
 
Last edited:
I would approach this differently.

If the nodes have different purposes (SQL, Oracle, File data, Web, etc) I would create multiple primary storage pools and assign node classifications on each primary storage pool. Say group DB backups into one, File data and OS backups on another, and APPS in another, etc. This leads to a faster backup.

The sizing of the primary storage pools will be determined by the amount of data being backed up nightly by the collective node groups.

At the moment we are running about 50 Nodes with mostly filebackups. My concern is, that it will be consuming a lot of time to constantly monitor and adapt the different pool sizes, as the overall space is limited.

Your reply is, what I expected - I made it too easy.

So thanks for your approach. I will try calculating this through

tyvm
 
Last edited by a moderator:
Back
Top