NAME

       bup-fsck - verify or repair a bup repository

SYNOPSIS

       bup fsck [-r][-g] [-v][\--quick] [-j jobs][\--par2-ok] [--disable-par2][filenames...]

DESCRIPTION

       bup fsck is a tool for validating bup repositories in the same way that git fsck validates
       git repositories.

       It can also generate and/or use "recovery blocks" using the par2(1) tool (if you  have  it
       installed).   This  allows  you  to  recover from damaged blocks covering up to 5% of your
       .pack files.

       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, all your backup sets would be damaged at once.  Thus, it's important to  be
       able to verify the integrity of your backups and recover from disk errors if they occur.

       WARNING:  bup  fsck's recovery features are not available unless you have the free par2(1)
       package installed on your bup server.

       WARNING: 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).

OPTIONS

       -r, --repair
              attempt to repair any damaged packs  using  existing  recovery  blocks.   (Requires
              par2(1).)

       -g, --generate
              generate  recovery  blocks  for  any packs that don't already have them.  (Requires
              par2(1).)

       -v, --verbose
              increase verbosity (can be used more than once).

       --quick
              don't run a full git verify-pack 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're  paranoid.   Has
              no effect on packs that already have recovery information.

       -j, --jobs=numjobs
              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 numjobs is less
              than  the  number of CPU cores on your system.  You can experiment with this option
              to find the optimal value.

       --par2-ok
              immediately return 0 if par2(1) is installed and working, or 1 otherwise.   Do  not
              actually check anything.

       --disable-par2
              pretend that par2(1) is not installed, and ignore all recovery blocks.

EXAMPLE

              # generate recovery blocks for all packs that don'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

SEE ALSO

       bup-damage(1), fsck(1), git-fsck(1)

BUP

       Part of the bup(1) suite.

AUTHORS

       Avery Pennarun <apenwarr@gmail.com>.