diff options
Diffstat (limited to 'doc/lziprecover.texi')
| -rw-r--r-- | doc/lziprecover.texi | 60 |
1 files changed, 53 insertions, 7 deletions
diff --git a/doc/lziprecover.texi b/doc/lziprecover.texi index 08d4312..85f0385 100644 --- a/doc/lziprecover.texi +++ b/doc/lziprecover.texi @@ -6,8 +6,8 @@ @finalout @c %**end of header -@set UPDATED 16 October 2014 -@set VERSION 1.17-pre1 +@set UPDATED 21 January 2015 +@set VERSION 1.17-rc1 @dircategory Data Compression @direntry @@ -37,6 +37,7 @@ This manual is for Lziprecover (version @value{VERSION}, @value{UPDATED}). @menu * Introduction:: Purpose and features of lziprecover * Invoking lziprecover:: Command line interface +* Data safety:: Protecting data from accidental loss * Repairing files:: Fixing bit-flip and similar errors * Merging files:: Fixing several damaged copies * File names:: Names of the files produced by lziprecover @@ -48,7 +49,7 @@ This manual is for Lziprecover (version @value{VERSION}, @value{UPDATED}). @end menu @sp 1 -Copyright @copyright{} 2009-2014 Antonio Diaz Diaz. +Copyright @copyright{} 2009-2015 Antonio Diaz Diaz. This manual is free documentation: you have unlimited permission to copy, distribute and modify it. @@ -281,6 +282,48 @@ invalid input file, 3 for an internal consistency error (eg, bug) which caused lziprecover to panic. +@node Data safety +@chapter Protecting data from accidental loss +@cindex data safety + +There are 3 main types of data corruption that may cause data loss: +single-byte errors, multi-byte errors (generally affecting a whole +sector in a block device), and total device failure. + +Lziprecover protects natively against single-byte errors +(@pxref{Repairing files}), as long as file integrity is checked +frequently enough that a second single-byte error does not develop in +the same member before the first one is repaired. + +Lziprecover also protects against multi-byte errors (@pxref{Merging +files}), if at least one backup copy of the file is made. + +The only remedy for total device failure is storing backup copies in +separate media. + +How does lzip compare with gzip and bzip2 with respect to data safety? +Lets suppose that you made a backup copy of your valuable scientific +data, compressed it, and stored two copies on separate media. Years +later you notice that both copies are corrupt. + +If you compressed with gzip and both copies suffer any damage in the +data stream, even if it is just one altered bit, the original data can't +be recovered. + +If you used bzip2, and if the file is large enough to contain more than +one compressed data block (usually larger than 900 kB), and if no block +is damaged in both files, then the data can be manually recovered by +splitting the files with bzip2recover, verifying every block and then +copying the right blocks in the right order in another file. + +But if you used lzip, the data can be automatically recovered as long as +no byte is damaged in both files. + +Note that each error in a bzip2 file makes a whole block unusable, but +each error in a lzip file only affects the damaged bytes, making it +possible to recover a file with thousands of errors. + + @node Repairing files @chapter Repairing files @cindex repairing files @@ -288,12 +331,15 @@ caused lziprecover to panic. Lziprecover can repair perfectly most files with small errors (up to one single-byte error per member), without the need of any extra redundance at all. If the reparation is successful, the repaired file will be -identical bit for bit to the original. +identical bit for bit to the original. This makes lzip files resistant +to bit-flip, one of the most common forms of data corruption. The error may be located anywhere in the file except in the header (first 6 bytes of each member) or in the @samp{Member size} field of the -trailer (last 8 bytes of each member). This makes lzip files resistant -to bit-flip, one of the most common forms of data corruption. +trailer (last 8 bytes of each member). If the error is in the header it +can be easily repaired with a text editor like GNU Moe (@pxref{File +format}). If the error is in the member size, it is enough to ignore the +message about @samp{bad member size} when decompressing. Bit-flip happens when one bit in the file is changed from 0 to 1 or vice versa. It may be caused by bad RAM or even by natural radiation. I have @@ -641,7 +687,7 @@ for all eternity, if not longer. If you find a bug in lziprecover, please send electronic mail to @email{lzip-bug@@nongnu.org}. Include the version number, which you can -find by running @w{@samp{lziprecover --version}}. +find by running @w{@code{lziprecover --version}}. @node Concept index |