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 :-)
Thanks  ben.


Just a thought- as I understand the problem, you are trying to backup to a
hard drive rather than to tape of removable right? and the file that is
getting to be too big is the file that Retrospect is writing, right? So
here's possible workaround that I haven't tried, but it makes sense so it
might work:

Try partitioning the drive into segments <2GB, and then define all of the
partitions within Retrospect as members of the backup set. If my
assumptions about the way Retrospect works are correct, then it will fill
up each one in turn and the files will not get over the 2GB limit imposed
by ASIP.

As I said, I haven't tried this, so it's really a guess. Does anyone see
any reason why this wouldn't work?

-- Donovan D. Brooke
Systems Administrator/
Assc. Art Director
Epsen Hillmer Graphics

Reply via email to