xref: /freebsd/sys/contrib/openzfs/man/man8/zfs-receive.8 (revision 1323ec571215a77ddd21294f0871979d5ad6b992)
1.\"
2.\" CDDL HEADER START
3.\"
4.\" The contents of this file are subject to the terms of the
5.\" Common Development and Distribution License (the "License").
6.\" You may not use this file except in compliance with the License.
7.\"
8.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9.\" or http://www.opensolaris.org/os/licensing.
10.\" See the License for the specific language governing permissions
11.\" and limitations under the License.
12.\"
13.\" When distributing Covered Code, include this CDDL HEADER in each
14.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15.\" If applicable, add the following below this CDDL HEADER, with the
16.\" fields enclosed by brackets "[]" replaced with your own identifying
17.\" information: Portions Copyright [yyyy] [name of copyright owner]
18.\"
19.\" CDDL HEADER END
20.\"
21.\" Copyright (c) 2009 Sun Microsystems, Inc. All Rights Reserved.
22.\" Copyright 2011 Joshua M. Clulow <josh@sysmgr.org>
23.\" Copyright (c) 2011, 2019 by Delphix. All rights reserved.
24.\" Copyright (c) 2013 by Saso Kiselkov. All rights reserved.
25.\" Copyright (c) 2014, Joyent, Inc. All rights reserved.
26.\" Copyright (c) 2014 by Adam Stevko. All rights reserved.
27.\" Copyright (c) 2014 Integros [integros.com]
28.\" Copyright 2019 Richard Laager. All rights reserved.
29.\" Copyright 2018 Nexenta Systems, Inc.
30.\" Copyright 2019 Joyent, Inc.
31.\"
32.Dd March 16, 2022
33.Dt ZFS-RECEIVE 8
34.Os
35.
36.Sh NAME
37.Nm zfs-receive
38.Nd create snapshot from backup stream
39.Sh SYNOPSIS
40.Nm zfs
41.Cm receive
42.Op Fl FhMnsuv
43.Op Fl o Sy origin Ns = Ns Ar snapshot
44.Op Fl o Ar property Ns = Ns Ar value
45.Op Fl x Ar property
46.Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
47.Nm zfs
48.Cm receive
49.Op Fl FhMnsuv
50.Op Fl d Ns | Ns Fl e
51.Op Fl o Sy origin Ns = Ns Ar snapshot
52.Op Fl o Ar property Ns = Ns Ar value
53.Op Fl x Ar property
54.Ar filesystem
55.Nm zfs
56.Cm receive
57.Fl A
58.Ar filesystem Ns | Ns Ar volume
59.
60.Sh DESCRIPTION
61.Bl -tag -width ""
62.It Xo
63.Nm zfs
64.Cm receive
65.Op Fl FhMnsuv
66.Op Fl o Sy origin Ns = Ns Ar snapshot
67.Op Fl o Ar property Ns = Ns Ar value
68.Op Fl x Ar property
69.Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
70.Xc
71.It Xo
72.Nm zfs
73.Cm receive
74.Op Fl FhMnsuv
75.Op Fl d Ns | Ns Fl e
76.Op Fl o Sy origin Ns = Ns Ar snapshot
77.Op Fl o Ar property Ns = Ns Ar value
78.Op Fl x Ar property
79.Ar filesystem
80.Xc
81Creates a snapshot whose contents are as specified in the stream provided on
82standard input.
83If a full stream is received, then a new file system is created as well.
84Streams are created using the
85.Nm zfs Cm send
86subcommand, which by default creates a full stream.
87.Nm zfs Cm recv
88can be used as an alias for
89.Nm zfs Cm receive .
90.Pp
91If an incremental stream is received, then the destination file system must
92already exist, and its most recent snapshot must match the incremental stream's
93source.
94For
95.Sy zvols ,
96the destination device link is destroyed and recreated, which means the
97.Sy zvol
98cannot be accessed during the
99.Cm receive
100operation.
101.Pp
102When a snapshot replication package stream that is generated by using the
103.Nm zfs Cm send Fl R
104command is received, any snapshots that do not exist on the sending location are
105destroyed by using the
106.Nm zfs Cm destroy Fl d
107command.
108.Pp
109The ability to send and receive deduplicated send streams has been removed.
110However, a deduplicated send stream created with older software can be converted
111to a regular (non-deduplicated) stream by using the
112.Nm zstream Cm redup
113command.
114.Pp
115If
116.Fl o Em property Ns = Ns Ar value
117or
118.Fl x Em property
119is specified, it applies to the effective value of the property throughout
120the entire subtree of replicated datasets.
121Effective property values will be set
122.Pq Fl o
123or inherited
124.Pq Fl x
125on the topmost in the replicated subtree.
126In descendant datasets, if the
127property is set by the send stream, it will be overridden by forcing the
128property to be inherited from the top‐most file system.
129Received properties are retained in spite of being overridden
130and may be restored with
131.Nm zfs Cm inherit Fl S .
132Specifying
133.Fl o Sy origin Ns = Ns Em snapshot
134is a special case because, even if
135.Sy origin
136is a read-only property and cannot be set, it's allowed to receive the send
137stream as a clone of the given snapshot.
138.Pp
139Raw encrypted send streams (created with
140.Nm zfs Cm send Fl w )
141may only be received as is, and cannot be re-encrypted, decrypted, or
142recompressed by the receive process.
143Unencrypted streams can be received as
144encrypted datasets, either through inheritance or by specifying encryption
145parameters with the
146.Fl o
147options.
148Note that the
149.Sy keylocation
150property cannot be overridden to
151.Sy prompt
152during a receive.
153This is because the receive process itself is already using
154the standard input for the send stream.
155Instead, the property can be overridden after the receive completes.
156.Pp
157The added security provided by raw sends adds some restrictions to the send
158and receive process.
159ZFS will not allow a mix of raw receives and non-raw receives.
160Specifically, any raw incremental receives that are attempted after
161a non-raw receive will fail.
162Non-raw receives do not have this restriction and,
163therefore, are always possible.
164Because of this, it is best practice to always
165use either raw sends for their security benefits or non-raw sends for their
166flexibility when working with encrypted datasets, but not a combination.
167.Pp
168The reason for this restriction stems from the inherent restrictions of the
169AEAD ciphers that ZFS uses to encrypt data.
170When using ZFS native encryption,
171each block of data is encrypted against a randomly generated number known as
172the "initialization vector" (IV), which is stored in the filesystem metadata.
173This number is required by the encryption algorithms whenever the data is to
174be decrypted.
175Together, all of the IVs provided for all of the blocks in a
176given snapshot are collectively called an "IV set".
177When ZFS performs a raw send, the IV set is transferred from the source
178to the destination in the send stream.
179When ZFS performs a non-raw send, the data is decrypted by the source
180system and re-encrypted by the destination system, creating a snapshot with
181effectively the same data, but a different IV set.
182In order for decryption to work after a raw send, ZFS must ensure that
183the IV set used on both the source and destination side match.
184When an incremental raw receive is performed on
185top of an existing snapshot, ZFS will check to confirm that the "from"
186snapshot on both the source and destination were using the same IV set,
187ensuring the new IV set is consistent.
188.Pp
189The name of the snapshot
190.Pq and file system, if a full stream is received
191that this subcommand creates depends on the argument type and the use of the
192.Fl d
193or
194.Fl e
195options.
196.Pp
197If the argument is a snapshot name, the specified
198.Ar snapshot
199is created.
200If the argument is a file system or volume name, a snapshot with the same name
201as the sent snapshot is created within the specified
202.Ar filesystem
203or
204.Ar volume .
205If neither of the
206.Fl d
207or
208.Fl e
209options are specified, the provided target snapshot name is used exactly as
210provided.
211.Pp
212The
213.Fl d
214and
215.Fl e
216options cause the file system name of the target snapshot to be determined by
217appending a portion of the sent snapshot's name to the specified target
218.Ar filesystem .
219If the
220.Fl d
221option is specified, all but the first element of the sent snapshot's file
222system path
223.Pq usually the pool name
224is used and any required intermediate file systems within the specified one are
225created.
226If the
227.Fl e
228option is specified, then only the last element of the sent snapshot's file
229system name
230.Pq i.e. the name of the source file system itself
231is used as the target file system name.
232.Bl -tag -width "-F"
233.It Fl F
234Force a rollback of the file system to the most recent snapshot before
235performing the receive operation.
236If receiving an incremental replication stream
237.Po for example, one generated by
238.Nm zfs Cm send Fl R Op Fl i Ns | Ns Fl I
239.Pc ,
240destroy snapshots and file systems that do not exist on the sending side.
241.It Fl d
242Discard the first element of the sent snapshot's file system name, using the
243remaining elements to determine the name of the target file system for the new
244snapshot as described in the paragraph above.
245.It Fl e
246Discard all but the last element of the sent snapshot's file system name, using
247that element to determine the name of the target file system for the new
248snapshot as described in the paragraph above.
249.It Fl h
250Skip the receive of holds.
251There is no effect if holds are not sent.
252.It Fl M
253Force an unmount of the file system while receiving a snapshot.
254This option is not supported on Linux.
255.It Fl n
256Do not actually receive the stream.
257This can be useful in conjunction with the
258.Fl v
259option to verify the name the receive operation would use.
260.It Fl o Sy origin Ns = Ns Ar snapshot
261Forces the stream to be received as a clone of the given snapshot.
262If the stream is a full send stream, this will create the filesystem
263described by the stream as a clone of the specified snapshot.
264Which snapshot was specified will not affect the success or failure of the
265receive, as long as the snapshot does exist.
266If the stream is an incremental send stream, all the normal verification will be
267performed.
268.It Fl o Em property Ns = Ns Ar value
269Sets the specified property as if the command
270.Nm zfs Cm set Em property Ns = Ns Ar value
271was invoked immediately before the receive.
272When receiving a stream from
273.Nm zfs Cm send Fl R ,
274causes the property to be inherited by all descendant datasets, as through
275.Nm zfs Cm inherit Em property
276was run on any descendant datasets that have this property set on the
277sending system.
278.Pp
279If the send stream was sent with
280.Fl c
281then overriding the
282.Sy compression
283property will have no effect on received data but the
284.Sy compression
285property will be set.
286To have the data recompressed on receive remove the
287.Fl c
288flag from the send stream.
289.Pp
290Any editable property can be set at receive time.
291Set-once properties bound
292to the received data, such as
293.Sy normalization
294and
295.Sy casesensitivity ,
296cannot be set at receive time even when the datasets are newly created by
297.Nm zfs Cm receive .
298Additionally both settable properties
299.Sy version
300and
301.Sy volsize
302cannot be set at receive time.
303.Pp
304The
305.Fl o
306option may be specified multiple times, for different properties.
307An error results if the same property is specified in multiple
308.Fl o
309or
310.Fl x
311options.
312.Pp
313The
314.Fl o
315option may also be used to override encryption properties upon initial receive.
316This allows unencrypted streams to be received as encrypted datasets.
317To cause the received dataset (or root dataset of a recursive stream) to be
318received as an encryption root, specify encryption properties in the same
319manner as is required for
320.Nm zfs Cm create .
321For instance:
322.Dl # Nm zfs Cm send Pa tank/test@snap1 | Nm zfs Cm recv Fl o Sy encryption Ns = Ns Sy on Fl o Sy keyformat Ns = Ns Sy passphrase Fl o Sy keylocation Ns = Ns Pa file:///path/to/keyfile
323.Pp
324Note that
325.Fl o Sy keylocation Ns = Ns Sy prompt
326may not be specified here, since the standard input
327is already being utilized for the send stream.
328Once the receive has completed, you can use
329.Nm zfs Cm set
330to change this setting after the fact.
331Similarly, you can receive a dataset as an encrypted child by specifying
332.Fl x Sy encryption
333to force the property to be inherited.
334Overriding encryption properties (except for
335.Sy keylocation )
336is not possible with raw send streams.
337.It Fl s
338If the receive is interrupted, save the partially received state, rather
339than deleting it.
340Interruption may be due to premature termination of the stream
341.Po e.g. due to network failure or failure of the remote system
342if the stream is being read over a network connection
343.Pc ,
344a checksum error in the stream, termination of the
345.Nm zfs Cm receive
346process, or unclean shutdown of the system.
347.Pp
348The receive can be resumed with a stream generated by
349.Nm zfs Cm send Fl t Ar token ,
350where the
351.Ar token
352is the value of the
353.Sy receive_resume_token
354property of the filesystem or volume which is received into.
355.Pp
356To use this flag, the storage pool must have the
357.Sy extensible_dataset
358feature enabled.
359See
360.Xr zpool-features 7
361for details on ZFS feature flags.
362.It Fl u
363File system that is associated with the received stream is not mounted.
364.It Fl v
365Print verbose information about the stream and the time required to perform the
366receive operation.
367.It Fl x Em property
368Ensures that the effective value of the specified property after the
369receive is unaffected by the value of that property in the send stream (if any),
370as if the property had been excluded from the send stream.
371.Pp
372If the specified property is not present in the send stream, this option does
373nothing.
374.Pp
375If a received property needs to be overridden, the effective value will be
376set or inherited, depending on whether the property is inheritable or not.
377.Pp
378In the case of an incremental update,
379.Fl x
380leaves any existing local setting or explicit inheritance unchanged.
381.Pp
382All
383.Fl o
384restrictions (e.g. set-once) apply equally to
385.Fl x .
386.El
387.It Xo
388.Nm zfs
389.Cm receive
390.Fl A
391.Ar filesystem Ns | Ns Ar volume
392.Xc
393Abort an interrupted
394.Nm zfs Cm receive Fl s ,
395deleting its saved partially received state.
396.El
397.
398.Sh EXAMPLES
399.\" These are, respectively, examples 12, 13 from zfs.8
400.\" Make sure to update them bidirectionally
401.Ss Example 1 : No Remotely Replicating ZFS Data
402The following commands send a full stream and then an incremental stream to a
403remote machine, restoring them into
404.Em poolB/received/fs@a
405and
406.Em poolB/received/fs@b ,
407respectively.
408.Em poolB
409must contain the file system
410.Em poolB/received ,
411and must not initially contain
412.Em poolB/received/fs .
413.Bd -literal -compact -offset Ds
414.No # Nm zfs Cm send Ar pool/fs@a |
415.No "   " Nm ssh Ar host Nm zfs Cm receive Ar poolB/received/fs Ns @ Ns Ar a
416.No # Nm zfs Cm send Fl i Ar a pool/fs@b |
417.No "   " Nm ssh Ar host Nm zfs Cm receive Ar poolB/received/fs
418.Ed
419.
420.Ss Example 2 : No Using the Nm zfs Cm receive Fl d No Option
421The following command sends a full stream of
422.Ar poolA/fsA/fsB@snap
423to a remote machine, receiving it into
424.Ar poolB/received/fsA/fsB@snap .
425The
426.Ar fsA/fsB@snap
427portion of the received snapshot's name is determined from the name of the sent
428snapshot.
429.Ar poolB
430must contain the file system
431.Ar poolB/received .
432If
433.Ar poolB/received/fsA
434does not exist, it is created as an empty file system.
435.Bd -literal -compact -offset Ds
436.No # Nm zfs Cm send Ar poolA/fsA/fsB@snap |
437.No "   " Nm ssh Ar host Nm zfs Cm receive Fl d Ar poolB/received
438.Ed
439.
440.Sh SEE ALSO
441.Xr zfs-send 8 ,
442.Xr zstream 8
443