btrfs-receive - receive subvolumes from send stream
Receive a stream of changes and replicate one or more subvolumes that were
previously generated by btrfs send
. The received subvolumes are stored
, unless --dump
option is given.
option is specified, btrfs receive
will only do the
validation of the stream, and print the stream metadata, one operation per
will fail in the following cases:
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).
increase verbosity about performed actions,
print details about each operation
read the stream from <FILE>
instead of stdin,
confine the process to path using
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
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.
the root mount point of the destination
By default the mountpoint is searched in /proc/self/mounts
is not accessible, eg. in a chroot environment, use this option
to tell us where this filesystem is mounted.
dump the stream metadata, one line per
Does not require the path
parameter. The filesystem remains
sets the subvolume read-only after it completes
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
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 streams 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.
returns a zero exit status if it succeeds. Non zero is
returned in case of failure.
is part of btrfs-progs. Please refer to the btrfs wiki
for further details.