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.
8 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9 .\" or https://opensource.org/licenses/CDDL-1.0.
10 .\" See the License for the specific language governing permissions
11 .\" and limitations under the License.
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]
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 .\" Copyright (c) 2024, Klara, Inc.
39 .Nd generate backup stream of ZFS dataset
44 .Op Fl R Op Fl X Ar dataset Ns Oo , Ns Ar dataset Oc Ns …
45 .Op Oo Fl I Ns | Ns Fl i Oc Ar snapshot
50 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
51 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
54 .Fl -redact Ar redaction_bookmark
56 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
62 .Ar receive_resume_token
69 .Ar snapshot redaction_bookmark
70 .Ar redaction_snapshot Ns …
78 .Op Fl R Op Fl X Ar dataset Ns Oo , Ns Ar dataset Oc Ns …
79 .Op Oo Fl I Ns | Ns Fl i Oc Ar snapshot
82 Creates a stream representation of the second
84 which is written to standard output.
85 The output can be redirected to a file or to a different system
86 .Po for example, using
89 By default, a full stream is generated.
92 Deduplicated send is no longer supported.
93 This flag is accepted for backwards compatibility, but a regular,
94 non-deduplicated stream will be generated.
96 Generate a stream package that sends all intermediary snapshots from the first
97 snapshot to the second snapshot.
101 .Fl i Em @a Em fs@b Ns \&; Fl i Em @b Em fs@c Ns \&; Fl i Em @c Em fs@d .
102 The incremental source may be specified as with the
105 .It Fl L , -large-block
106 Generate a stream which may contain blocks larger than 128 KiB.
107 This flag has no effect if the
109 pool feature is disabled, or if the
111 property of this filesystem has never been set above 128 KiB.
112 The receiving system must have the
114 pool feature enabled as well.
115 This flag is required if the
117 pool feature is active.
120 for details on ZFS feature flags and the
124 Print machine-parsable verbose information about the stream package generated.
125 .It Fl R , -replicate
126 Generate a replication stream package, which will replicate the specified
127 file system, and all descendent file systems, up to the named snapshot.
128 When received, all properties, snapshots, descendent file systems, and clones
135 flags are used in conjunction with the
137 flag, an incremental replication stream is generated.
138 The current values of properties, and current snapshot and file system names are
139 set when the stream is received.
142 flag is specified when this stream is received, snapshots and file systems that
143 do not exist on the sending side are destroyed.
146 flag is used to send encrypted datasets, then
148 must also be specified.
149 .It Fl V , -proctitle
150 Set the process title to a per-second report of how much data has been sent.
151 .It Fl X , -exclude Ar dataset Ns Oo , Ns Ar dataset Oc Ns …
155 specifies a set of datasets (and, hence, their descendants),
156 to be excluded from the send stream.
157 The root dataset may not be excluded.
160 .Fl X Ar a , Ns Ar b .
162 Generate a more compact stream by using
164 records for blocks which are stored more compactly on disk by the
167 This flag has no effect if the
170 The receiving system must have the
175 feature is active on the sending system, then the receiving system must have
176 that feature enabled as well.
177 Datasets that are sent with this flag may not be
178 received as an encrypted dataset, since encrypted datasets cannot use the
183 for details on ZFS feature flags and the
187 Sends only received property values whether or not they are overridden by local
188 settings, but only if the dataset has ever been received.
189 Use this option when you want
191 to restore received properties backed up on the sent dataset and to avoid
192 sending local settings that may have nothing to do with the source dataset,
193 but only with how the data is backed up.
194 .It Fl c , -compressed
195 Generate a more compact stream by using compressed WRITE records for blocks
196 which are compressed on disk and in memory
203 feature is active on the sending system, then the receiving system must have
204 that feature enabled as well.
207 feature is enabled on the sending system but the
209 option is not supplied in conjunction with
211 then the data will be decompressed before sending so it can be split into
215 will not have their data recompressed on the receiver side using
216 .Fl o Sy compress Ns = Ar value .
217 The data will stay compressed as it was from the sender.
218 The new compression property will be set for future data.
219 Note that uncompressed data from the sender will still attempt to
220 compress on the receiver, unless you specify
221 .Fl o Sy compress Ns = Em off .
223 For encrypted datasets, send data exactly as it exists on disk.
224 This allows backups to be taken even if encryption keys are not currently
226 The backup may then be received on an untrusted machine since that machine will
227 not have the encryption keys to read the protected data or alter it without
229 Upon being received, the dataset will have the same encryption
230 keys as it did on the send side, although the
232 property will be defaulted to
234 if not otherwise provided.
235 For unencrypted datasets, this flag will be equivalent to
237 Note that if you do not use this flag for sending encrypted datasets, data will
238 be sent unencrypted and may be re-encrypted with a different encryption key on
239 the receiving system, which will disable the ability to do a raw send to that
240 system for incrementals.
242 Generate a stream package that includes any snapshot holds (created with the
244 command), and indicating to
246 that the holds be applied to the dataset on the receiving system.
248 Generate an incremental stream from the first
250 .Pq the incremental source
253 .Pq the incremental target .
254 The incremental source can be specified as the last component of the snapshot
258 character and following
260 and it is assumed to be from the same file system as the incremental target.
262 If the destination is a clone, the source may be the origin snapshot, which must
273 Do not generate any actual send data.
274 This is useful in conjunction with the
278 flags to determine what data will be sent.
279 In 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
281 and the verbose output goes to standard error
284 Include the dataset's properties in the stream.
285 This flag is implicit when
288 The receiving system must also support this feature.
289 Sends of encrypted datasets must use
291 when using this flag.
292 .It Fl s , -skip-missing
293 Allows sending a replication stream even when there are snapshots missing in the
295 When a snapshot is missing, instead of throwing an error and aborting the send,
296 a warning is printed to the standard error stream and the dataset to which it
298 and its descendents are skipped.
299 This flag can only be used in conjunction with
302 Print verbose information about the stream package generated.
303 This information includes a per-second report of how much data has been sent.
304 The same report can be requested by sending
311 The format of the stream is committed.
312 You will be able to receive your streams on future versions of ZFS.
318 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
319 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
321 Generate a send stream, which may be of a filesystem, and may be incremental
323 If the destination is a filesystem or volume, the pool must be read-only, or the
324 filesystem must not be mounted.
325 When the stream generated from a filesystem or volume is received, the default
326 snapshot name will be
330 Deduplicated send is no longer supported.
331 This flag is accepted for backwards compatibility, but a regular,
332 non-deduplicated stream will be generated.
333 .It Fl L , -large-block
334 Generate a stream which may contain blocks larger than 128 KiB.
335 This flag has no effect if the
337 pool feature is disabled, or if the
339 property of this filesystem has never been set above 128 KiB.
340 The receiving system must have the
342 pool feature enabled as well.
345 for details on ZFS feature flags and the
349 Print machine-parsable verbose information about the stream package generated.
350 .It Fl c , -compressed
351 Generate a more compact stream by using compressed WRITE records for blocks
352 which are compressed on disk and in memory
359 feature is active on the sending system, then the receiving system must have
360 that feature enabled as well.
363 feature is enabled on the sending system but the
365 option is not supplied in conjunction with
367 then the data will be decompressed before sending so it can be split into
370 For encrypted datasets, send data exactly as it exists on disk.
371 This allows backups to be taken even if encryption keys are not currently
373 The backup may then be received on an untrusted machine since that machine will
374 not have the encryption keys to read the protected data or alter it without
376 Upon being received, the dataset will have the same encryption
377 keys as it did on the send side, although the
379 property will be defaulted to
381 if not otherwise provided.
382 For unencrypted datasets, this flag will be equivalent to
384 Note that if you do not use this flag for sending encrypted datasets, data will
385 be sent unencrypted and may be re-encrypted with a different encryption key on
386 the receiving system, which will disable the ability to do a raw send to that
387 system for incrementals.
389 Generate a more compact stream by using
391 records for blocks which are stored more compactly on disk by the
394 This flag has no effect if the
397 The receiving system must have the
402 feature is active on the sending system, then the receiving system must have
403 that feature enabled as well.
404 Datasets that are sent with this flag may not be received as an encrypted
406 since encrypted datasets cannot use the
411 for details on ZFS feature flags and the
414 .It Fl i Ar snapshot Ns | Ns Ar bookmark
415 Generate an incremental send stream.
416 The incremental source must be an earlier snapshot in the destination's history.
417 It will commonly be an earlier snapshot in the destination's file system, in
418 which case it can be specified as the last component of the name
423 character and following
426 If the incremental target is a clone, the incremental source can be the origin
427 snapshot, or an earlier snapshot in the origin's filesystem, or the origin's
433 Do not generate any actual send data.
434 This is useful in conjunction with the
438 flags to determine what data will be sent.
439 In this case, the verbose output will be written to standard output
440 .Po contrast with a non-dry-run, where the stream is written to standard output
441 and the verbose output goes to standard error
444 Print verbose information about the stream package generated.
445 This information includes a per-second report of how much data has been sent.
446 The same report can be requested by sending
456 .Fl -redact Ar redaction_bookmark
458 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
461 Generate a redacted send stream.
462 This send stream contains all blocks from the snapshot being sent that aren't
463 included in the redaction list contained in the bookmark specified by the
468 The resulting send stream is said to be redacted with respect to the snapshots
469 the bookmark specified by the
470 .Fl -redact No flag was created with .
471 The bookmark must have been created by running
473 on the snapshot being sent.
475 This feature can be used to allow clones of a filesystem to be made available on
476 a remote system, in the case where their parent need not (or needs to not) be
478 For example, if a filesystem contains sensitive data, and it has clones where
479 that sensitive data has been secured or replaced with dummy data, redacted sends
480 can be used to replicate the secured data without replicating the original
481 sensitive data, while still sharing all possible blocks.
482 A snapshot that has been redacted with respect to a set of snapshots will
483 contain all blocks referenced by at least one snapshot in the set, but will
484 contain none of the blocks referenced by none of the snapshots in the set.
485 In other words, if all snapshots in the set have modified a given block in the
486 parent, that block will not be sent; but if one or more snapshots have not
487 modified a block in the parent, they will still reference the parent's block, so
488 that block will be sent.
489 Note that only user data will be redacted.
491 When the redacted send stream is received, we will generate a redacted
493 Due to the nature of redaction, a redacted dataset can only be used in the
495 .Bl -enum -width "a."
497 To receive, as a clone, an incremental send from the original snapshot to one
498 of the snapshots it was redacted with respect to.
499 In this case, the stream will produce a valid dataset when received because all
500 blocks that were redacted in the parent are guaranteed to be present in the
502 This use case will produce a normal snapshot, which can be used just like other
506 To receive an incremental send from the original snapshot to something
507 redacted with respect to a subset of the set of snapshots the initial snapshot
508 was redacted with respect to.
509 In this case, each block that was redacted in the original is still redacted
510 (redacting with respect to additional snapshots causes less data to be redacted
511 (because the snapshots define what is permitted, and everything else is
513 This use case will produce a new redacted snapshot.
515 To receive an incremental send from a redaction bookmark of the original
516 snapshot that was created when redacting with respect to a subset of the set of
517 snapshots the initial snapshot was created with respect to
519 A send stream from such a redaction bookmark will contain all of the blocks
520 necessary to fill in any redacted data, should it be needed, because the sending
521 system is aware of what blocks were originally redacted.
522 This will either produce a normal snapshot or a redacted one, depending on
523 whether the new send stream is redacted.
525 To receive an incremental send from a redacted version of the initial
526 snapshot that is redacted with respect to a subject of the set of snapshots the
527 initial snapshot was created with respect to.
528 A send stream from a compatible redacted dataset will contain all of the blocks
529 necessary to fill in any redacted data.
530 This will either produce a normal snapshot or a redacted one, depending on
531 whether the new send stream is redacted.
533 To receive a full send as a clone of the redacted snapshot.
534 Since the stream is a full send, it definitionally contains all the data needed
535 to create a new dataset.
536 This use case will either produce a normal snapshot or a redacted one, depending
537 on whether the full send stream was redacted.
540 These restrictions are detected and enforced by
542 a redacted send stream will contain the list of snapshots that the stream is
543 redacted with respect to.
544 These are stored with the redacted snapshot, and are used to detect and
545 correctly handle the cases above.
546 Note that for technical reasons,
547 raw sends and redacted sends cannot be combined at this time.
553 .Ar receive_resume_token
555 Creates a send stream which resumes an interrupted receive.
557 .Ar receive_resume_token
558 is the value of this property on the filesystem or volume that was being
560 See the documentation for
561 .Nm zfs Cm receive Fl s
567 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
571 Generate a send stream from a dataset that has been partially received.
574 This flag requires that the specified filesystem previously received a resumable
575 send that did not finish and was interrupted.
576 In such scenarios this flag
577 enables the user to send this partially received state.
578 Using this flag will always use the last fully received snapshot
579 as the incremental source if it exists.
584 .Ar snapshot redaction_bookmark
585 .Ar redaction_snapshot Ns …
587 Generate a new redaction bookmark.
588 In addition to the typical bookmark information, a redaction bookmark contains
589 the list of redacted blocks and the list of redaction snapshots specified.
590 The redacted blocks are blocks in the snapshot which are not referenced by any
591 of the redaction snapshots.
592 These blocks are found by iterating over the metadata in each redaction snapshot
593 to determine what has been changed since the target snapshot.
594 Redaction is designed to support redacted zfs sends; see the entry for
596 for more information on the purpose of this operation.
597 If a redact operation fails partway through (due to an error or a system
598 failure), the redaction can be resumed by rerunning the same command.
601 ZFS has support for a limited version of data subsetting, in the form of
606 .Sy redaction bookmark
607 can be created that stores a list of blocks containing sensitive information.
613 Redacted sends omit the blocks containing sensitive information,
614 replacing them with REDACT records.
615 When these send streams are received, a
618 A redacted dataset cannot be mounted by default, since it is incomplete.
619 It can be used to receive other send streams.
620 In this way datasets can be used for data backup and replication,
621 with all the benefits that zfs send and receive have to offer,
622 while protecting sensitive information from being
623 stored on less-trusted machines or services.
625 For the purposes of redaction, there are two steps to the process.
626 A redact step, and a send/receive step.
627 First, a redaction bookmark is created.
628 This is done by providing the
630 command with a parent snapshot, a bookmark to be created, and a number of
632 These redaction snapshots must be descendants of the parent snapshot,
633 and they should modify data that is considered sensitive in some way.
634 Any blocks of data modified by all of the redaction snapshots will
635 be listed in the redaction bookmark, because it represents the truly sensitive
637 When it comes to the send step, the send process will not send
638 the blocks listed in the redaction bookmark, instead replacing them with
640 When received on the target system, this will create a
641 redacted dataset, missing the data that corresponds to the blocks in the
642 redaction bookmark on the sending system.
643 The incremental send streams from
644 the original parent to the redaction snapshots can then also be received on
645 the target system, and this will produce a complete snapshot that can be used
647 Incrementals from one snapshot on the parent filesystem and another
648 can also be done by sending from the redaction bookmark, rather than the
649 snapshots themselves.
651 In order to make the purpose of the feature more clear, an example is provided.
652 Consider a zfs filesystem containing four files.
653 These files represent information for an online shopping service.
654 One file contains a list of usernames and passwords, another contains purchase
656 a third contains click tracking data, and a fourth contains user preferences.
657 The owner of this data wants to make it available for their development teams to
658 test against, and their market research teams to do analysis on.
659 The development teams need information about user preferences and the click
660 tracking data, while the market research teams need information about purchase
661 histories and user preferences.
662 Neither needs access to the usernames and passwords.
663 However, because all of this data is stored in one ZFS filesystem,
664 it must all be sent and received together.
665 In addition, the owner of the data
666 wants to take advantage of features like compression, checksumming, and
667 snapshots, so they do want to continue to use ZFS to store and transmit their
669 Redaction can help them do so.
670 First, they would make two clones of a snapshot of the data on the source.
671 In one clone, they create the setup they want their market research team to see;
672 they delete the usernames and passwords file,
673 and overwrite the click tracking data with dummy information.
674 In another, they create the setup they want the development teams
675 to see, by replacing the passwords with fake information and replacing the
676 purchase histories with randomly generated ones.
677 They would then create a redaction bookmark on the parent snapshot,
678 using snapshots on the two clones as redaction snapshots.
679 The parent can then be sent, redacted, to the target
680 server where the research and development teams have access.
681 Finally, incremental sends from the parent snapshot to each of the clones can be
683 to and received on the target server; these snapshots are identical to the
684 ones on the source, and are ready to be used, while the parent snapshot on the
685 target contains none of the username and password data present on the source,
686 because it was removed by the redacted send operation.
693 .\" These are, respectively, examples 12, 13 from zfs.8
694 .\" Make sure to update them bidirectionally
695 .Ss Example 1 : No Remotely Replicating ZFS Data
696 The following commands send a full stream and then an incremental stream to a
697 remote machine, restoring them into
698 .Em poolB/received/fs@a
700 .Em poolB/received/fs@b ,
703 must contain the file system
705 and must not initially contain
706 .Em poolB/received/fs .
707 .Bd -literal -compact -offset Ds
708 .No # Nm zfs Cm send Ar pool/fs@a |
709 .No " " Nm ssh Ar host Nm zfs Cm receive Ar poolB/received/fs Ns @ Ns Ar a
710 .No # Nm zfs Cm send Fl i Ar a pool/fs@b |
711 .No " " Nm ssh Ar host Nm zfs Cm receive Ar poolB/received/fs
714 .Ss Example 2 : No Using the Nm zfs Cm receive Fl d No Option
715 The following command sends a full stream of
716 .Ar poolA/fsA/fsB@snap
717 to a remote machine, receiving it into
718 .Ar poolB/received/fsA/fsB@snap .
721 portion of the received snapshot's name is determined from the name of the sent
724 must contain the file system
727 .Ar poolB/received/fsA
728 does not exist, it is created as an empty file system.
729 .Bd -literal -compact -offset Ds
730 .No # Nm zfs Cm send Ar poolA/fsA/fsB@snap |
731 .No " " Nm ssh Ar host Nm zfs Cm receive Fl d Ar poolB/received