Provided by: bup-doc_0.29-3_all bug


       bup-damage - randomly destroy blocks of a file


       bup damage [-n count] [-s maxsize] [--percent pct] [-S seed] [--equal] <filenames...>


       Use   bup damage   to   deliberately  destroy  blocks  in  a  .pack  or  .idx  file  (from
       .bup/objects/pack) to test the recovery features of bup-fsck(1) or other programs.


       bup damage is primarily useful for automated or manual tests of data  recovery  tools,  to
       reassure yourself that the tools actually work.


       -n, --num=numblocks
              the  number of separate blocks to damage in each file (default 10).  Note that it's
              possible for more than one damaged segment to fall in the same bup-fsck(1) recovery
              block, so you might not damage as many recovery blocks as you expect.  If this is a
              problem, use --equal.

       -s, --size=maxblocksize
              the maximum size, in bytes, of each damaged block (default 1  unless  --percent  is
              specified).   Note  that  because  of the way bup-fsck(1) works, a multi-byte block
              could fall on the boundary between two  recovery  blocks,  and  thus  damaging  two
              separate  recovery  blocks.  In small files, it's also possible for a damaged block
              to be larger than a recovery block.  If these issues might be a problem, you should
              use the default damage size of one byte.

              the  maximum size, in percent of the original file, of each damaged block.  If both
              --size and --percent are given, the maximum block size is the minimum  of  the  two
              restrictions.  You can use this to ensure that a given block will never damage more
              than one or two git-fsck(1) recovery blocks.

       -S, --seed=randomseed
              seed the random number generator with the given value.  If  you  use  this  option,
              your tests will be repeatable, since the damaged block offsets, sizes, and contents
              will be the same every time.  By default, the random numbers  are  different  every
              time (so you can run tests in a loop and repeatedly test with different damage each

              instead of choosing random offsets for each damaged block, space the blocks equally
              throughout  the  file,  starting at offset 0.  If you also choose a correct maximum
              block size, this can guarantee that any given damage block never damages more  than
              one git-fsck(1) recovery block.  (This is also guaranteed if you use -s 1.)


              # make a backup in case things go horribly wrong
              cp -pPR ~/.bup/objects/pack ~/bup-packs.bak

              # generate recovery blocks for all packs
              bup fsck -g

              # deliberately damage the packs
              bup damage -n 10 -s 1 -S 0 ~/.bup/objects/pack/*.{pack,idx}

              # recover from the damage
              bup fsck -r


       bup-fsck(1), par2(1)


       Part of the bup(1) suite.


       Avery Pennarun <>.