Re: backup compress on the fly
On Mon, 3 Oct 2005, Mike McCarty wrote:
> > most "large capacity" drives uses ECC which does support error correction
> > at least in the firmware and tape controllers to read the data
> > off the tape ..
> So has every hard disc. But we still get disc errors, don't we?
but nobody said ecc will fix/prevent disk error ...
ecc can only fix certain error conditions
- detect and fix 1 bit error
- detect and fix 2 bit error
- detect 3 bit errors
or some silly sequences depending on the number of bits
in each of the ecc field and what the original data
is that it is trying to detect and fix
any othe eerror ... retry a few times and than flag the sector
was whacky and tell the os "help"
- a smart disk controller will than rewrite that
sector in a new location on disk when its told
by the os to write it someplace else
> > there's an asumption that you only have 1 compressed file
> > on the tape
> If you read what I wrote carefully, you'll see that I stated that "if
> the whole image on tape is a compressed one" as opposed to "if the
> image on tape contains compressed files". In this particular thread,
> the context specifically mentioned as a possibility using tar with
> the "z" compression option specified, which results in a single tar
> image which is then compressed, or possibly piping the output from
> cpio into gzip.
like i said.. there can be 2 or more *.tgz files .. each
appended after the other previous one ...
and each of those *.tgz can have other *.tgz files inside
write-tue-backup.tgz which is appended after monday
write-wed-backup.tgz which is appended after tue
if one day's backup is bad ... so what.. the other
files ( sectors on the tape ) are still readable