1BTRFS-RECEIVE(8) Btrfs Manual BTRFS-RECEIVE(8)
2
3
4
6 btrfs-receive - receive subvolumes from send stream
7
9 btrfs receive [options] <path>
10
11 or
12
13 btrfs receive --dump [options]
14
16 Receive a stream of changes and replicate one or more subvolumes that
17 were previously generated by btrfs send. The received subvolumes are
18 stored to path, unless --dump option is given.
19
20 If --dump option is specified, btrfs receive will only do the
21 validation of the stream, and print the stream metadata, one operation
22 per line.
23
24 btrfs receive will fail in the following cases:
25
26 1. receiving subvolume already exists
27
28 2. previously received subvolume has been changed after it was
29 received
30
31 3. default subvolume has changed or you didn’t mount the filesystem at
32 the toplevel subvolume
33
34 A subvolume is made read-only after the receiving process finishes
35 successfully (see BUGS below).
36
37 Options
38
39 -v
40 increase verbosity about performed actions, print details about
41 each operation
42
43 -q|--quiet
44 suppress all messages except errors
45
46 -f <FILE>
47 read the stream from <FILE> instead of stdin,
48
49 -C|--chroot
50 confine the process to path using chroot(1)
51
52 -e
53 terminate after receiving an end cmd marker in the stream.
54
55 Without this option the receiver side terminates only in case of an
56 error on end of file.
57
58 -E|--max-errors <NERR>
59 terminate as soon as NERR errors occur while stream processing
60 commands from the stream
61
62 Default value is 1. A value of 0 means no limit.
63
64 -m <ROOTMOUNT>
65 the root mount point of the destination filesystem
66
67 By default the mountpoint is searched in /proc/self/mounts. If
68 /proc is not accessible, eg. in a chroot environment, use this
69 option to tell us where this filesystem is mounted.
70
71 --dump
72 dump the stream metadata, one line per operation
73
74 Does not require the path parameter. The filesystem remains
75 unchanged.
76
78 btrfs receive sets the subvolume read-only after it completes
79 successfully. However, while the receive is in progress, users who have
80 write access to files or directories in the receiving path can add,
81 remove, or modify files, in which case the resulting read-only
82 subvolume will not be an exact copy of the sent subvolume.
83
84 If the intention is to create an exact copy, the receiving path should
85 be protected from access by users until the receive operation has
86 completed and the subvolume is set to read-only.
87
88 Additionally, receive does not currently do a very good job of
89 validating that an incremental send stream actually makes sense, and it
90 is thus possible for a specially crafted send stream to create a
91 subvolume with reflinks to arbitrary files in the same filesystem.
92 Because of this, users are advised to not use btrfs receive on send
93 streams from untrusted sources, and to protect trusted streams when
94 sending them across untrusted networks.
95
97 btrfs receive returns a zero exit status if it succeeds. Non zero is
98 returned in case of failure.
99
101 btrfs is part of btrfs-progs. Please refer to the btrfs wiki
102 http://btrfs.wiki.kernel.org for further details.
103
105 mkfs.btrfs(8), btrfs-send(8)
106
107
108
109Btrfs v5.1 05/17/2019 BTRFS-RECEIVE(8)