summaryrefslogtreecommitdiff
path: root/Documentation/btrfs-send.asciidoc
diff options
context:
space:
mode:
authorDimitri John Ledkov <xnox@ubuntu.com>2016-07-26 13:24:39 +0100
committerDimitri John Ledkov <xnox@ubuntu.com>2016-07-26 13:24:39 +0100
commit3d69435ee3292b4b1db2d61c4784789d75883821 (patch)
tree2c0edc9d9501374799875af36259089feb99d48c /Documentation/btrfs-send.asciidoc
Imported Upstream version 4.6.1
Diffstat (limited to 'Documentation/btrfs-send.asciidoc')
-rw-r--r--Documentation/btrfs-send.asciidoc76
1 files changed, 76 insertions, 0 deletions
diff --git a/Documentation/btrfs-send.asciidoc b/Documentation/btrfs-send.asciidoc
new file mode 100644
index 00000000..47b0b047
--- /dev/null
+++ b/Documentation/btrfs-send.asciidoc
@@ -0,0 +1,76 @@
+btrfs-send(8)
+=============
+
+NAME
+----
+btrfs-send - generate a stream of changes between two subvolumes
+
+SYNOPSIS
+--------
+*btrfs send* [-ve] [-p <parent>] [-c <clone-src>] [-f <outfile>] <subvol> [<subvol>...]
+
+DESCRIPTION
+-----------
+
+This command will generate a stream of instructions that describe changes
+between two subvolumes. The stream can be consumed by the *btrfs receive*
+command to replicate the sent subvolume on a different filesystem.
+The command operates in two modes: full and incremental.
+
+All subvolumes involved in one send command must be read-only (ie. the
+read-only snapshots and this status cannot be changed if there's a running send
+operation that uses the subvolume).
+
+In the full mode, the entire subvolume data and metadata will end up in the
+stream.
+
+In the incremental mode (options '-p' and '-c'), there can be one or more
+parent subvolumes that will establish the base for determining the changes.
+The final stream will be smaller compared to the full mode.
+
+It is allowed to omit the '-p <parent>' option when '-c <clone-src>' options
+are given, in which case *btrfs send* will determine a suitable parent among the
+clone sources itself.
+
+You must not specify clone sources unless you guarantee that these snapshots
+are exactly in the same state on both sides, the sender and the receiver.
+
+`Options`
+
+-e::
+if sending multiple subvolumes at once, use the new format and omit the
+'end cmd' marker in the stream separating the subvolumes
+-p <parent>::
+send an incremental stream from 'parent' to 'subvol'
+-c <clone-src>::
+use this snapshot as a clone source for an incremental send (multiple allowed)
+-f <outfile>::
+output is normally written to standard outout so it can be eg. piped to
+receive, use this option to write it to a file
+--no-data::
+send in 'NO_FILE_DATA' mode
++
+The output stream does not contain any file
+data and thus cannot be used to transfer changes. This mode is faster and
+useful to show the differences in metadata.
+-v|--verbose::
+enable verbose output, print generated commands in a readable form, (each
+occurrence of this option increases the verbosity level)
+-q|--quiet::
+suppress all messagese except errors
+
+EXIT STATUS
+-----------
+*btrfs send* returns a zero exit status if it succeeds. Non zero is
+returned in case of failure.
+
+AVAILABILITY
+------------
+*btrfs* is part of btrfs-progs.
+Please refer to the btrfs wiki http://btrfs.wiki.kernel.org for
+further details.
+
+SEE ALSO
+--------
+`mkfs.btrfs`(8),
+`btrfs-receive`(8)