ldmwndletsm
ADSM.ORG Senior Member
- Joined
- Oct 30, 2019
- Messages
- 232
- Reaction score
- 5
- Points
- 0
We're under a very tight deadline, and we need to decide very soon which of the following two methods to use to back up a single client with a lot of file systems and data on it. Knowledge of proxies is all new to me, so I may have some terminology wrong here. This is on Linux, running Spectrum Protect 8.1.3. This stems from another thread(https://adsm.org/forum/index.php?threads/can-you-move-a-file-space-between-nodes.33041/) BUT I thought I'd make a new post for this.
We do not want to distribute the backups to other machines on the network as with a more traditional proxy scenario. This will all be done by the one client. We are not looking to gain any parallelism advantage here over a single node solution since either can satisfy that using the proper resourceutil setting. Instead, we want to support simultaneous schedules.
Two proposed methods:
1. Two independent nodes using two stanzas (same client)
OR:
2. Two agent nodes (also two stanzas and same client) sharing one target node.
We have two collections of data on this system, so we'll be using two different management classes and storage pools, etc. because we want their data separated to different tapes, and there are different polices for the data so we can't rely solely on collocation. Moreover, while a single node solution *could* work, we instead want to manage these backups with two different schedules so we need two nodes, and the schedule startup window is very unpredictable due to the fact that the larger collection of data (managed by node 2) has a large quantity of large file systems that could sometimes take over a day each to complete whereas the smaller collection (managed by node 1) can be done in a single night. As a result, there could frequently be overlap.
Either method allows us to run concurrent schedules (two dsmcad processes), but the second solution does have the benefit in that all the file spaces will share the same (target) node on the server so anything can be restored from just that one node. However, the first solution is simpler to set up, and knowing which file system is on which node will be quite simple as all the large file spaces to be backed up by node 2 are all consistently named, and the data is all under the same classification, so we don't consider this an imposition.
Does anyone know any other compelling reason to use solution 2?
We have already set things up based on the first method, but we could define a third (virtual) target node on the server and do the proxy witchcraft and change things to use method 2. However, any data already backed up to node 1 or 2 would need to be re-backed up if we switched to method 2 since file spaces cannot be moved between nodes, correct? We have not backed up that much data yet, but time is running out. Proxies are all new to me in just the last couple of days so I don't know how much of an impact implementing solution 2 would have on our existing configuration for the two management classes, policy domains, storage pools, etc.
We do not want to distribute the backups to other machines on the network as with a more traditional proxy scenario. This will all be done by the one client. We are not looking to gain any parallelism advantage here over a single node solution since either can satisfy that using the proper resourceutil setting. Instead, we want to support simultaneous schedules.
Two proposed methods:
1. Two independent nodes using two stanzas (same client)
OR:
2. Two agent nodes (also two stanzas and same client) sharing one target node.
We have two collections of data on this system, so we'll be using two different management classes and storage pools, etc. because we want their data separated to different tapes, and there are different polices for the data so we can't rely solely on collocation. Moreover, while a single node solution *could* work, we instead want to manage these backups with two different schedules so we need two nodes, and the schedule startup window is very unpredictable due to the fact that the larger collection of data (managed by node 2) has a large quantity of large file systems that could sometimes take over a day each to complete whereas the smaller collection (managed by node 1) can be done in a single night. As a result, there could frequently be overlap.
Either method allows us to run concurrent schedules (two dsmcad processes), but the second solution does have the benefit in that all the file spaces will share the same (target) node on the server so anything can be restored from just that one node. However, the first solution is simpler to set up, and knowing which file system is on which node will be quite simple as all the large file spaces to be backed up by node 2 are all consistently named, and the data is all under the same classification, so we don't consider this an imposition.
Does anyone know any other compelling reason to use solution 2?
We have already set things up based on the first method, but we could define a third (virtual) target node on the server and do the proxy witchcraft and change things to use method 2. However, any data already backed up to node 1 or 2 would need to be re-backed up if we switched to method 2 since file spaces cannot be moved between nodes, correct? We have not backed up that much data yet, but time is running out. Proxies are all new to me in just the last couple of days so I don't know how much of an impact implementing solution 2 would have on our existing configuration for the two management classes, policy domains, storage pools, etc.
