Documentation/btrfs-receive.asciidoc

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