Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

bup-fsck(1) [debian man page]

bup-fsck(1)						      General Commands Manual						       bup-fsck(1)

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 dam- aged 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>. Bup unknown- bup-fsck(1)

Check Out this Related Man Page

bup-random(1)						      General Commands Manual						     bup-random(1)

NAME
bup-random - generate a stream of random output SYNOPSIS
bup random [-S seed] [-fv] DESCRIPTION
bup random produces a stream of pseudorandom output bytes to stdout. Note: the bytes are not generated using a cryptographic algorithm and should never be used for security. Note that the stream of random bytes will be identical every time bup random is run, unless you provide a different seed value. This is intentional: the purpose of this program is to be able to run repeatable tests on large amounts of data, so we want identical data every time. bup random generates about 240 megabytes per second on a modern test system (Intel Core2), which is faster than you could achieve by read- ing data from most disks. Thus, it can be helpful when running microbenchmarks. OPTIONS
the number of bytes of data to generate. Can be used with the suffices k, M, or G to indicate kilobytes, megabytes, or gigabytes, respectively. -S, --seed=seed use the given value to seed the pseudorandom number generator. The generated output stream will be identical for every stream seeded with the same value. The default seed is 1. A seed value of 0 is equivalent to 1. -f, --force generate output even if stdout is a tty. (Generating random data to a tty is generally considered ill-advised, but you can do if you really want.) -v, --verbose print a progress message showing the number of bytes that has been output so far. EXAMPLES
$ bup random 1k | sha1sum 2108c55d0a2687c8dacf9192677c58437a55db71 - $ bup random -S1 1k | sha1sum 2108c55d0a2687c8dacf9192677c58437a55db71 - $ bup random -S2 1k | sha1sum f71acb90e135d98dad7efc136e8d2cc30573e71a - $ time bup random 1G >/dev/null Random: 1024 Mbytes, done. real 0m4.261s user 0m4.048s sys 0m0.172s $ bup random 1G | bup split -t --bench Random: 1024 Mbytes, done. bup: 1048576.00kbytes in 18.59 secs = 56417.78 kbytes/sec 1092599b9c7b2909652ef1e6edac0796bfbfc573 BUP
Part of the bup(1) suite. AUTHORS
Avery Pennarun <apenwarr@gmail.com>. Bup unknown- bup-random(1)
Man Page