My apologies to Claus-Justus and Jens: the attribution was incorrect in
the previous reply (because I accidentally hit the send key too early ;-)
On 11 Nov 1997, Claus-Justus Heine wrote:
> "Jens B. Jorgensen" <[EMAIL PROTECTED]> writes:
>
> > Claus-Justus Heine wrote:
> > >
...
> > > So does t
On 11 Nov 1997, Claus-Justus Heine wrote:
> "Jens B. Jorgensen" <[EMAIL PROTECTED]> writes:
> > Claus-Justus Heine wrote:
...
> > So does this mean that "SETMARKS" are kind of "second level" file
> > marks? I'm just curious what these things are. There is no real need
> > for me to know it, I'm ju
"Jens B. Jorgensen" <[EMAIL PROTECTED]> writes:
> Claus-Justus Heine wrote:
> >
> > > > Aren't these marks simply "file marks"? (just asking, I know that
> > > > there are thos MTFSS/BSS/WSM tape operations, are these effectively
> > > > different from the MTFSF/BSF/WEOF operations?)
> > >
> > >
Claus-Justus Heine wrote:
>
> "Jens B. Jorgensen" <[EMAIL PROTECTED]> writes:
>
> > Claus-Justus Heine wrote:
> > >
> > > > > Aren't these marks simply "file marks"? (just asking, I know that
> > > > > there are thos MTFSS/BSS/WSM tape operations, are these effectively
> > > > > different from th
Claus-Justus Heine wrote:
>
> > > Aren't these marks simply "file marks"? (just asking, I know that
> > > there are thos MTFSS/BSS/WSM tape operations, are these effectively
> > > different from the MTFSF/BSF/WEOF operations?)
> >
> > Yeah, it's a different beast. Trust, me, I can tell mt to find
> > Aren't these marks simply "file marks"? (just asking, I know that
> > there are thos MTFSS/BSS/WSM tape operations, are these effectively
> > different from the MTFSF/BSF/WEOF operations?)
>
> Yeah, it's a different beast. Trust, me, I can tell mt to find a mark
> and it'll
> skip over all kin
Claus-Justus Heine wrote:
>
> > Now all you need is a good script which will do a full dump and then put
> > incrementals after it on the same tape, right? Of course! I'm sending you
> > my perl backup script (which backs up *multiple* machines) via direct email
> > anyone else who's interested ca
> Now all you need is a good script which will do a full dump and then put
> incrementals after it on the same tape, right? Of course! I'm sending you
> my perl backup script (which backs up *multiple* machines) via direct email
> anyone else who's interested can have it to. My backup script has th
> 3. In setting the volume size, how can I correctly bring the compression
> factor of using zftape into account?
This is difficult. Generally, there is no easy way to predict any
compressors efficiency unless one knows which kind of data is going to
be compressed.
When compressing ordinary files
Johann Spies wrote:
>
> Thank you for the reactions to my enquiry about efficient backup programs.
>
> I have overlooked dump and am trying it out now. What I do not seem to
> get right is setting the volume size. While using dump like this:
> dump 0uf /dev/nzqft0 / it does a backup, but sa
Thank you for the reactions to my enquiry about efficient backup programs.
I have overlooked dump and am trying it out now. What I do not seem to
get right is setting the volume size. While using dump like this:
dump 0uf /dev/nzqft0 / it does a backup, but says it requires 11
tapes asking ev
11 matches
Mail list logo
