bup(1) General Commands Manual bup(1) NAME bup - Backup program using rolling checksums and git file formats SYNOPSIS bup [global options...] [options...] DESCRIPTION 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. GLOBAL 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. PRIMARY COMMANDS bup-init(1) Initialize a bup repository bup-index(1) Create or display the index of files to back up bup-save(1) Save files into a backup set (note: run "bup index" first) bup-restore(1) Extract files from a backup set bup-fsck(1) Check backup sets for damage and add recovery information bup-on(1) Index/save/split/get/... a remote machine bup-help(1) Print detailed help for the given command 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 MANIPULATION COMMANDS bup-gc(1) Remove unreferenced, unneeded data bup-get(1) Transfer/transform items between/within repositories bup-prune-older(1) Remove older saves bup-rm(1) Remove references to archive content IMPORT COMMANDS bup-import-duplicity(1) Import from duplicity(1) bup-import-rdiff-backup(1) Import from rdiff-backup(1) bup-import-rsnapshot(1) Import from rsnapshot(1) OTHER COMMANDS bup-cat-file(1) Extract archive content bup-drecurse(1) Recursively list files in your filesystem bup-features(1) Report the current status and capabilities of bup itself bup-join(1) Retrieve a file backed up using bup-split(1) bup-server(1) The server side of the bup client-server relationship bup-split(1) Split a single file into its own backup set bup-tag(1) Tag a commit in the bup repository bup-validate-object-links(1) Scan the repository for broken object links bup-validate-ref-links(1) Check repository refs for links to missing objects bup-version(1) Report the version number of your copy of bup. ESOTERIC COMMANDS bup-bloom(1) Generates, regenerates, updates bloom filters bup-damage(1) Deliberately destroy data bup-margin(1) Determine how close your bup repository is to armageddon bup-memtest(1) Test bup memory usage statistics bup-meta(1) Create or extract a metadata archive bup-midx(1) Index objects to speed up future backups bup-random(1) Generate a stream of random output bup-tick(1) Wait for up to one second. REMOTE 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. SEE ALSO The README file from the bup distribution, git(1), and http://bup.github.io AUTHORS Avery Pennarun . Bup 0.34+ 2026-09-01 bup(1)