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