2021-10-26 22:45:24 +00:00
|
|
|
btrfs-receive(8)
|
|
|
|
================
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
|
|
|
|
**btrfs receive** [options] <path>
|
|
|
|
|
|
|
|
or
|
|
|
|
|
|
|
|
**btrfs receive** --dump [options]
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
|
|
|
|
Receive a stream of changes and replicate one or more subvolumes that were
|
2023-04-26 23:48:47 +00:00
|
|
|
previously generated by :command:`btrfs send`. The received subvolumes are stored to
|
2021-10-26 22:45:24 +00:00
|
|
|
*path*, unless *--dump* option is given.
|
|
|
|
|
2023-04-26 23:48:47 +00:00
|
|
|
If *--dump* option is specified, :command:`btrfs receive` will only do the validation of
|
2021-10-26 22:45:24 +00:00
|
|
|
the stream, and print the stream metadata, one operation per line.
|
|
|
|
|
2023-04-26 23:48:47 +00:00
|
|
|
:command:`btrfs receive` will fail in the following cases:
|
2021-10-26 22:45:24 +00:00
|
|
|
|
|
|
|
1. receiving subvolume already exists
|
|
|
|
|
|
|
|
2. previously received subvolume has been changed after it was received
|
|
|
|
|
|
|
|
3. default subvolume has changed or you didn't mount the filesystem at the toplevel subvolume
|
|
|
|
|
|
|
|
A subvolume is made read-only after the receiving process finishes successfully (see BUGS below).
|
|
|
|
|
|
|
|
``Options``
|
|
|
|
|
|
|
|
-f <FILE>
|
|
|
|
read the stream from *FILE* instead of stdin,
|
|
|
|
|
|
|
|
-C|--chroot
|
|
|
|
confine the process to *path* using ``chroot(1)``
|
|
|
|
|
|
|
|
-e
|
|
|
|
terminate after receiving an *end cmd* marker in the stream.
|
|
|
|
|
|
|
|
Without this option the receiver side terminates only in case
|
|
|
|
of an error on end of file.
|
|
|
|
|
|
|
|
-E|--max-errors <NERR>
|
|
|
|
terminate as soon as NERR errors occur while stream processing commands from
|
|
|
|
the stream
|
|
|
|
|
|
|
|
Default value is 1. A value of 0 means no limit.
|
|
|
|
|
|
|
|
-m <ROOTMOUNT>
|
|
|
|
the root mount point of the destination filesystem
|
|
|
|
|
2023-06-28 17:55:08 +00:00
|
|
|
By default the mount point is searched in :file:/proc/self/mounts`.
|
|
|
|
If :file:`/proc` is not accessible, e.g. in a chroot environment, use this option to
|
2021-10-26 22:45:24 +00:00
|
|
|
tell us where this filesystem is mounted.
|
|
|
|
|
2022-03-17 17:25:49 +00:00
|
|
|
--force-decompress
|
|
|
|
if the stream contains compressed data (see *--compressed-data* in
|
2023-06-28 17:55:08 +00:00
|
|
|
:doc:`btrfs-send`), always decompress it instead of writing it with
|
2022-03-17 17:25:49 +00:00
|
|
|
encoded I/O
|
|
|
|
|
2021-10-26 22:45:24 +00:00
|
|
|
--dump
|
|
|
|
dump the stream metadata, one line per operation
|
|
|
|
|
|
|
|
Does not require the *path* parameter. The filesystem remains unchanged.
|
|
|
|
|
|
|
|
-q|--quiet
|
|
|
|
(deprecated) alias for global *-q* option
|
|
|
|
|
|
|
|
-v
|
|
|
|
(deprecated) alias for global *-v* option
|
|
|
|
|
|
|
|
``Global options``
|
|
|
|
|
|
|
|
-v|--verbose
|
|
|
|
increase verbosity about performed actions, print details about each operation
|
|
|
|
|
|
|
|
-q|--quiet
|
|
|
|
suppress all messages except errors
|
|
|
|
|
|
|
|
BUGS
|
|
|
|
----
|
|
|
|
|
2023-04-26 23:48:47 +00:00
|
|
|
:command:`btrfs receive` sets the subvolume read-only after it completes
|
2021-10-26 22:45:24 +00:00
|
|
|
successfully. However, while the receive is in progress, users who have
|
|
|
|
write access to files or directories in the receiving *path* can add,
|
|
|
|
remove, or modify files, in which case the resulting read-only subvolume
|
|
|
|
will not be an exact copy of the sent subvolume.
|
|
|
|
|
|
|
|
If the intention is to create an exact copy, the receiving *path*
|
|
|
|
should be protected from access by users until the receive operation
|
|
|
|
has completed and the subvolume is set to read-only.
|
|
|
|
|
|
|
|
Additionally, receive does not currently do a very good job of validating
|
|
|
|
that an incremental send stream actually makes sense, and it is thus
|
|
|
|
possible for a specially crafted send stream to create a subvolume with
|
|
|
|
reflinks to arbitrary files in the same filesystem. Because of this,
|
|
|
|
users are advised to not use *btrfs receive* on send streams from
|
|
|
|
untrusted sources, and to protect trusted streams when sending them
|
|
|
|
across untrusted networks.
|
|
|
|
|
|
|
|
EXIT STATUS
|
|
|
|
-----------
|
|
|
|
|
|
|
|
**btrfs receive** 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-send`,
|
|
|
|
:doc:`mkfs.btrfs`
|