NAME<\/a> btrfs-receive \u2212 receive subvolumes from send stream<\/p>\n btrfs receive<\/b> [options] or<\/p>\n btrfs receive<\/b> \u2212\u2212dump [options]<\/p>\n Receive a stream of changes and replicate one or more subvolumes that were previously generated by btrfs send<\/b>. The received subvolumes are stored to path<\/i>, unless \u2212\u2212dump<\/i> option is given.<\/p>\n If \u2212\u2212dump<\/i> option is specified, btrfs receive<\/b> will only do the validation of the stream, and print the stream metadata, one operation per line.<\/p>\n btrfs receive<\/b> will fail in the following cases:<\/p>\n 1. receiving subvolume already exists<\/p>\n 2. previously received subvolume has been changed after it was received<\/p>\n 3. default subvolume has changed or you didn\u2019t mount the filesystem at the toplevel subvolume<\/p>\n A subvolume is made read\u2212only after the receiving process finishes successfully (see BUGS below).<\/p>\n Options<\/b><\/p>\n \u2212f read the stream from \u2212C|\u2212\u2212chroot<\/p>\n confine the process to path<\/i> using chroot<\/b>(1)<\/p>\n \u2212e<\/p>\n terminate after receiving an end cmd<\/i> marker in the stream.<\/p>\n Without this option the receiver side terminates only in case of an error on end of file.<\/p>\n \u2212E|\u2212\u2212max\u2212errors terminate as soon as NERR errors occur while stream processing commands from the stream<\/p>\n Default value is 1. A value of 0 means no limit.<\/p>\n \u2212m the root mount point of the destination filesystem<\/p>\n By default the mountpoint is searched in \/proc\/self\/mounts<\/i>. If \/proc<\/i> is not accessible, eg. in a chroot environment, use this option to tell us where this filesystem is mounted.<\/p>\n \u2212\u2212dump<\/p>\n dump the stream metadata, one line per operation<\/p>\n Does not require the path<\/i> parameter. The filesystem remains unchanged.<\/p>\n \u2212q|\u2212\u2212quiet<\/p>\n (deprecated) alias for global \u2212q<\/i> option<\/p>\n \u2212v<\/p>\n (deprecated) alias for global \u2212v<\/i> option<\/p>\n Global options<\/b><\/p>\n \u2212v|\u2212\u2212verbose<\/p>\n increase verbosity about performed actions, print details about each operation<\/p>\n \u2212q|\u2212\u2212quiet<\/p>\n suppress all messages except errors<\/p>\n btrfs receive<\/b> sets the subvolume read\u2212only after it completes successfully. However, while the receive is in progress, users who have write access to files or directories in the receiving path<\/i> can add, remove, or modify files, in which case the resulting read\u2212only subvolume will not be an exact copy of the sent subvolume.<\/p>\n If the intention is to create an exact copy, the receiving path<\/i> should be protected from access by users until the receive operation has completed and the subvolume is set to read\u2212only.<\/p>\n 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<\/b> on send streams from untrusted sources, and to protect trusted streams when sending them across untrusted networks.<\/p>\n btrfs receive<\/b> returns a zero exit status if it succeeds. Non zero is returned in case of failure.<\/p>\n
SYNOPSIS<\/a>
DESCRIPTION<\/a>
BUGS<\/a>
EXIT STATUS<\/a>
AVAILABILITY<\/a>
SEE ALSO<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
DESCRIPTION <\/a> <\/h2>\n
BUGS <\/a> <\/h2>\n
EXIT STATUS <\/a> <\/h2>\n
AVAILABILITY <\/a> <\/h2>\n