2021-10-26 22:45:24 +00:00
|
|
|
btrfs-send(8)
|
|
|
|
=============
|
|
|
|
|
|
|
|
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
|
2023-04-26 23:48:47 +00:00
|
|
|
between two subvolume snapshots. The stream can be consumed by the :command:`btrfs receive`
|
|
|
|
command to replicate the sent snapshot on a different filesystem.
|
2021-10-26 22:45:24 +00:00
|
|
|
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
|
2022-09-21 07:55:19 +00:00
|
|
|
snapshot. Read-only mount of the subvolume is not sufficient, there's no way to
|
|
|
|
guarantee that there won't be any other writable mount of the same subvolume
|
|
|
|
that would potentially write while send would be running.
|
2021-10-26 22:45:24 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
The *-p <parent>* option can be omitted when *-c <clone-src>* options are
|
2023-04-26 23:48:47 +00:00
|
|
|
given, in which case :command:`btrfs send` will determine a suitable parent from among
|
2021-10-26 22:45:24 +00:00
|
|
|
the clone sources.
|
|
|
|
|
|
|
|
You must not specify clone sources unless you guarantee that these snapshots
|
|
|
|
are exactly in the same state on both sides--both for the sender and the
|
|
|
|
receiver. For implications of changed read-write status of a received snapshot
|
2023-06-28 17:55:08 +00:00
|
|
|
please see section *SUBVOLUME FLAGS* in :doc:`btrfs-subvolume`.
|
2021-10-26 22:45:24 +00:00
|
|
|
|
|
|
|
``Options``
|
|
|
|
|
|
|
|
-e
|
|
|
|
if sending multiple subvolumes at once, use the new format and omit the
|
2023-06-28 17:55:08 +00:00
|
|
|
*end cmd* marker in the stream separating the subvolumes
|
2021-10-26 22:45:24 +00:00
|
|
|
|
|
|
|
-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.
|
|
|
|
|
2022-09-23 09:48:45 +00:00
|
|
|
--no-data
|
2021-10-26 22:45:24 +00:00
|
|
|
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 is useful to show the
|
|
|
|
differences in metadata.
|
|
|
|
|
2022-03-17 17:25:52 +00:00
|
|
|
--proto <N>
|
|
|
|
use send protocol version N
|
|
|
|
|
|
|
|
The default is 1, which was the original protocol version. Version 2
|
|
|
|
encodes file data slightly more efficiently; it is also required for
|
|
|
|
sending compressed data directly (see *--compressed-data*). Version 2
|
2022-10-14 10:48:47 +00:00
|
|
|
requires at least btrfs-progs 6.0 on both the sender and receiver and
|
|
|
|
at least Linux 6.0 on the sender. Passing 0 means to use the highest
|
2022-03-17 17:25:52 +00:00
|
|
|
version supported by the running kernel.
|
|
|
|
|
|
|
|
--compressed-data
|
|
|
|
send data that is compressed on the filesystem directly without
|
|
|
|
decompressing it
|
|
|
|
|
|
|
|
If the receiver supports the *BTRFS_IOC_ENCODED_WRITE* ioctl (added in
|
2022-10-14 10:48:47 +00:00
|
|
|
Linux 6.0), it can also write it directly without decompressing it.
|
2022-03-17 17:25:52 +00:00
|
|
|
Otherwise, the receiver will fall back to decompressing it and writing
|
|
|
|
it normally.
|
|
|
|
|
|
|
|
This requires protocol version 2 or higher. If *--proto* was not used,
|
|
|
|
then *--compressed-data* implies *--proto 2*.
|
|
|
|
|
2021-10-26 22:45:24 +00:00
|
|
|
-q|--quiet
|
|
|
|
(deprecated) alias for global *-q* option
|
|
|
|
|
|
|
|
-v|--verbose
|
|
|
|
(deprecated) alias for global *-v* option
|
|
|
|
|
|
|
|
``Global options``
|
|
|
|
|
|
|
|
-q|--quiet
|
|
|
|
suppress all messages except errors
|
|
|
|
|
|
|
|
-v|--verbose
|
|
|
|
increase output verbosity, print generated commands in a readable form
|
|
|
|
|
|
|
|
EXIT STATUS
|
|
|
|
-----------
|
|
|
|
|
|
|
|
**btrfs send** returns a zero exit status if it succeeds. Non zero is
|
|
|
|
returned in case of failure.
|
|
|
|
|
|
|
|
AVAILABILITY
|
|
|
|
------------
|
|
|
|
|
2022-10-06 15:52:25 +00:00
|
|
|
**btrfs** is part of btrfs-progs. Please refer to the documentation at
|
2023-03-16 21:38:21 +00:00
|
|
|
`https://btrfs.readthedocs.io <https://btrfs.readthedocs.io>`_.
|
2021-10-26 22:45:24 +00:00
|
|
|
|
|
|
|
SEE ALSO
|
|
|
|
--------
|
|
|
|
|
2023-06-28 17:55:08 +00:00
|
|
|
:doc:`btrfs-receive`,
|
|
|
|
:doc:`btrfs-subvolume`,
|
|
|
|
:doc:`mkfs.btrfs`
|