mirror of
https://github.com/kdave/btrfs-progs
synced 2024-12-23 22:53:35 +00:00
90f7db78a3
While talking to another btrfs user on IRC today, it became clear that a major point of confusion in the btrfs send manual is that it's not telling the user soon enough that send/receive solely operates on subvolume snapshots instead of the original (read/write) subvolumes. So, change the first few lines to explicitly mention snapshots instead. Technically, snapshots are also just subvolumes, but requiring this level of technical detailed knowledge doesn't help the user who is just trying out things. Signed-off-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by: David Sterba <dsterba@suse.com>
79 lines
2.5 KiB
Plaintext
79 lines
2.5 KiB
Plaintext
btrfs-send(8)
|
|
=============
|
|
|
|
NAME
|
|
----
|
|
btrfs-send - generate a stream of changes between two subvolume snapshots
|
|
|
|
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 subvolume snapshots. The stream can be consumed by the *btrfs
|
|
receive* command to replicate the sent snapshot on a different filesystem.
|
|
The command operates in two modes: full and incremental.
|
|
|
|
All snapshots involved in one send command must be read-only, and this status
|
|
cannot be changed as long as there's a running send operation that uses the
|
|
snapshot.
|
|
|
|
In the full mode, the entire snapshot data and metadata will end up in the
|
|
stream.
|
|
|
|
In the incremental mode (options '-p' and '-c'), previously sent snapshots that
|
|
are available on both the sending and receiving side can be used to reduce the
|
|
amount of information that has to be sent to reconstruct the sent snapshot on a
|
|
different filesystem.
|
|
|
|
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 output so it can be, for example, piped
|
|
to btrfs receive. Use this option to write it to a file instead.
|
|
--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 messages 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)
|