This special remote type stores file contents in a bup repository. By using git-annex in the front-end, and bup as a remote, you get an easy git-style interface to large files, and easy backups of the file contents using git.
This is particularly well suited to collaboration on projects involving large files, since both the git-annex and bup repositories can be accessed like any other git repository.
See using bup for usage examples.
Each individual key is stored in a bup remote using bup split
, with
a git branch named the same as the key name. Content is retrieved from
bup using bup join
. All other bup operations are up to you -- consider
running bup fsck --generate
in a cron job to generate recovery blocks,
for example; or clone bup's git repository to further back it up.
configuration
These parameters can be passed to git annex initremote
to configure bup:
encryption
- Required. Either "none" to disable encryption of content stored in bup (ssh will still be used to transport it securely), or a value that can be looked up (using gpg -k) to find a gpg encryption key that will be given access to the remote. Note that additional gpg keys can be given access to a remote by rerunning initremote with the new key id. See encryption.buprepo
- Required. This is passed tobup
as the--remote
to use to store data. To create the repository,bup init
will be run. Example: "buprepo=example.com:/big/mybup" or "buprepo=/big/mybup" (To use the default~/.bup
repository on the local host, specify "buprepo=")
Options to pass to bup split
when sending content to bup can also
be specified, by using git config annex.bup-split-options
. This
can be used to, for example, limit its bandwidth.
notes
git-annex-shell does not support bup, due to the wacky way that bup starts its server. So, to use bup, you need full shell access to the server.