ldmwndletsm
ADSM.ORG Senior Member
- Joined
- Oct 30, 2019
- Messages
- 232
- Reaction score
- 5
- Points
- 0
This might be the wrong category to post this thread?
I'm new to TSM, but ...
1. Does TSM allow you to control how many save streams can be backed up to a single drive and/or how many streams a given client (or node) can send to the TSM server simultaneously?
For example, if I have a single stanza (one node) for a client, and it has 100 file systems, does it actually walk each of these one at a time, backs it up (whatever has changed, natch) and then moves on to the next file system and so on and so forth? Or does it instead parallelize the operation wherein multiple data chunks from different file systems (collocation notwitstanding, of course) are wrapped together (interleaved) and then sent to the drive?
2. Does client side compression change this behavior?
3. How can you adjust these values?
For example, I see 'maxprocess' for the 'backup stgpool' command, but can this be set for when the backups actually run from the client, e.g. if you were writing directly to tape?
I have to say that we're planning to back up to disk and then move that to tape. It will not sit on disk very long, however, (maybe one day), and we will not be using a disk cache. Maybe it's moot then since it will go to disk first? But would it be more efficient to have multiple file systems backing up from the client to disk at the same time?
My experience is with EMC NetWorker, and we wrote directly to tape. We could increase the number of parallel streams (parallelism) for a given drive, which could push their speeds up so they were optimally streaming, but after a point, it maxes out, of course. So if the parallelism of the drive was set to 6, then once 6 file spaces are writing to it (not necessarily from the same client) then any additional file spaces that come in to the server are then sent to another drive and so and so forth. We could also increase the number of parallel streams sent from the client, wherein we might have, say, 50 file systems, and we might set the client paralleism to 8 so it could send up to eight streams (working on 8 of the 50 file systems simulataneously while the remaining 42 are pending), and this would speed up the backup times as apposed to setting it to a lower value, even 1, wherein it walks one file system at a time, taking all night. Of course, the data is interleaved on the tape, and the higher the parallelism, the more multiplexed the data is and the loner the recovery times since there's more data to de-multiplex. Lower parallelism yields slower backup times but faster recovery times whereas higher parallelism produces faster backup times but slower recovery times. Something like that. Of course, we weren't dealing with collocation or anything like that.
I'm new to TSM, but ...
1. Does TSM allow you to control how many save streams can be backed up to a single drive and/or how many streams a given client (or node) can send to the TSM server simultaneously?
For example, if I have a single stanza (one node) for a client, and it has 100 file systems, does it actually walk each of these one at a time, backs it up (whatever has changed, natch) and then moves on to the next file system and so on and so forth? Or does it instead parallelize the operation wherein multiple data chunks from different file systems (collocation notwitstanding, of course) are wrapped together (interleaved) and then sent to the drive?
2. Does client side compression change this behavior?
3. How can you adjust these values?
For example, I see 'maxprocess' for the 'backup stgpool' command, but can this be set for when the backups actually run from the client, e.g. if you were writing directly to tape?
I have to say that we're planning to back up to disk and then move that to tape. It will not sit on disk very long, however, (maybe one day), and we will not be using a disk cache. Maybe it's moot then since it will go to disk first? But would it be more efficient to have multiple file systems backing up from the client to disk at the same time?
My experience is with EMC NetWorker, and we wrote directly to tape. We could increase the number of parallel streams (parallelism) for a given drive, which could push their speeds up so they were optimally streaming, but after a point, it maxes out, of course. So if the parallelism of the drive was set to 6, then once 6 file spaces are writing to it (not necessarily from the same client) then any additional file spaces that come in to the server are then sent to another drive and so and so forth. We could also increase the number of parallel streams sent from the client, wherein we might have, say, 50 file systems, and we might set the client paralleism to 8 so it could send up to eight streams (working on 8 of the 50 file systems simulataneously while the remaining 42 are pending), and this would speed up the backup times as apposed to setting it to a lower value, even 1, wherein it walks one file system at a time, taking all night. Of course, the data is interleaved on the tape, and the higher the parallelism, the more multiplexed the data is and the loner the recovery times since there's more data to de-multiplex. Lower parallelism yields slower backup times but faster recovery times whereas higher parallelism produces faster backup times but slower recovery times. Something like that. Of course, we weren't dealing with collocation or anything like that.
