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