zfs discuss - Nov 2009 - "zfs send" from solaris 10/08 to "zfs receive" on solaris 10/09

I built a fileserver on solaris 10u6 (10/08) intending to back it up to
another server via zfs send | ssh othermachine ''zfs receive''

However, the new server is too new for 10u6 (10/08) and requires a later
version of solaris . presently available is 10u8 (10/09)

 

Is it crazy for me to try the send/receive with these two different versions
of OSes?

 

Is it possible the underlying ZFS''s would be compatible?  Is there any
way
for me to know?

 

Thanks for the help.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091112/f4952d51/attachment.html>

On Thu, November 12, 2009 13:36, Edward Ned Harvey
wrote:
> I built a fileserver on solaris 10u6 (10/08) intending to back it up to
> another server via zfs send | ssh othermachine ''zfs
receive''
>
> However, the new server is too new for 10u6 (10/08) and requires a later
> version of solaris . presently available is 10u8 (10/09)
>
> Is it crazy for me to try the send/receive with these two different
> versions of OSes?
It says at the end of the zfs send section of the man page "The format of
the stream is committed. You will be able to receive your streams on
future versions of ZFS."

That would seem to be a rather strong general commitment.  That makes it
IMHO at least worth experimenting with the case you need, see if it
accepts the stream.  It should, according to the man page.
-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

David Dyer-Bennet wrote:
> On Thu, November 12, 2009 13:36, Edward Ned Harvey wrote:
>   
>> I built a fileserver on solaris 10u6 (10/08) intending to back it up to
>> another server via zfs send | ssh othermachine ''zfs
receive''
>>
>> However, the new server is too new for 10u6 (10/08) and requires a
later
>> version of solaris . presently available is 10u8 (10/09)
>>
>> Is it crazy for me to try the send/receive with these two different
>> versions of OSes?
>>     
>
> It says at the end of the zfs send section of the man page "The format
of
> the stream is committed. You will be able to receive your streams on
> future versions of ZFS."
>
> That would seem to be a rather strong general commitment.  That makes it
> IMHO at least worth experimenting with the case you need, see if it
> accepts the stream.  It should, according to the man page.
>   
Like so many other things in Solaris,  older revs of ZFS are supported 
in newer releases of Solaris.  :-)

When you create a zfs filesystem on a version of Solaris, by default it 
is created by the latest ZFS fs version that version of Solaris supports.

HOWEVER, you can explicitly create a zfs filesystem with a backrev 
version, and it works fine (you just don''t get the latest features).  
Look at the ZFS man page for creating a filesystem with a version other 
than the default.

This works for ''zfs send|receive'', with this caveaut:   the
receiving
filesytem will be created with the zfs filesystem version of the SENDER.

So, it''s possible to send/receive a ZFS filesystem from a OLDER version
of Solaris to a NEWER version, but NOT vice versa (unless the zfs 
filesystem on the newer Solaris was explicitly created with a backrev 
version that the older Solaris understands).

An example:  (and, I''m sure I don''t have the ZFS version
numbers right,
so check the man pages)

Say 10u6 supports ZFS version 10, and 10u8 support ZFS version 12.

By default, a 10u6 machine creates v10 ZFS filesystems, and 10u8 creates 
v12 filesystems.  But, a 10u8 systems can also create v10 filesystems.  
So, you can send a 10u6 ZFS filesystem to a 10u8 machine, resulting in 
creating a new v10 filesystem on the 10u8 machine.  However, you can''t 
send a v12 filesystem from the 10u8 machine to the 10u6 machine.  If you 
explicitly create a v10 filesystem on the 10u8 machine, you can send 
that filesystem to the 10u6 machine.


I hope that''s clear.

-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

> *snip*
> I hope that''s clear.
Yes, perfectly clear, and very helpful.  Thank you very much.

On 12 Nov 2009, at 19:54, "David Dyer-Bennet" <dd-b at dd-b.net>
wrote:
>
> On Thu, November 12, 2009 13:36, Edward Ned Harvey wrote:
>> I built a fileserver on solaris 10u6 (10/08) intending to back it  
>> up to
>> another server via zfs send | ssh othermachine ''zfs
receive''
>>
>> However, the new server is too new for 10u6 (10/08) and requires a  
>> later
>> version of solaris . presently available is 10u8 (10/09)
>>
>> Is it crazy for me to try the send/receive with these two different
>> versions of OSes?
>
> It says at the end of the zfs send section of the man page "The  
> format of the stream is committed. You will be able to receive your  
> streams on
> future versions of ZFS."
''Twas not always so. It used to say "The format of the stream is  
evolving. No backwards compatibility is guaranteed. You may not be  
able to receive your streams on future versions of ZFS."

See http://hub.opensolaris.org/bin/view/Community+Group+on/2008042301

However, the above states that you''re ok within Solaris 10 (which got  
a usable ZFS quite late in the day - you were very brave if you used  
the s10u3 implementation), and I''ve only fallen foul of the issue with
old Nevada and OpenSolaris versions.

