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 join. All other bup operations are up to you -- consider
bup fsck --generate in a cron job to generate recovery blocks,
for example; or clone bup's git repository to further back it up.
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, or "shared" which allows every clone of the repository to access the encrypted data (use with caution).
Note that additional gpg keys can be given access to a remote by running enableremote with the new key id. See encryption.
buprepo- Required. This is passed to
--remoteto use to store data. To create the repository,
bup initwill be run. Example: "buprepo=example.com:/big/mybup" or "buprepo=/big/mybup" (To use the default
~/.buprepository 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.
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.