diff options
Diffstat (limited to 'upstream/archlinux/man8/btrfs-receive.8')
| -rw-r--r-- | upstream/archlinux/man8/btrfs-receive.8 | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/upstream/archlinux/man8/btrfs-receive.8 b/upstream/archlinux/man8/btrfs-receive.8 new file mode 100644 index 00000000..d206b010 --- /dev/null +++ b/upstream/archlinux/man8/btrfs-receive.8 @@ -0,0 +1,159 @@ +.\" Man page generated from reStructuredText. +. +. +.nr rst2man-indent-level 0 +. +.de1 rstReportMargin +\\$1 \\n[an-margin] +level \\n[rst2man-indent-level] +level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] +- +\\n[rst2man-indent0] +\\n[rst2man-indent1] +\\n[rst2man-indent2] +.. +.de1 INDENT +.\" .rstReportMargin pre: +. RS \\$1 +. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] +. nr rst2man-indent-level +1 +.\" .rstReportMargin post: +.. +.de UNINDENT +. RE +.\" indent \\n[an-margin] +.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] +.nr rst2man-indent-level -1 +.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] +.in \\n[rst2man-indent\\n[rst2man-indent-level]]u +.. +.TH "BTRFS-RECEIVE" "8" "Feb 14, 2024" "6.7.1" "BTRFS" +.SH NAME +btrfs-receive \- receive subvolumes from send stream +.SH SYNOPSIS +.sp +\fBbtrfs receive\fP [options] <path> +.sp +or +.sp +\fBbtrfs receive\fP \-\-dump [options] +.SH DESCRIPTION +.sp +Receive a stream of changes and replicate one or more subvolumes that were +previously generated by \fBbtrfs send\fP\&. The received subvolumes are stored to +\fIpath\fP, unless \fI\-\-dump\fP option is given. +.sp +If \fI\-\-dump\fP option is specified, \fBbtrfs receive\fP will only do the validation of +the stream, and print the stream metadata, one operation per line. +.sp +\fBbtrfs receive\fP will fail in the following cases: +.INDENT 0.0 +.IP 1. 3 +receiving subvolume already exists +.IP 2. 3 +previously received subvolume has been changed after it was received +.IP 3. 3 +default subvolume has changed or you didn\(aqt mount the filesystem at the toplevel subvolume +.UNINDENT +.sp +A subvolume is made read\-only after the receiving process finishes successfully (see BUGS below). +.sp +\fBOptions\fP +.INDENT 0.0 +.TP +.BI \-f \ <FILE> +read the stream from \fIFILE\fP instead of stdin, +.UNINDENT +.INDENT 0.0 +.TP +.B \-C|\-\-chroot +confine the process to \fIpath\fP using \fBchroot(1)\fP +.UNINDENT +.INDENT 0.0 +.TP +.B \-e +terminate after receiving an \fIend cmd\fP marker in the stream. +.sp +Without this option the receiver side terminates only in case +of an error on end of file. +.UNINDENT +.INDENT 0.0 +.TP +.B \-E|\-\-max\-errors <NERR> +terminate as soon as NERR errors occur while stream processing commands from +the stream +.sp +Default value is 1. A value of 0 means no limit. +.UNINDENT +.INDENT 0.0 +.TP +.BI \-m \ <ROOTMOUNT> +the root mount point of the destination filesystem +.sp +By default the mount point is searched in :\fI\%file:/proc/self\fP/mounts\(ga. +If \fB/proc\fP is not accessible, e.g. in a chroot environment, use this option to +tell us where this filesystem is mounted. +.TP +.B \-\-force\-decompress +if the stream contains compressed data (see \fI\-\-compressed\-data\fP in +\fI\%btrfs\-send(8)\fP), always decompress it instead of writing it with +encoded I/O +.TP +.B \-\-dump +dump the stream metadata, one line per operation +.sp +Does not require the \fIpath\fP parameter. The filesystem remains unchanged. +.UNINDENT +.INDENT 0.0 +.TP +.B \-q|\-\-quiet +(deprecated) alias for global \fI\-q\fP option +.UNINDENT +.INDENT 0.0 +.TP +.B \-v +(deprecated) alias for global \fI\-v\fP option +.UNINDENT +.sp +\fBGlobal options\fP +.INDENT 0.0 +.TP +.B \-v|\-\-verbose +increase verbosity about performed actions, print details about each operation +.TP +.B \-q|\-\-quiet +suppress all messages except errors +.UNINDENT +.SH BUGS +.sp +\fBbtrfs receive\fP 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 \fIpath\fP can add, +remove, or modify files, in which case the resulting read\-only subvolume +will not be an exact copy of the sent subvolume. +.sp +If the intention is to create an exact copy, the receiving \fIpath\fP +should be protected from access by users until the receive operation +has completed and the subvolume is set to read\-only. +.sp +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 \fIbtrfs receive\fP on send streams from +untrusted sources, and to protect trusted streams when sending them +across untrusted networks. +.SH EXIT STATUS +.sp +\fBbtrfs receive\fP returns a zero exit status if it succeeds. Non zero is +returned in case of failure. +.SH AVAILABILITY +.sp +\fBbtrfs\fP is part of btrfs\-progs. Please refer to the documentation at +\fI\%https://btrfs.readthedocs.io\fP\&. +.SH SEE ALSO +.sp +\fI\%btrfs\-send(8)\fP, +\fI\%mkfs.btrfs(8)\fP +.\" Generated by docutils manpage writer. +. |