> That would seem to be a rather strong general commitment.  That  
> makes it
> IMHO at least worth experimenting with the case you need, see if it
> accepts the stream.  It should, according to the man page.
> -- 
> David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
> Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
> Photos: http://dd-b.net/photography/gallery/
> Dragaera: http://dragaera.info
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On 12 Nov 2009, at 19:54, "David Dyer-Bennet" <dd-b at dd-b.net>
wrote:
>
> On Thu, November 12, 2009 13:36, Edward Ned Harvey wrote:
>> I built a fileserver on solaris 10u6 (10/08) intending to back it  
>> up to
>> another server via zfs send | ssh othermachine ''zfs
receive''
>>
>> However, the new server is too new for 10u6 (10/08) and requires a  
>> later
>> version of solaris . presently available is 10u8 (10/09)
>>
>> Is it crazy for me to try the send/receive with these two different
>> versions of OSes?
>
> It says at the end of the zfs send section of the man page "The  
> format of the stream is committed. You will be able to receive your  
> streams on
> future versions of ZFS."
Twas not always so. It used to say


http://hub.opensolaris.org/bin/view/Community+Group+on/2008042301
>
> That would seem to be a rather strong general commitment.  That  
> makes it
> IMHO at least worth experimenting with the case you need, see if it
> accepts the stream.  It should, according to the man page.
> -- 
> David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
> Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
> Photos: http://dd-b.net/photography/gallery/
> Dragaera: http://dragaera.info
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091113/59fad13d/attachment.html>

> It says at the end of the zfs send section of the man page "The format
> of the stream is committed. You will be able to receive your streams on
> future versions of ZFS."
> 
> ''Twas not always so. It used to say "The format of the stream
is
> evolving. No backwards compatibility is guaranteed. You may not be able
> to receive your streams on future versions of ZFS."
> 
> See http://hub.opensolaris.org/bin/view/Community+Group+on/2008042301
Thanks, Phil.
I knew I read the man page in its entirety at one point, and had just cause to
be nervous, and when this comment basically "read the man page" came
out - and it was obvious now that there''s no problem - I knew it
sounded like news to me.

Thanks for the clarification.  I feel even more sane now.  ;-)

>>>>> "ph" == Phil Harman <phil.harman at
gmail.com> writes:
    >> "The format of the stream is committed. You will be able to
    >> receive your streams on future versions of ZFS."

What Erik said is stronger than the man page in an important way,
though.  He said you can dump an old stream into a filesystem on a new
zpool, and when you ''zfs send'' the stream back out,
it''ll be in the
old format.  Keeping this commitment means you can store s10 streams
on snv_xxx backup servers as expanded filesystems, not
stream-inside-a-file, and still restore them onto s10 by ''zfs
send''ing
from nevada.  One reason this makes sense as something one might
actually do because zpools are a lot more resilient to corruption than
''zfs send'' streams.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091114/f34235ee/attachment.bin>

Miles Nordin wrote:
>>>>>> "ph" == Phil Harman <phil.harman at
gmail.com> writes:
>>>>>>             
>
>     >> "The format of the stream is committed. You will be able
to
>     >> receive your streams on future versions of ZFS."
>
> What Erik said is stronger than the man page in an important way,
> though.  He said you can dump an old stream into a filesystem on a new
> zpool, and when you ''zfs send'' the stream back out,
it''ll be in the
> old format.  Keeping this commitment means you can store s10 streams
> on snv_xxx backup servers as expanded filesystems, not
> stream-inside-a-file, and still restore them onto s10 by ''zfs
send''ing
> from nevada.  One reason this makes sense as something one might
> actually do because zpools are a lot more resilient to corruption than
> ''zfs send'' streams.
>   
>   
It also came in very handy for me to archive a stream that caused a 
panic on Solaris 10.  I was able to resend the stream to test patches.

-- 
Ian.

Yes indeed, but my point was that it was not always so. This change  
was something I and others campaigned for quite some time ago.

Indeed, in the early days of ZFS evangelism (when I was still at Sun)  
the issue came up rather often. In those days there were even more  
reasons not to use a zfs send stream as a backup.

My point was made partly to celebrate this welcome change (as  
reflected in the manpage) because I was pleasantly surprised to find  
that the change we had requested has already been delivered.

The other reason for my point was to remind people that there may be  
system out there for which this may not be the case, in which the old  
restrictions still hold until the relevant patches and/or upgrades  
have been applied.

Indeed, the heads up link I posted seems to imply that there are still  
some older versions of ZFS stream format which cannot be imported -  
that backwards compatibility has its reasonable limits.

When it come to Erik''s exciting  extention beyond what is already good
news, perhaps the manpage needs to be stronger? It would be a shame  
for such useful information to be accessible only to random googlers  
and the august readers of this list.

On 14 Nov 2009, at 17:58, Miles Nordin <carton at Ivy.NET> wrote:
>>>>>> "ph" == Phil Harman <phil.harman at
gmail.com> writes:
>
>>> "The format of the stream is committed. You will be able to
>>> receive your streams on future versions of ZFS."
>
> What Erik said is stronger than the man page in an important way,
> though.  He said you can dump an old stream into a filesystem on a new
> zpool, and when you ''zfs send'' the stream back out,
it''ll be in the
> old format.  Keeping this commitment means you can store s10 streams
> on snv_xxx backup servers as expanded filesystems, not
> stream-inside-a-file, and still restore them onto s10 by ''zfs
send''ing
> from nevada.  One reason this makes sense as something one might
> actually do because zpools are a lot more resilient to corruption than
> ''zfs send'' streams.
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss