xref: /freebsd/sys/contrib/openzfs/man/man8/zfs-send.8 (revision cb2887746f8b9dd4ad6b1e757cdc053a08b25a2e)
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