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