bup-tag(1) [debian man page]

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

NAME

       bup-tag - tag a commit in the bup repository

SYNOPSIS

       bup tag

       bup tag <tag name> <committish>

       bup tag -d <tag name>

DESCRIPTION

       bup tag lists, creates or deletes a tag in the bup repository.

       A tag is an easy way to retreive a specific commit.  It can be used to mark a specific backup for easier retrieval later.

       When  called without any arguments, the command lists all tags that can be found in the repository.  When called with a tag name and a com-
       mit ID or ref name, it creates a new tag with the given name, if it doesn't already exist, that points to the commit given  in  the  second
       argument.  When called with '-d' and a tag name, it removes the given tag, if it exists.

       bup  exposes  the  contents  of	backups with current tags, via any command that lists or shows backups.  They can be found under the /.tag
       directory.  For example, the 'ftp' command will show the tag named 'tag1' under /.tag/tag1.

       Tags are also exposed under the branches from which they can be reached.  For example, if you create a tag named 'important'  under  branch
       'computerX',  you  will	also be able to retrieve the contents of the backup that was tagged under /computerX/important.  This is done as a
       convenience, and should the branch 'computerX' be deleted, the contents of the tagged backup will be available through  /.tag/important	as
       long as the tag is not deleted.

OPTIONS

       -d, --delete
	      delete a tag

EXAMPLE

	      $ bup tag new-puppet-version hostx-backup

	      $ bup tag
	      new-puppet-version

	      $ bup ftp "ls /.tag/new-puppet-version"
	      files..

	      $ bup tag -d new-puppet-version

SEE ALSO

       bup-save(1), bup-split(1), bup-ftp(1), bup-fuse(1), bup-web(1)

BUP

       Part of the bup(1) suite.

AUTHORS

       Gabriel Filion <lelutin@gmail.com>.

Bup unknown-																bup-tag(1)

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)