bup(1) General Commands Manual bup(1)

bup - Backup program using rolling checksums and git file formats

bup [global options...] <command> [options...]

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.

print bup’s version number. Equivalent to bup version.
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.

Initialize a bup repository
Create or display the index of files to back up
Save files into a backup set (note: run “bup index” first)
Extract files from a backup set
Check backup sets for damage and add recovery information
Index/save/split/get/... a remote machine
Print detailed help for the given command

Browse the files in your backup sets
Mount your backup sets as a filesystem
Launch a web server to examine backup sets
Browse backup sets using an ftp-like client

Remove unreferenced, unneeded data
Transfer/transform items between/within repositories
Remove older saves
Remove references to archive content

Import from duplicity(1)
Import from rdiff-backup(1)
Import from rsnapshot(1)

Extract archive content
Recursively list files in your filesystem
Report the current status and capabilities of bup itself
Retrieve a file backed up using bup-split(1)
The server side of the bup client-server relationship
Split a single file into its own backup set
Tag a commit in the bup repository
Scan the repository for broken object links
Check repository refs for links to missing objects
Report the version number of your copy of bup.

Generates, regenerates, updates bloom filters
Deliberately destroy data
Determine how close your bup repository is to armageddon
Test bup memory usage statistics
Create or extract a metadata archive
Index objects to speed up future backups
Generate a stream of random output
Wait for up to one second.

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.

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.

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.
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:.
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.

If set to true, yes, or 1, assume the version of git in the path is acceptable.

The README file from the bup distribution, git(1), and http://bup.github.io

Avery Pennarun apenwarr@gmail.com.

2026-09-01 Bup 0.34+