.TH bup\-fsck 1 "2013\-12\-16" "Bup debian/0.25\-1"
.SH NAME
.PP
bup\-fsck \- verify or repair a bup repository
.SH SYNOPSIS
.PP
bup fsck [\-r][\-g] [\-v][\\\-\-quick] [\-j
\f[I]jobs\f[]][\\\-\-par2\-ok] [\-\-disable\-par2][filenames...]
.SH DESCRIPTION
.PP
\f[C]bup\ fsck\f[] is a tool for validating bup repositories in the same
way that \f[C]git\ fsck\f[] validates git repositories.
.PP
It can also generate and/or use "recovery blocks" using the
\f[C]par2\f[](1) tool (if you have it installed).
This allows you to recover from damaged blocks covering up to 5% of your
\f[C]\&.pack\f[] files.
.PP
In a normal backup system, damaged blocks are less important, because
there tends to be enough data duplicated between backup sets that a
single damaged backup set is non\-critical.
In a deduplicating backup system like bup, however, no block is ever
stored more than once, even if it is used in every single backup.
If that block were to be unrecoverable, \f[I]all\f[] your backup sets
would be damaged at once.
Thus, it\[aq]s important to be able to verify the integrity of your
backups and recover from disk errors if they occur.
.PP
\f[I]WARNING\f[]: bup fsck\[aq]s recovery features are not available
unless you have the free \f[C]par2\f[](1) package installed on your bup
server.
.PP
\f[I]WARNING\f[]: bup fsck obviously cannot recover from a complete disk
failure.
If your backups are important, you need to carefully consider redundancy
(such as using RAID for multi\-disk redundancy, or making off\-site
backups for site redundancy).
.SH OPTIONS
.TP
.B \-r, \-\-repair
attempt to repair any damaged packs using existing recovery blocks.
(Requires \f[C]par2\f[](1).)
.RS
.RE
.TP
.B \-g, \-\-generate
generate recovery blocks for any packs that don\[aq]t already have them.
(Requires \f[C]par2\f[](1).)
.RS
.RE
.TP
.B \-v, \-\-verbose
increase verbosity (can be used more than once).
.RS
.RE
.TP
.B \-\-quick
don\[aq]t run a full \f[C]git\ verify\-pack\f[] on each pack file;
instead just check the final checksum.
This can cause a significant speedup with no obvious decrease in
reliability.
However, you may want to avoid this option if you\[aq]re paranoid.
Has no effect on packs that already have recovery information.
.RS
.RE
.TP
.B \-j, \-\-jobs=\f[I]numjobs\f[]
maximum number of pack verifications to run at a time.
The optimal value for this option depends how fast your CPU can verify
packs vs.
your disk throughput.
If you run too many jobs at once, your disk will get saturated by
seeking back and forth between files and performance will actually
decrease, even if \f[I]numjobs\f[] is less than the number of CPU cores
on your system.
You can experiment with this option to find the optimal value.
.RS
.RE
.TP
.B \-\-par2\-ok
immediately return 0 if \f[C]par2\f[](1) is installed and working, or 1
otherwise.
Do not actually check anything.
.RS
.RE
.TP
.B \-\-disable\-par2
pretend that \f[C]par2\f[](1) is not installed, and ignore all recovery
blocks.
.RS
.RE
.SH EXAMPLE
.IP
.nf
\f[C]
#\ generate\ recovery\ blocks\ for\ all\ packs\ that\ don\[aq]t
#\ have\ them
bup\ fsck\ \-g

#\ generate\ recovery\ blocks\ for\ a\ particular\ pack
bup\ fsck\ \-g\ ~/.bup/objects/pack/153a1420cb1c8*.pack

#\ check\ all\ packs\ for\ correctness\ (can\ be\ very\ slow!)
bup\ fsck

#\ check\ all\ packs\ for\ correctness\ and\ recover\ any
#\ damaged\ ones
bup\ fsck\ \-r

#\ check\ a\ particular\ pack\ for\ correctness\ and\ recover
#\ it\ if\ damaged
bup\ fsck\ \-r\ ~/.bup/objects/pack/153a1420cb1c8*.pack

#\ check\ if\ recovery\ blocks\ are\ available\ on\ this\ system
if\ bup\ fsck\ \-\-par2\-ok;\ then
\ \ \ \ echo\ "par2\ is\ ok"
fi
\f[]
.fi
.SH SEE ALSO
.PP
\f[C]bup\-damage\f[](1), \f[C]fsck\f[](1), \f[C]git\-fsck\f[](1)
.SH BUP
.PP
Part of the \f[C]bup\f[](1) suite.
.SH AUTHORS
Avery Pennarun <apenwarr@gmail.com>.