.\" Automatically generated by Pandoc 3.1.3
.\"
.\" Define V font for inline verbatim, using C font in formats
.\" that render this, and otherwise B font.
.ie "\f[CB]x\f[]"x" \{\
. ftr V B
. ftr VI BI
. ftr VB B
. ftr VBI BI
.\}
.el \{\
. ftr V CR
. ftr VI CI
. ftr VB CB
. ftr VBI CBI
.\}
.TH "bup-damage" "1" "0.33.3" "Bup 0.33.3" ""
.hy
.SH NAME
.PP
bup-damage - randomly destroy blocks of a file
.SH SYNOPSIS
.PP
bup damage [-n count] [-s maxsize] [--percent pct] [-S seed] [--equal]
<filenames\&...>
.SH DESCRIPTION
.PP
Use \f[V]bup damage\f[R] to deliberately destroy blocks in a
\f[V].pack\f[R] or \f[V].idx\f[R] file (from
\f[V].bup/objects/pack\f[R]) to test the recovery features of
\f[V]bup-fsck\f[R](1) or other programs.
.PP
\f[I]THIS PROGRAM IS EXTREMELY DANGEROUS AND WILL DESTROY YOUR DATA\f[R]
.PP
\f[V]bup damage\f[R] is primarily useful for automated or manual tests
of data recovery tools, to reassure yourself that the tools actually
work.
.PP
Note that the details of the current behavior may change (particularly
the details not documented here).
For example the moment, the damage is strictly probabilistic, and so may
or may not actually alter any given block.
With a block size of 1, there should be a 1/256 chance that the block
won\[cq]t actually change.
This behavior may change.
.SH OPTIONS
.TP
-n, --num=\f[I]numblocks\f[R]
the number of separate blocks to damage in each file (default 10).
Note that it\[cq]s possible for more than one damaged segment to fall in
the same \f[V]bup-fsck\f[R](1) recovery block, so you might not damage
as many recovery blocks as you expect.
If this is a problem, use \f[V]--equal\f[R].
.TP
-s, --size=\f[I]maxblocksize\f[R]
the maximum size, in bytes, of each damaged block (default 1 unless
\f[V]--percent\f[R] is specified).
Note that because of the way \f[V]bup-fsck\f[R](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\[cq]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.
.TP
--percent=\f[I]maxblockpercent\f[R]
the maximum size, in percent of the original file, of each damaged
block.
If both \f[V]--size\f[R] and \f[V]--percent\f[R] 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 \f[V]git-fsck\f[R](1) recovery blocks.
.TP
-S, --seed=\f[I]randomseed\f[R]
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 time).
.TP
--equal
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 \f[V]git-fsck\f[R](1)
recovery block.
(This is also guaranteed if you use \f[V]-s 1\f[R].)
.SH EXAMPLES
.IP
.nf
\f[C]
# make a backup in case things go horribly wrong
cp -pPR \[ti]/.bup/objects/pack \[ti]/bup-packs.bak

# generate recovery blocks for all packs
bup fsck -g

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

# recover from the damage
bup fsck -r
\f[R]
.fi
.SH SEE ALSO
.PP
\f[V]bup-fsck\f[R](1), \f[V]par2\f[R](1)
.SH BUP
.PP
Part of the \f[V]bup\f[R](1) suite.
.SH AUTHORS
Avery Pennarun <apenwarr@gmail.com>.