blob: 950b64e9c019c65675a93770ac1b1d5791995f90 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
This special remote type stores file contents in a
[bup](http://github.com/apenwarr/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.
See [[walkthrough/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,
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.
* `remote` - Required. This is passed to `bup` as the `--remote`
to use to store data. `bup init` will be run to create the
repository. Example: "remote=example.com:/big/mybup"
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.
## data security
When encryption=none, there is **no** protection against your data being read
by anyone who can access the bup remote. However, bup does transfer data
using ssh, and if you trust the security of the remote, that's fine.
** Encryption is not yet supported. **
See [[design/encryption]].
|
