Suppose I have a fileserver, which may be zpool 10, 14, or 15. No compression, no dedup. Suppose I have a backupserver. I want to zfs send from the fileserver to the backupserver, and I want the backupserver to receive and store compressed and/or dedup''d. The backupserver can be a more recent version of zpool than the fileserver, but right now, whatever they are, they''re the same as each other. And I think it''s 10, and I think I have 15 available if I upgrade them. (Obviously I can get accurate details on the exact versions, if it matters.) I have created the destination filesystem with compression. And now my question ... Can I "zfs send" from the fileserver to the backupserver and expect it to be compressed and/or dedup''d upon receive? Does "zfs send" preserve the properties of the originating filesystem? Will the "zfs receive" clobber or ignore the compression / dedup options on the destination filesystem? I''m doing it now. So I guess the question here is sort of academic. ;-) I''ll know the answer tomorrow, either way. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100708/0cdd4834/attachment.html>
On 07/ 9/10 09:21 AM, Edward Ned Harvey wrote:> > Suppose I have a fileserver, which may be zpool 10, 14, or 15. No > compression, no dedup. > > Suppose I have a backupserver. I want to zfs send from the fileserver > to the backupserver, and I want the backupserver to receive and store > compressed and/or dedup''d. The backupserver can be a more recent > version of zpool than the fileserver, but right now, whatever they > are, they''re the same as each other. And I think it''s 10, and I think > I have 15 available if I upgrade them. (Obviously I can get accurate > details on the exact versions, if it matters.) > > I have created the destination filesystem with compression. And now > my question ... > > Can I "zfs send" from the fileserver to the backupserver and expect it > to be compressed and/or dedup''d upon receive? Does "zfs send" > preserve the properties of the originating filesystem? Will the "zfs > receive" clobber or ignore the compression / dedup options on the > destination filesystem? >Yes. Unless they are explicitly set on the source file system. I replicate to a build 134 box with dedup enabled from an older server. -- Ian.
On Thu, Jul 8, 2010 at 2:21 PM, Edward Ned Harvey <solaris2 at nedharvey.com> wrote:> Can I "zfs send" from the fileserver to the backupserver and expect it tobe> compressed and/or dedup''d upon receive? Does "zfs send" preserve the > properties of the originating filesystem? Will the "zfs receive" clobberor> ignore the compression / dedup options on the destination filesystem?If you set a property on the dataset that you''re sending, then it''ll overwrite what''s on the receiving end if you used ''zfs send -R'' or ''zfs send -p''. You can get around this by sending only a snapshot without -R or -p, then using -I to get intermediate snapshots for every dataset. If the destination dataset has the property set on it, then it''ll be overwritten if you used ''zfs send -R'' or ''zfs send -p''. If the source inherited the property from a parent and the destination inherits the property, then it won''t be overwritten. Personally, I''ve started organizing datasets in a hierarchy, setting the properties that I want for descendant datasets at a level where it will apply to everything that I want to get it. So if you have your source at tank/export/foo and your destination is tank2/export/foo, you''d want to set compression, etc at tank/export or tank2/export. If you''re going to have a newer zfs version on the destination, be aware that you can''t receive from datasets with a higher version than the destination. -B -- Brandon High : bhigh at freaks.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100708/f187c871/attachment.html>
On 07/ 9/10 10:59 AM, Brandon High wrote:> > Personally, I''ve started organizing datasets in a hierarchy, setting > the properties that I want for descendant datasets at a level where it > will apply to everything that I want to get it. So if you have your > source at tank/export/foo and your destination is tank2/export/foo, > you''d want to set compression, etc at tank/export or tank2/export. >I believe that is the best way to go. I tend to set key attributes such as compress at the root and change on filesystems where they are not appropriate. My backup server has compress and dedup on at the root, along with atime=off and readonly=on.> If you''re going to have a newer zfs version on the destination, be > aware that you can''t receive from datasets with a higher version than > the destination. >Yes, one to watch for recovery! You can set the filesystem version explicitly, but then you loose the newer version''s features. -- Ian.