1.\" SPDX-License-Identifier: CDDL-1.0 2.\" 3.\" CDDL HEADER START 4.\" 5.\" The contents of this file are subject to the terms of the 6.\" Common Development and Distribution License (the "License"). 7.\" You may not use this file except in compliance with the License. 8.\" 9.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE 10.\" or https://opensource.org/licenses/CDDL-1.0. 11.\" See the License for the specific language governing permissions 12.\" and limitations under the License. 13.\" 14.\" When distributing Covered Code, include this CDDL HEADER in each 15.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE. 16.\" If applicable, add the following below this CDDL HEADER, with the 17.\" fields enclosed by brackets "[]" replaced with your own identifying 18.\" information: Portions Copyright [yyyy] [name of copyright owner] 19.\" 20.\" CDDL HEADER END 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.\" Copyright (c) 2024, Klara, Inc. 33.\" 34.Dd October 2, 2024 35.Dt ZFS-SEND 8 36.Os 37. 38.Sh NAME 39.Nm zfs-send 40.Nd generate backup stream of ZFS dataset 41.Sh SYNOPSIS 42.Nm zfs 43.Cm send 44.Op Fl DLPVbcehnpsvw 45.Op Fl R Op Fl X Ar dataset Ns Oo , Ns Ar dataset Oc Ns … 46.Op Oo Fl I Ns | Ns Fl i Oc Ar snapshot 47.Ar snapshot 48.Nm zfs 49.Cm send 50.Op Fl DLPVcensvw 51.Op Fl i Ar snapshot Ns | Ns Ar bookmark 52.Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot 53.Nm zfs 54.Cm send 55.Fl -redact Ar redaction_bookmark 56.Op Fl DLPVcenpv 57.Op Fl i Ar snapshot Ns | Ns Ar bookmark 58.Ar snapshot 59.Nm zfs 60.Cm send 61.Op Fl PVenv 62.Fl t 63.Ar receive_resume_token 64.Nm zfs 65.Cm send 66.Op Fl PVnv 67.Fl S Ar filesystem 68.Nm zfs 69.Cm redact 70.Ar snapshot redaction_bookmark 71.Ar redaction_snapshot Ns … 72. 73.Sh DESCRIPTION 74.Bl -tag -width "" 75.It Xo 76.Nm zfs 77.Cm send 78.Op Fl DLPVbcehnpsvw 79.Op Fl R Op Fl X Ar dataset Ns Oo , Ns Ar dataset Oc Ns … 80.Op Oo Fl I Ns | Ns Fl i Oc Ar snapshot 81.Ar snapshot 82.Xc 83Creates a stream representation of the second 84.Ar snapshot , 85which is written to standard output. 86The output can be redirected to a file or to a different system 87.Po for example, using 88.Xr ssh 1 89.Pc . 90By default, a full stream is generated. 91.Bl -tag -width "-D" 92.It Fl D , -dedup 93Deduplicated send is no longer supported. 94This flag is accepted for backwards compatibility, but a regular, 95non-deduplicated stream will be generated. 96.It Fl I Ar snapshot 97Generate a stream package that sends all intermediary snapshots from the first 98snapshot to the second snapshot. 99For example, 100.Fl I Em @a Em fs@d 101is similar to 102.Fl i Em @a Em fs@b Ns \&; Fl i Em @b Em fs@c Ns \&; Fl i Em @c Em fs@d . 103The incremental source may be specified as with the 104.Fl i 105option. 106.It Fl L , -large-block 107Generate a stream which may contain blocks larger than 128 KiB. 108This flag has no effect if the 109.Sy large_blocks 110pool feature is disabled, or if the 111.Sy recordsize 112property of this filesystem has never been set above 128 KiB. 113The receiving system must have the 114.Sy large_blocks 115pool feature enabled as well. 116This flag is required if the 117.Sy large_microzap 118pool feature is active. 119See 120.Xr zpool-features 7 121for details on ZFS feature flags and the 122.Sy large_blocks 123feature. 124.It Fl P , -parsable 125Print machine-parsable verbose information about the stream package generated. 126.It Fl R , -replicate 127Generate a replication stream package, which will replicate the specified 128file system, and all descendent file systems, up to the named snapshot. 129When received, all properties, snapshots, descendent file systems, and clones 130are preserved. 131.Pp 132If the 133.Fl i 134or 135.Fl I 136flags are used in conjunction with the 137.Fl R 138flag, an incremental replication stream is generated. 139The current values of properties, and current snapshot and file system names are 140set when the stream is received. 141If the 142.Fl F 143flag is specified when this stream is received, snapshots and file systems that 144do not exist on the sending side are destroyed. 145If the 146.Fl R 147flag is used to send encrypted datasets, then 148.Fl w 149must also be specified. 150.It Fl V , -proctitle 151Set the process title to a per-second report of how much data has been sent. 152.It Fl X , -exclude Ar dataset Ns Oo , Ns Ar dataset Oc Ns … 153With 154.Fl R , 155.Fl X 156specifies a set of datasets (and, hence, their descendants), 157to be excluded from the send stream. 158The root dataset may not be excluded. 159.Fl X Ar a Fl X Ar b 160is equivalent to 161.Fl X Ar a , Ns Ar b . 162.It Fl e , -embed 163Generate a more compact stream by using 164.Sy WRITE_EMBEDDED 165records for blocks which are stored more compactly on disk by the 166.Sy embedded_data 167pool feature. 168This flag has no effect if the 169.Sy embedded_data 170feature is disabled. 171The receiving system must have the 172.Sy embedded_data 173feature enabled. 174If the 175.Sy lz4_compress 176or 177.Sy zstd_compress 178features are active on the sending system, then the receiving system must have 179the corresponding features enabled as well. 180Datasets that are sent with this flag may not be 181received as an encrypted dataset, since encrypted datasets cannot use the 182.Sy embedded_data 183feature. 184See 185.Xr zpool-features 7 186for details on ZFS feature flags and the 187.Sy embedded_data 188feature. 189.It Fl b , -backup 190Sends only received property values whether or not they are overridden by local 191settings, but only if the dataset has ever been received. 192Use this option when you want 193.Nm zfs Cm receive 194to restore received properties backed up on the sent dataset and to avoid 195sending local settings that may have nothing to do with the source dataset, 196but only with how the data is backed up. 197.It Fl c , -compressed 198Generate a more compact stream by using compressed WRITE records for blocks 199which are compressed on disk and in memory 200.Po see the 201.Sy compression 202property for details 203.Pc . 204If the 205.Sy lz4_compress 206or 207.Sy zstd_compress 208features are active on the sending system, then the receiving system must have 209the corresponding features enabled as well. 210If the 211.Sy large_blocks 212feature is enabled on the sending system but the 213.Fl L 214option is not supplied in conjunction with 215.Fl c , 216then the data will be decompressed before sending so it can be split into 217smaller block sizes. 218Streams sent with 219.Fl c 220will not have their data recompressed on the receiver side using 221.Fl o Sy compress Ns = Ar value . 222The data will stay compressed as it was from the sender. 223The new compression property will be set for future data. 224Note that uncompressed data from the sender will still attempt to 225compress on the receiver, unless you specify 226.Fl o Sy compress Ns = Em off . 227.It Fl w , -raw 228For encrypted datasets, send data exactly as it exists on disk. 229This allows backups to be taken even if encryption keys are not currently 230loaded. 231The backup may then be received on an untrusted machine since that machine will 232not have the encryption keys to read the protected data or alter it without 233being detected. 234Upon being received, the dataset will have the same encryption 235keys as it did on the send side, although the 236.Sy keylocation 237property will be defaulted to 238.Sy prompt 239if not otherwise provided. 240For unencrypted datasets, this flag will be equivalent to 241.Fl Lec . 242Note that if you do not use this flag for sending encrypted datasets, data will 243be sent unencrypted and may be re-encrypted with a different encryption key on 244the receiving system, which will disable the ability to do a raw send to that 245system for incrementals. 246.It Fl h , -holds 247Generate a stream package that includes any snapshot holds (created with the 248.Nm zfs Cm hold 249command), and indicating to 250.Nm zfs Cm receive 251that the holds be applied to the dataset on the receiving system. 252.It Fl i Ar snapshot 253Generate an incremental stream from the first 254.Ar snapshot 255.Pq the incremental source 256to the second 257.Ar snapshot 258.Pq the incremental target . 259The incremental source can be specified as the last component of the snapshot 260name 261.Po the 262.Sy @ 263character and following 264.Pc 265and it is assumed to be from the same file system as the incremental target. 266.Pp 267If the destination is a clone, the source may be the origin snapshot, which must 268be fully specified 269.Po for example, 270.Em pool/fs@origin , 271not just 272.Em @origin 273.Pc . 274.It Fl n , -dryrun 275Do a dry-run 276.Pq Qq No-op 277send. 278Do not generate any actual send data. 279This is useful in conjunction with the 280.Fl v 281or 282.Fl P 283flags to determine what data will be sent. 284In this case, the verbose output will be written to standard output 285.Po contrast with a non-dry-run, where the stream is written to standard output 286and the verbose output goes to standard error 287.Pc . 288.It Fl p , -props 289Include the dataset's properties in the stream. 290This flag is implicit when 291.Fl R 292is specified. 293The receiving system must also support this feature. 294Sends of encrypted datasets must use 295.Fl w 296when using this flag. 297.It Fl s , -skip-missing 298Allows sending a replication stream even when there are snapshots missing in the 299hierarchy. 300When a snapshot is missing, instead of throwing an error and aborting the send, 301a warning is printed to the standard error stream and the dataset to which it 302belongs 303and its descendants are skipped. 304This flag can only be used in conjunction with 305.Fl R . 306.It Fl v , -verbose 307Print verbose information about the stream package generated. 308This information includes a per-second report of how much data has been sent. 309The same report can be requested by sending 310.Dv SIGINFO 311or 312.Dv SIGUSR1 , 313regardless of 314.Fl v . 315.Pp 316The format of the stream is committed. 317You will be able to receive your streams on future versions of ZFS. 318.El 319.It Xo 320.Nm zfs 321.Cm send 322.Op Fl DLPVcenvw 323.Op Fl i Ar snapshot Ns | Ns Ar bookmark 324.Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot 325.Xc 326Generate a send stream, which may be of a filesystem, and may be incremental 327from a bookmark. 328If the destination is a filesystem or volume, the pool must be read-only, or the 329filesystem must not be mounted. 330When the stream generated from a filesystem or volume is received, the default 331snapshot name will be 332.Qq --head-- . 333.Bl -tag -width "-D" 334.It Fl D , -dedup 335Deduplicated send is no longer supported. 336This flag is accepted for backwards compatibility, but a regular, 337non-deduplicated stream will be generated. 338.It Fl L , -large-block 339Generate a stream which may contain blocks larger than 128 KiB. 340This flag has no effect if the 341.Sy large_blocks 342pool feature is disabled, or if the 343.Sy recordsize 344property of this filesystem has never been set above 128 KiB. 345The receiving system must have the 346.Sy large_blocks 347pool feature enabled as well. 348See 349.Xr zpool-features 7 350for details on ZFS feature flags and the 351.Sy large_blocks 352feature. 353.It Fl P , -parsable 354Print machine-parsable verbose information about the stream package generated. 355.It Fl c , -compressed 356Generate a more compact stream by using compressed WRITE records for blocks 357which are compressed on disk and in memory 358.Po see the 359.Sy compression 360property for details 361.Pc . 362If the 363.Sy lz4_compress 364or 365.Sy zstd_compress 366features are active on the sending system, then the receiving system must have 367the corresponding features enabled as well. 368If the 369.Sy large_blocks 370feature is enabled on the sending system but the 371.Fl L 372option is not supplied in conjunction with 373.Fl c , 374then the data will be decompressed before sending so it can be split into 375smaller block sizes. 376.It Fl w , -raw 377For encrypted datasets, send data exactly as it exists on disk. 378This allows backups to be taken even if encryption keys are not currently 379loaded. 380The backup may then be received on an untrusted machine since that machine will 381not have the encryption keys to read the protected data or alter it without 382being detected. 383Upon being received, the dataset will have the same encryption 384keys as it did on the send side, although the 385.Sy keylocation 386property will be defaulted to 387.Sy prompt 388if not otherwise provided. 389For unencrypted datasets, this flag will be equivalent to 390.Fl Lec . 391Note that if you do not use this flag for sending encrypted datasets, data will 392be sent unencrypted and may be re-encrypted with a different encryption key on 393the receiving system, which will disable the ability to do a raw send to that 394system for incrementals. 395.It Fl e , -embed 396Generate a more compact stream by using 397.Sy WRITE_EMBEDDED 398records for blocks which are stored more compactly on disk by the 399.Sy embedded_data 400pool feature. 401This flag has no effect if the 402.Sy embedded_data 403feature is disabled. 404The receiving system must have the 405.Sy embedded_data 406feature enabled. 407If the 408.Sy lz4_compress 409or 410.Sy zstd_compress 411features are active on the sending system, then the receiving system must have 412the corresponding features enabled as well. 413Datasets that are sent with this flag may not be received as an encrypted 414dataset, 415since encrypted datasets cannot use the 416.Sy embedded_data 417feature. 418See 419.Xr zpool-features 7 420for details on ZFS feature flags and the 421.Sy embedded_data 422feature. 423.It Fl i Ar snapshot Ns | Ns Ar bookmark 424Generate an incremental send stream. 425The incremental source must be an earlier snapshot in the destination's history. 426It will commonly be an earlier snapshot in the destination's file system, in 427which case it can be specified as the last component of the name 428.Po the 429.Sy # 430or 431.Sy @ 432character and following 433.Pc . 434.Pp 435If the incremental target is a clone, the incremental source can be the origin 436snapshot, or an earlier snapshot in the origin's filesystem, or the origin's 437origin, etc. 438.It Fl n , -dryrun 439Do a dry-run 440.Pq Qq No-op 441send. 442Do not generate any actual send data. 443This is useful in conjunction with the 444.Fl v 445or 446.Fl P 447flags to determine what data will be sent. 448In this case, the verbose output will be written to standard output 449.Po contrast with a non-dry-run, where the stream is written to standard output 450and the verbose output goes to standard error 451.Pc . 452.It Fl v , -verbose 453Print verbose information about the stream package generated. 454This information includes a per-second report of how much data has been sent. 455The same report can be requested by sending 456.Dv SIGINFO 457or 458.Dv SIGUSR1 , 459regardless of 460.Fl v . 461.El 462.It Xo 463.Nm zfs 464.Cm send 465.Fl -redact Ar redaction_bookmark 466.Op Fl DLPVcenpv 467.Op Fl i Ar snapshot Ns | Ns Ar bookmark 468.Ar snapshot 469.Xc 470Generate a redacted send stream. 471This send stream contains all blocks from the snapshot being sent that aren't 472included in the redaction list contained in the bookmark specified by the 473.Fl -redact 474(or 475.Fl d ) 476flag. 477The resulting send stream is said to be redacted with respect to the snapshots 478the bookmark specified by the 479.Fl -redact No flag was created with . 480The bookmark must have been created by running 481.Nm zfs Cm redact 482on the snapshot being sent. 483.Pp 484This feature can be used to allow clones of a filesystem to be made available on 485a remote system, in the case where their parent need not (or needs to not) be 486usable. 487For example, if a filesystem contains sensitive data, and it has clones where 488that sensitive data has been secured or replaced with dummy data, redacted sends 489can be used to replicate the secured data without replicating the original 490sensitive data, while still sharing all possible blocks. 491A snapshot that has been redacted with respect to a set of snapshots will 492contain all blocks referenced by at least one snapshot in the set, but will 493contain none of the blocks referenced by none of the snapshots in the set. 494In other words, if all snapshots in the set have modified a given block in the 495parent, that block will not be sent; but if one or more snapshots have not 496modified a block in the parent, they will still reference the parent's block, so 497that block will be sent. 498Note that only user data will be redacted. 499.Pp 500When the redacted send stream is received, we will generate a redacted 501snapshot. 502Due to the nature of redaction, a redacted dataset can only be used in the 503following ways: 504.Bl -enum -width "a." 505.It 506To receive, as a clone, an incremental send from the original snapshot to one 507of the snapshots it was redacted with respect to. 508In this case, the stream will produce a valid dataset when received because all 509blocks that were redacted in the parent are guaranteed to be present in the 510child's send stream. 511This use case will produce a normal snapshot, which can be used just like other 512snapshots. 513. 514.It 515To receive an incremental send from the original snapshot to something 516redacted with respect to a subset of the set of snapshots the initial snapshot 517was redacted with respect to. 518In this case, each block that was redacted in the original is still redacted 519(redacting with respect to additional snapshots causes less data to be redacted 520(because the snapshots define what is permitted, and everything else is 521redacted)). 522This use case will produce a new redacted snapshot. 523.It 524To receive an incremental send from a redaction bookmark of the original 525snapshot that was created when redacting with respect to a subset of the set of 526snapshots the initial snapshot was created with respect to 527anything else. 528A send stream from such a redaction bookmark will contain all of the blocks 529necessary to fill in any redacted data, should it be needed, because the sending 530system is aware of what blocks were originally redacted. 531This will either produce a normal snapshot or a redacted one, depending on 532whether the new send stream is redacted. 533.It 534To receive an incremental send from a redacted version of the initial 535snapshot that is redacted with respect to a subject of the set of snapshots the 536initial snapshot was created with respect to. 537A send stream from a compatible redacted dataset will contain all of the blocks 538necessary to fill in any redacted data. 539This will either produce a normal snapshot or a redacted one, depending on 540whether the new send stream is redacted. 541.It 542To receive a full send as a clone of the redacted snapshot. 543Since the stream is a full send, it definitionally contains all the data needed 544to create a new dataset. 545This use case will either produce a normal snapshot or a redacted one, depending 546on whether the full send stream was redacted. 547.El 548.Pp 549These restrictions are detected and enforced by 550.Nm zfs Cm receive ; 551a redacted send stream will contain the list of snapshots that the stream is 552redacted with respect to. 553These are stored with the redacted snapshot, and are used to detect and 554correctly handle the cases above. 555Note that for technical reasons, 556raw sends and redacted sends cannot be combined at this time. 557.It Xo 558.Nm zfs 559.Cm send 560.Op Fl PVenv 561.Fl t 562.Ar receive_resume_token 563.Xc 564Creates a send stream which resumes an interrupted receive. 565The 566.Ar receive_resume_token 567is the value of this property on the filesystem or volume that was being 568received into. 569See the documentation for 570.Nm zfs Cm receive Fl s 571for more details. 572.It Xo 573.Nm zfs 574.Cm send 575.Op Fl PVnv 576.Op Fl i Ar snapshot Ns | Ns Ar bookmark 577.Fl S 578.Ar filesystem 579.Xc 580Generate a send stream from a dataset that has been partially received. 581.Bl -tag -width "-L" 582.It Fl S , -saved 583This flag requires that the specified filesystem previously received a resumable 584send that did not finish and was interrupted. 585In such scenarios this flag 586enables the user to send this partially received state. 587Using this flag will always use the last fully received snapshot 588as the incremental source if it exists. 589.El 590.It Xo 591.Nm zfs 592.Cm redact 593.Ar snapshot redaction_bookmark 594.Ar redaction_snapshot Ns … 595.Xc 596Generate a new redaction bookmark. 597In addition to the typical bookmark information, a redaction bookmark contains 598the list of redacted blocks and the list of redaction snapshots specified. 599The redacted blocks are blocks in the snapshot which are not referenced by any 600of the redaction snapshots. 601These blocks are found by iterating over the metadata in each redaction snapshot 602to determine what has been changed since the target snapshot. 603Redaction is designed to support redacted zfs sends; see the entry for 604.Nm zfs Cm send 605for more information on the purpose of this operation. 606If a redact operation fails partway through (due to an error or a system 607failure), the redaction can be resumed by rerunning the same command. 608.El 609.Ss Redaction 610ZFS has support for a limited version of data subsetting, in the form of 611redaction. 612Using the 613.Nm zfs Cm redact 614command, a 615.Sy redaction bookmark 616can be created that stores a list of blocks containing sensitive information. 617When provided to 618.Nm zfs Cm send , 619this causes a 620.Sy redacted send 621to occur. 622Redacted sends omit the blocks containing sensitive information, 623replacing them with REDACT records. 624When these send streams are received, a 625.Sy redacted dataset 626is created. 627A redacted dataset cannot be mounted by default, since it is incomplete. 628It can be used to receive other send streams. 629In this way datasets can be used for data backup and replication, 630with all the benefits that zfs send and receive have to offer, 631while protecting sensitive information from being 632stored on less-trusted machines or services. 633.Pp 634For the purposes of redaction, there are two steps to the process. 635A redact step, and a send/receive step. 636First, a redaction bookmark is created. 637This is done by providing the 638.Nm zfs Cm redact 639command with a parent snapshot, a bookmark to be created, and a number of 640redaction snapshots. 641These redaction snapshots must be descendants of the parent snapshot, 642and they should modify data that is considered sensitive in some way. 643Any blocks of data modified by all of the redaction snapshots will 644be listed in the redaction bookmark, because it represents the truly sensitive 645information. 646When it comes to the send step, the send process will not send 647the blocks listed in the redaction bookmark, instead replacing them with 648REDACT records. 649When received on the target system, this will create a 650redacted dataset, missing the data that corresponds to the blocks in the 651redaction bookmark on the sending system. 652The incremental send streams from 653the original parent to the redaction snapshots can then also be received on 654the target system, and this will produce a complete snapshot that can be used 655normally. 656Incrementals from one snapshot on the parent filesystem and another 657can also be done by sending from the redaction bookmark, rather than the 658snapshots themselves. 659.Pp 660In order to make the purpose of the feature more clear, an example is provided. 661Consider a zfs filesystem containing four files. 662These files represent information for an online shopping service. 663One file contains a list of usernames and passwords, another contains purchase 664histories, 665a third contains click tracking data, and a fourth contains user preferences. 666The owner of this data wants to make it available for their development teams to 667test against, and their market research teams to do analysis on. 668The development teams need information about user preferences and the click 669tracking data, while the market research teams need information about purchase 670histories and user preferences. 671Neither needs access to the usernames and passwords. 672However, because all of this data is stored in one ZFS filesystem, 673it must all be sent and received together. 674In addition, the owner of the data 675wants to take advantage of features like compression, checksumming, and 676snapshots, so they do want to continue to use ZFS to store and transmit their 677data. 678Redaction can help them do so. 679First, they would make two clones of a snapshot of the data on the source. 680In one clone, they create the setup they want their market research team to see; 681they delete the usernames and passwords file, 682and overwrite the click tracking data with dummy information. 683In another, they create the setup they want the development teams 684to see, by replacing the passwords with fake information and replacing the 685purchase histories with randomly generated ones. 686They would then create a redaction bookmark on the parent snapshot, 687using snapshots on the two clones as redaction snapshots. 688The parent can then be sent, redacted, to the target 689server where the research and development teams have access. 690Finally, incremental sends from the parent snapshot to each of the clones can be 691sent 692to and received on the target server; these snapshots are identical to the 693ones on the source, and are ready to be used, while the parent snapshot on the 694target contains none of the username and password data present on the source, 695because it was removed by the redacted send operation. 696. 697.Sh SIGNALS 698See 699.Fl v . 700. 701.Sh EXAMPLES 702.\" These are, respectively, examples 12, 13 from zfs.8 703.\" Make sure to update them bidirectionally 704.Ss Example 1 : No Remotely Replicating ZFS Data 705The following commands send a full stream and then an incremental stream to a 706remote machine, restoring them into 707.Em poolB/received/fs@a 708and 709.Em poolB/received/fs@b , 710respectively. 711.Em poolB 712must contain the file system 713.Em poolB/received , 714and must not initially contain 715.Em poolB/received/fs . 716.Bd -literal -compact -offset Ds 717.No # Nm zfs Cm send Ar pool/fs@a | 718.No " " Nm ssh Ar host Nm zfs Cm receive Ar poolB/received/fs Ns @ Ns Ar a 719.No # Nm zfs Cm send Fl i Ar a pool/fs@b | 720.No " " Nm ssh Ar host Nm zfs Cm receive Ar poolB/received/fs 721.Ed 722. 723.Ss Example 2 : No Using the Nm zfs Cm receive Fl d No Option 724The following command sends a full stream of 725.Ar poolA/fsA/fsB@snap 726to a remote machine, receiving it into 727.Ar poolB/received/fsA/fsB@snap . 728The 729.Ar fsA/fsB@snap 730portion of the received snapshot's name is determined from the name of the sent 731snapshot. 732.Ar poolB 733must contain the file system 734.Ar poolB/received . 735If 736.Ar poolB/received/fsA 737does not exist, it is created as an empty file system. 738.Bd -literal -compact -offset Ds 739.No # Nm zfs Cm send Ar poolA/fsA/fsB@snap | 740.No " " Nm ssh Ar host Nm zfs Cm receive Fl d Ar poolB/received 741.Ed 742. 743.Sh SEE ALSO 744.Xr zfs-bookmark 8 , 745.Xr zfs-receive 8 , 746.Xr zfs-redact 8 , 747.Xr zfs-snapshot 8 748