Creating a second datacenter and datamover nodes

skarr24

Newcomer
Joined
Oct 17, 2017
Messages
4
Reaction score
0
Points
0
Hi

i am relatively new to tsm and would like to know how the process of adding a new datacenter node as well as a new datamover node works.
 
Hi

i am relatively new to tsm and would like to know how the process of adding a new datacenter node as well as a new datamover node works.

By saying "new data center node", I presume you are referring to a new TSM (server) instance. There are many data movers - NDMP, VM, etc. Which one?

Search the IBM website for guidance on the exact environment you want to create.

Communication between the two data centers will be via server-to-server wherein the primary site can transfer data to the secondary site effectively making the secondary site an extension. Setting this up is under any TSM Adminisrator guide.
 
So if i'm correct then i won't be able to set up 2 datacenters on a single server, i am trying to configure daily incremental backups as well as monthly backups, i have found some help eluding to the fact that i would have to create a new datamover node as well as a new datacenter node.
 
So if i'm correct then i won't be able to set up 2 datacenters on a single server, i am trying to configure daily incremental backups as well as monthly backups, i have found some help eluding to the fact that i would have to create a new datamover node as well as a new datacenter node.
Sorry, don’t think secondary nodes will be the way to go. Works fine for client based backup, but not vmware. Problem is that both your nodes (daily and monthly) will update/reset vmware’s change block tracking (CBT). So every time you run the montly, it will find that CBT makes no sense, do a full backup, and then reset the CBT. Next day, when you run the daily, it will find that CBT has been reset, it will do a full backup, and reset the CBT again. If it all goes to the same storage pool, dedup will probably handle most of the extra data, so storage will not neccessarily be an issue, but the time to required to do two full backups every month is probably too time consuming.
As far as I know, no one has come up with a way to handle this using TSM for VE in larger environments.
 
Sorry, don’t think secondary nodes will be the way to go. Works fine for client based backup, but not vmware. Problem is that both your nodes (daily and monthly) will update/reset vmware’s change block tracking (CBT). So every time you run the montly, it will find that CBT makes no sense, do a full backup, and then reset the CBT. Next day, when you run the daily, it will find that CBT has been reset, it will do a full backup, and reset the CBT again. If it all goes to the same storage pool, dedup will probably handle most of the extra data, so storage will not neccessarily be an issue, but the time to required to do two full backups every month is probably too time consuming.
As far as I know, no one has come up with a way to handle this using TSM for VE in larger environments.

This where you are wrong.

TSM is not like any other backup software - the concept of doing weekly or monthly is simply not there. TSM runs incremental forever and nothing gets reset.

You have to make a paradigm shift when using TSM.

https://www.ibm.com/support/knowledgecenter/en/SSERB6_8.1.0/ve.user/r_techchg_ve.html
https://www.ibm.com/support/knowled....ibm.itsm.ve.doc/c_ve_backup_incrforever.html
 
This where you are wrong.

TSM is not like any other backup software - the concept of doing weekly or monthly is simply not there. TSM runs incremental forever and nothing gets reset.

You have to make a paradigm shift when using TSM.

https://www.ibm.com/support/knowledgecenter/en/SSERB6_8.1.0/ve.user/r_techchg_ve.html
https://www.ibm.com/support/knowled....ibm.itsm.ve.doc/c_ve_backup_incrforever.html
When using TSM baclient, you’re absolutely right, it is incremental forever. TDPs also contains various incremental options. In these instances TSM is keeping track of the changes. However, when TSM for VE is used, TSM relies on VMware’s CBT to find what data blocks have changed since the last backup. And if two different datacenter nodes are being used, there will be no valid CBT data when switching between the nodes.
But I do agree, incremental forever is the best way to go, but there still are customer with rules and regulations that do demand long retention times. In most cases I have been able to resolve this with customers by running TSM for VE as the general protection, with retention of 30-90 days, and installing the baclient in the few vm’s that according to their regulations really do need very long retention.
 
No offence taken, I really do hope this works.
I must admit that I haven't even tried the multiple nodes with TSM for VE. My info was based on a thread 2-3 years ago, discussing TSM for VE, and the conclusion back then was:
"If you backup to a different nodename you will reset the CBT info. So you can do that monthly full backup to the different nodename, but when you switch back to the original, it will also require a full. So in essence you need to do 2 back to back fulls to get this done. I've been down this road".
(unfortunately I do not have a pointer to the thread, just made a clipping of the conclusion)
 
Back
Top