Usage
bup [global
options ...]
<command>
[options ...]
Overview
bup is a program for making backups of your files using the git file format.
Unlike git(1) itself, bup is optimized for handling huge data sets including individual very large files (such a virtual machine images). However, once a backup set is created, it can still be accessed using git tools.
Subcommands are described in separate man pages. For example bup-init(1) covers bup init.
Options
-
--version
-
print bup’s version number. Equivalent to bup version.
-
-d, --bup-dir=BUP_DIR
-
use the given BUP_DIR parameter as the bup repository location, instead of reading it from the $BUP_DIR environment variable or using the default ~/.bup location.
Inspection commands
bup-ls(1) |
Browse the files in your backup sets
|
bup-fuse(1) |
Mount your backup sets as a filesystem
|
bup-web(1) |
Launch a web server to examine backup sets
|
bup-ftp(1) |
Browse backup sets using an ftp-like client
|
Options
Some options (currently just --remote) allow the specification of a remote path as either a URL (see REPOSITORY URLS below) or a [*user*@]*host*:[*path*].
For either format, when there is no path, the default path on the server will be used (BUP_DIR if set in the remote environment or ~/.bup), and SSH settings for the connection can be provided by a custom host in your ~/.ssh/config file (ssh_config(5)).
The argument is treated as a URL if it begins with a syntactically valid URL scheme prefix that contains an “authority” (meaning that it begins with SCHEME:// as ssh://... does), and the scheme must be either ssh or bup; others will be rejected.
For the [*user*@]*host*:[*path*] syntax, if there is an @ symbol, then everything before the rightmost @ is included in the user so -r x@y@z indicates user x@y, host z. The host must always be followed by a colon, and anything after the first colon is the path.
For fully general purposes, prefer URLs to [*user*@]*host*:[*path*], so that there is no potential ambiguity. For example, consider the (unlikely) case where ssh://x/y is generated for a host named ssh and path //x/y, which would be interpreted as a URL with host x and path /y.
Repository urls
Bup supports the following URL schemes (i.e. scheme:) for referring to a repository. Note that the term “authority” below just means the URL section after the scheme:// and before the path, for example the “user@host:port” of an SSH URL.
As an exception to the standard, a scheme may be “path-oriented”, which means that there is no separate query or fragment. Anything after the (optional) authority is taken as the “path” and the constituent bytes are not decoded (e.g. percent decoded). This allows URLs provided on the command line to work naturally. So ssh://host/x?z has a path of /x?z.
And since URLs with an authority cannot represent relative paths, path-oriented schemes interpret a leading /./ as a relative path. So ssh://host/./x, file:///./x, and file:/./x all indicate the path x.
ssh:-
A path-oriented scheme (see above) that specifies access to a repository via a bup-server(1) launched on a host via SSH. This scheme has syntax and semantics matching a typical ssh: URL, including support for a user and port (e.g. ssh://user@host:2222/some/repo), and the user and host can be percent encoded.
bup:-
A path-oriented scheme (see above) specifying a direct network connection to to an existing bup-server(1). Otherwise identical to ssh:, except that it does not support a user. This connection has no authentication or encryption of its own so it’s unlikely you’ll want to use it; prefer file: or :ssh:.
file:-
A path-oriented scheme (see above) that specifies a repository’s filesystem path. This scheme has syntax and semantics matching a typical file: URL, except that it only allows an empty authority (i.e. no user, host, etc.).
In most cases, you will probably want to include the empty authority so you don’t have to consider the contents of the path carefully, i.e. use file://PATH or ssh://user@hostPATH when the PATH begins with a slash, and file:///./PATH or ssh://user@host/./PATH when it doesn’t. It is possible to omit the authority, but only if the path does not begin with two slashes. For example file:/ and file:some/where are fine, but file://some/where is not because some will be read as the authority.
Environment
-
BUP_ASSUME_GIT_VERSION_IS_FINE
-
If set to true, yes, or 1, assume the version of git in the path is acceptable.
Releases
8 releases since Debian 6.0 (Squeeze); the text changed 7 times.
-
6.0
-
7
-
8
-
9
-
11
-
12
-
13
-
Arch
--bup-dir since Debian 7 (Wheezy);
--version since Debian 7 (Wheezy);
-d since Debian 7 (Wheezy).