I don't know if I'm missing something, but why not use the same
storage set if you use the method below. I do that, multiple scripts
using the same storage set but for tapes. I can't see why you
couldn't do that in this situation.
>I spoke with dantz about Ben's idea.
>I think they were a bit impressed by it and it sounds
>like they had thought of that before. It is not a tested or
>supported solution and was suggested I not use the
>method. They said there is a problem with the verification
>process when partitioning in this way. However, one
>can turn verification off. My problem with this solution
>is that I have more than one script thus more than one
>backup set file. I think this would mean that, if I started a back-up
>script on the first partition, and this partition had, lets say, 4 other
>back-up sets on it, and the first script used the entire space of the
>first volume, then all there would be on the first volume is just
>the small beginning file for the rest of the scripts. Is this bad?...
>I don't know. If retrospect would automatically switch to the next
>empty partition in all the scripts, and if, when restoring, retrospect
>would automatically read at the appropriate mounted volume then
>I think it might be O.K. ( a bit jumbled, but it might work )
>Anyway, I did suggest to Dantz that they incorporate a similiar
>method to logging systems on a Unix or Linux machine. When
>a log gets to be over a certain size then the code starts a new file
>called <the file name>.1. I think this would be such a great feature.
>I haven't decided if I am going to try this or if I will just give
>in and go to tape. ( I usually do not do things the easy way :-)
>[EMAIL PROTECTED] wrote:
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.