After moving from SXCE to 2009.06, my ZFS pools/file systems were at too new of a version. I upgraded to the latest dev and recently upgraded to 122, but am not too thrilled with the instability, especially zfs send / recv lockups (don''t recall the bug number). I keep a copy of all of my critical stuff along with the original auto snapshots on a USB drive. I really want to move back to 2009.06 and keep all of my files / snapshots. Is there a way somehow to zfs send an older stream that 2009.06 will read so that I can import that into 2009.06? Can I even create an older pool/dataset using 122? Ideally I would provision an older version of the data and simply reinstall 2009.06 and just import the pool created under 122. It seems this would be a regular request. If I understand it correctly, an older BE cannot read upgraded pools and file systems, so a boot image upgrade followed by a zfs and zpool upgrade would kill a shop''s ability to fall back. Or am I mistaken? Is there a way to send older streams? Thanks, Marty -- This message posted from opensolaris.org
On Mon, 14 Sep 2009, Marty Scholes wrote:> I really want to move back to 2009.06 and keep all of my files / > snapshots. Is there a way somehow to zfs send an older stream that > 2009.06 will read so that I can import that into 2009.06? > > Can I even create an older pool/dataset using 122? Ideally I would > provision an older version of the data and simply reinstall 2009.06 and > just import the pool created under 122.The zfs send stream is dependent on the version of the filesystem, so the only way to create an older stream is to create a back-versioned filesystem: zfs create -o version=N pool/filesystem You can see what versions your system supports by using the zfs upgrade command: # zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and File system unique identifer (FUID) 4 userquota, groupquota properties For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/zpl/N Where ''N'' is the version number. # Of course, creating a version 3 or earlier system will not allow you to use user & group quotas, for example, but at least you''ll be able to zfs-send that filesystem to a version of zfs that can only understand the earlier versions.> It seems this would be a regular request. If I understand it correctly, > an older BE cannot read upgraded pools and file systems, so a boot image > upgrade followed by a zfs and zpool upgrade would kill a shop''s ability > to fall back. Or am I mistaken?You''re not mistaken. Regards, markm
On 09/15/09 02:07 PM, Mark J Musante wrote:> zfs create -o version=N pool/filesystemis possible to implement into a future version of ZFS a "released" send command, like: # zfs send -r2 <snap> ... to send a specific release (version 2 in the example) of the metadata? -- Luca Morettoni <luca(AT)morettoni.net> | OpenSolaris SCA #OS0344 Web/BLOG: http://www.morettoni.net/ | http://twitter.com/morettoni jugUmbria founder - https://jugUmbria.dev.java.net/ | Thawte notary ITL-OSUG leader - http://www.opensolaris.org/os/project/itl-osug/
> The zfs send stream is dependent on the version of > the filesystem, so the > only way to create an older stream is to create a > back-versioned > filesystem: > > zfs create -o version=N pool/filesystem > You can see what versions your system supports by > using the zfs upgrade > command:Thanks for the feedback. So if I have a version X pool/filesystem set, does that mean the way to move it back to an older version of TANK is to do something like: * Create OLDTANK with version=N * For each snapshot in TANK ** (cd tank_snapshot; tar cvf -) | (cd old_tank; tar xvf -) ** zfs snapshot oldtank the_snapshot_name This seems rather involved to get my current files/snaps into an older format. What did I miss? Thanks again, Marty -- This message posted from opensolaris.org
On 09/15/09 06:27, Luca Morettoni wrote:> On 09/15/09 02:07 PM, Mark J Musante wrote: >> zfs create -o version=N pool/filesystem > > is possible to implement into a future version of ZFS a "released" > send command, like: > > # zfs send -r2 <snap> ... > > to send a specific release (version 2 in the example) of the metadata? >I just created a RFE for this problem in general: 6882134. I''m not sure the above suggestion is the best way to solve the problem, but we do need some kind of support for inter-version send stream readability. Lori
On Sep 15, 2009, at 6:58 AM, Marty Scholes wrote:>> The zfs send stream is dependent on the version of >> the filesystem, so the >> only way to create an older stream is to create a >> back-versioned >> filesystem: >> >> zfs create -o version=N pool/filesystem >> You can see what versions your system supports by >> using the zfs upgrade >> command: > > Thanks for the feedback. So if I have a version X pool/filesystem > set...It is better to separate pool versions from filesystem versions. To date, there have been around 18 pool versions, but only 4 filesystem versions. zfs works on the filesystem, so you need to be concerned about the filesystem version when going backwards. -- richard
Lori Alt wrote:> On 09/15/09 06:27, Luca Morettoni wrote: >> On 09/15/09 02:07 PM, Mark J Musante wrote: >>> zfs create -o version=N pool/filesystem >> >> is possible to implement into a future version of ZFS a "released" >> send command, like: >> >> # zfs send -r2 <snap> ... >> >> to send a specific release (version 2 in the example) of the metadata? >> > I just created a RFE for this problem in general: 6882134. I''m not > sure the above suggestion is the best way to solve the problem, but we > do need some kind of support for inter-version send stream readability. > > Lori >I haven''t see this specific problem, but it occurs to me thus: For the reverse of the original problem, where (say) I back up a ''zfs send'' stream to tape, then later on, after upgrading my system, I want to get that stream back. Does ''zfs receive'' support reading a version X stream and dumping it into a version X+N zfs filesystem? If not, frankly, that''s a higher priority than the reverse. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
Erik Trimble wrote:> Lori Alt wrote: >> On 09/15/09 06:27, Luca Morettoni wrote: >>> On 09/15/09 02:07 PM, Mark J Musante wrote: >>>> zfs create -o version=N pool/filesystem >>> >>> is possible to implement into a future version of ZFS a "released" >>> send command, like: >>> >>> # zfs send -r2 <snap> ... >>> >>> to send a specific release (version 2 in the example) of the metadata? >>> >> I just created a RFE for this problem in general: 6882134. I''m not >> sure the above suggestion is the best way to solve the problem, but >> we do need some kind of support for inter-version send stream >> readability. >> >> Lori >> > > I haven''t see this specific problem, but it occurs to me thus: > > For the reverse of the original problem, where (say) I back up a ''zfs > send'' stream to tape, then later on, after upgrading my system, I want > to get that stream back. > > Does ''zfs receive'' support reading a version X stream and dumping it > into a version X+N zfs filesystem? > > If not, frankly, that''s a higher priority than the reverse. >I think you''ll find it isn''t "supported" but it does work. That is there''s no guarantee a new stream version will be upwardly compatible with an earlier one. -- Ian.
Erik Trimble wrote: > I haven''t see this specific problem, but it occurs to me thus:> > For the reverse of the original problem, where (say) I back up a ''zfs > send'' stream to tape, then later on, after upgrading my system, I want > to get that stream back. > > Does ''zfs receive'' support reading a version X stream and dumping it > into a version X+N zfs filesystem? > > If not, frankly, that''s a higher priority than the reverse.Your question confuses me greatly - am I missing something? "zfs recv" of a full stream will create a new filesystem of the appropriate version, which you may then "zfs upgrade" if you wish. And restoring incrementals to a different fs rev doesn''t make sense. As long as support for older fs versions isn''t removed from the kernel, this shouldn''t ever be a problem. -- Carson
Carson Gaspar wrote:> Erik Trimble wrote: > > I haven''t see this specific problem, but it occurs to me thus: >> >> For the reverse of the original problem, where (say) I back up a ''zfs >> send'' stream to tape, then later on, after upgrading my system, I >> want to get that stream back. >> >> Does ''zfs receive'' support reading a version X stream and dumping it >> into a version X+N zfs filesystem? >> >> If not, frankly, that''s a higher priority than the reverse. > > Your question confuses me greatly - am I missing something? "zfs recv" > of a full stream will create a new filesystem of the appropriate > version, which you may then "zfs upgrade" if you wish. And restoring > incrementals to a different fs rev doesn''t make sense. As long as > support for older fs versions isn''t removed from the kernel, this > shouldn''t ever be a problem.You are correct in that restoring a full stream creates the appropriate versioned filesystem. That''s not the problem. The /much/ more likely scenario is this: (1) Let''s say I have a 2008.11 server. I back up the various ZFS filesystems, with both incremental and full streams off to tape. (2) I now upgrade that machine to 2009.05, and upgrade all the zpool/zfs filesystems to the later versions, which is what most people will do. (3) Now, I need to get back a snapshot from before step #2. I don''t want a full stream recovery, just a little bit of data. I now am in the situation that I have a current (active) ZFS filesystem which has a later version than the (incremental) stream I stored earlier. This is what a typical recover instance is. If I can''t recover an incremental into an existing filesystem, it effectively means my backups are lost and useless. (not quite true, but it creates a huge headache.) -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
Erik Trimble wrote:> You are correct in that restoring a full stream creates the appropriate > versioned filesystem. That''s not the problem. > > The /much/ more likely scenario is this: > > (1) Let''s say I have a 2008.11 server. I back up the various ZFS > filesystems, with both incremental and full streams off to tape. > > (2) I now upgrade that machine to 2009.05, and upgrade all the zpool/zfs > filesystems to the later versions, which is what most people will do. > > (3) Now, I need to get back a snapshot from before step #2. I don''t > want a full stream recovery, just a little bit of data. I now am in the > situation that I have a current (active) ZFS filesystem which has a > later version than the (incremental) stream I stored earlier. > > > This is what a typical recover instance is. If I can''t recover an > incremental into an existing filesystem, it effectively means my backups > are lost and useless. (not quite true, but it creates a huge headache.) >Ummm... but you can''t recover that incremental anyway, unless you have the fs snapshot from which the incremental was derived. And that snapshot, by definition, is a compatible zfs fs version. Unless "zfs upgrade" touches snapshots? Which would be... odd... -- Carson
On Wed, Sep 16, 2009 at 09:34, Erik Trimble <Erik.Trimble at sun.com> wrote:> Carson Gaspar wrote: >> >> Erik Trimble wrote: >> ?> I haven''t see this specific problem, but it occurs to me thus: >>> >>> For the reverse of the original problem, where (say) I back up a ''zfs >>> send'' stream to tape, then later on, after upgrading my system, I want to >>> get that stream back. >>> >>> Does ''zfs receive'' support reading a version X stream and dumping it into >>> a version X+N zfs filesystem? >>> >>> If not, frankly, that''s a higher priority than the reverse. >> >> Your question confuses me greatly - am I missing something? "zfs recv" of >> a full stream will create a new filesystem of the appropriate version, which >> you may then "zfs upgrade" if you wish. And restoring incrementals to a >> different fs rev doesn''t make sense. As long as support for older fs >> versions isn''t removed from the kernel, this shouldn''t ever be a problem. > > You are correct in that restoring a full stream creates the appropriate > versioned filesystem. That''s not the problem. > > The /much/ more likely scenario is this: > > (1) Let''s say I have a 2008.11 server. ?I back up the various ZFS > filesystems, with both incremental and full streams off to tape. > > (2) I now upgrade that machine to 2009.05, and upgrade all the zpool/zfs > filesystems to the later versions, which is what most people will do. > > (3) Now, I need to get back a snapshot from before step #2. ?I don''t want a > full stream recovery, just a little bit of data. ?I now am in the situation > that I have a current (active) ZFS filesystem which has a later version than > the (incremental) stream I stored earlier. > > > This is what a typical recover instance is. ?If I can''t recover an > incremental into an existing filesystem, it effectively means my backups are > lost and useless. (not quite true, but it creates a huge headache.) >Congratulations! You now know why you should use a backup program instead of zfs send for your backups. (There are more reasons than this) zfs send streams are not designed for backups! (But a backup program that understand zfs send streams and uses that instead of re cursing the filesystem would be nice...)
On Wed, September 16, 2009 02:11, Carson Gaspar wrote:> "zfs recv" of a full > stream will create a new filesystem of the appropriate version, which you > may > then "zfs upgrade" if you wish. And restoring incrementals to a different > fs rev > doesn''t make sense. As long as support for older fs versions isn''t removed > from the kernel, this shouldn''t ever be a problem.It''s routine to go back into old incrementals for single-file recovery, in my experience over 40 years of backup strategies. But you can''t do that at all with saved zfs send streams. This is another example of how a ZFS SEND stream isn''t exactly a backup. I''m going with a strategy where the way I get old files back is from snapshots on either the main filesystem, or one of the backup filesystems, and send/receive are to be used only as communication channels between filesystems. But that does increase the size of the backup filesystems, if I keep any large amount of old snapshots around. Sun says roughly that if you want enterprise backup of ZFS filesystems, you should use an enterprise backup product, and I think I see their point on this one. -- 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
Erik Trimble wrote:> Lori Alt wrote: >> On 09/15/09 06:27, Luca Morettoni wrote: >>> On 09/15/09 02:07 PM, Mark J Musante wrote: >>>> zfs create -o version=N pool/filesystem >>> >>> is possible to implement into a future version of ZFS a "released" >>> send command, like: >>> >>> # zfs send -r2 <snap> ... >>> >>> to send a specific release (version 2 in the example) of the metadata? >>> >> I just created a RFE for this problem in general: 6882134. I''m not >> sure the above suggestion is the best way to solve the problem, but >> we do need some kind of support for inter-version send stream >> readability. >> >> Lori >> > > I haven''t see this specific problem, but it occurs to me thus: > > For the reverse of the original problem, where (say) I back up a ''zfs > send'' stream to tape, then later on, after upgrading my system, I want > to get that stream back. > > Does ''zfs receive'' support reading a version X stream and dumping it > into a version X+N zfs filesystem? > > If not, frankly, that''s a higher priority than the reverse. > > >I''m afraid that my answers yesterday, and the RFE I filed, have just confused matters. I''ve learned some more about send stream inter-version compatibility and found that the problem is not as difficult as I thought: There are two aspects to the stream versioning issue: the version of the objects stored in the stream and the version of the stream format itself. I was thinking that the object versioning was the harder problem, but I discussed this with Matt Ahrens and he pointed out that the existing zfs upgrade capability already copes with reading versions of data object formats that are earlier than the version of the pool into which the objects are being read. So as long as you''re doing a receive into a pool that has the same or greater version than the one that was used to generate the send stream, the objects should be interpreted correctly. The second version issue, which is the stream format, is where we haven''t necessarily promised compatibility in the past, but so far, the stream format has not changed. Changes are coming however for dedup. We''re looking at making those changes in such a way that earlier stream formats will still be receivable into future releases. So we''re considering a refinement of the current policy of not guaranteeing future readability of streams generated by earlier version of ZFS. The time may have come where we know enough about how send streams fit into overall ZFS versioning that we can make them more useful by making a stronger assurance about future readability. So stay tuned. As for being able to read streams of a later format on an earlier version of ZFS, I don''t think that will ever be supported. In that case, we really would have to somehow convert the format of the objects stored within the send stream and we have no plans to implement anything like that. As for being able to selectively receive only parts of a send stream, that''s another subject, unrelated to versioning. As someone else pointed out on this thread, that''s one way in which zfs send/recv is really not a ''backup'' tool in the usual sense. If you need that kind of functionality, zfs send/recv will not provide it for you. At some point, we could perhaps implement a way to select the datasets from within a send stream to receive, but given the way that objects are recorded in send streams, it would be very difficult to restore individual files. Lori
Lori Alt wrote:> As for being able to read streams of a later format > on an earlier > version of ZFS, I don''t think that will ever be > supported. In that > case, we really would have to somehow convert the > format of the objects > stored within the send stream and we have no plans to > implement anything > like that.If that is true, then it at least makes sense to include a "zfs downgrade" and "zpool downgrade" option, does it not? -- This message posted from opensolaris.org
On Wed, September 16, 2009 11:53, Lori Alt wrote:> So we''re considering a refinement of the current policy of not > guaranteeing future readability of streams generated by earlier version > of ZFS. The time may have come where we know enough about how send > streams fit into overall ZFS versioning that we can make them more > useful by making a stronger assurance about future readability. So stay > tuned.Is there any versioning in the stream format (like the on-disk ZFS format)? The tar/pax and TIFF file formats seem to be fairly good at having a base level, and have added extra functionality over the years (decades?). Older software ignores the fields it doesn''t understand, but still gets at most things. I guess there''s a balance between giving a guarantee and boxing yourself in unnecessarily.
On 09/16/09 10:48, Marty Scholes wrote:> Lori Alt wrote: > >> As for being able to read streams of a later format >> on an earlier >> version of ZFS, I don''t think that will ever be >> supported. In that >> case, we really would have to somehow convert the >> format of the objects >> stored within the send stream and we have no plans to >> implement anything >> like that. >> > > If that is true, then it at least makes sense to include a "zfs downgrade" and "zpool downgrade" option, does it not? >Not necessarily. The existence of an upgrade function doesn''t automatically mean that downgrade should be provided. What would a downgrade function do with, say, properties that weren''t even defined in the earlier version? Some kind of downgrade could theoretically be done (with appropriate messages about capabilities and fields that are not understood by the earlier version of the coded), but I don''t think its value would be worth the effort, at least not in comparison to other work that needs to be done. Lori -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090916/2c2c0eb7/attachment.html>
On 09/16/09 10:49, David Magda wrote:> On Wed, September 16, 2009 11:53, Lori Alt wrote: > > >> So we''re considering a refinement of the current policy of not >> guaranteeing future readability of streams generated by earlier version >> of ZFS. The time may have come where we know enough about how send >> streams fit into overall ZFS versioning that we can make them more >> useful by making a stronger assurance about future readability. So stay >> tuned. >> > > Is there any versioning in the stream format (like the on-disk ZFS format)? >Yes, there is versioning, but it hasn''t been used much so far. That''s what we intend to use going forward to allow future versions of the code to interpret older versions of the format.> The tar/pax and TIFF file formats seem to be fairly good at having a base > level, and have added extra functionality over the years (decades?). Older > software ignores the fields it doesn''t understand, but still gets at most > things. > > I guess there''s a balance between giving a guarantee and boxing yourself > in unnecessarily. >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090916/fb35a987/attachment.html>
Marty Scholes wrote:> Lori Alt wrote: >> As for being able to read streams of a later format >> on an earlier >> version of ZFS, I don''t think that will ever be >> supported. In that >> case, we really would have to somehow convert the >> format of the objects >> stored within the send stream and we have no plans to >> implement anything >> like that. > > If that is true, then it at least makes sense to include a "zfs downgrade" and "zpool downgrade" option, does it not?That is isn''t very easy to implement and could take a HUGE amount of time to convert the pool. Consider a pool with data encrypted and compressed with gzip (that would be a version 19 or higher pool) that you attempt to downgrade to version 4 ignoring all the other possible things you could be using that along requires decrypting and decompression all the data. That is technically possible but very time consuming. For the zfs version it just isn''t possible in some cases because, while you could choose to nolonger care about userquota not caring about create time only properties such as ut8only and normalization is a very difficult issue. -- Darren J Moffat
Lori Alt wrote:> On 09/16/09 10:48, Marty Scholes wrote: >> Lori Alt wrote: >> >>> As for being able to read streams of a later format >>> on an earlier >>> version of ZFS, I don''t think that will ever be >>> supported. In that >>> case, we really would have to somehow convert the >>> format of the objects >>> stored within the send stream and we have no plans to >>> implement anything >>> like that. >>> >> >> If that is true, then it at least makes sense to include a "zfs downgrade" and "zpool downgrade" option, does it not? >> > Not necessarily. The existence of an upgrade function doesn''t > automatically mean that downgrade should be provided. What would a > downgrade function do with, say, properties that weren''t even defined > in the earlier version? > > Some kind of downgrade could theoretically be done (with appropriate > messages about capabilities and fields that are not understood by the > earlier version of the coded), but I don''t think its value would be > worth the effort, at least not in comparison to other work that needs > to be done. > > LoriIn my earlier posting, I was more hypothesizing something that I''ve heard folks talking about. Personally, I don''t dump zfs streams to tape. ''zfs send/recive'' is not (nor do I expect it to be) a dump/receive for zfs. Backups and archives are to be done by appropriate backup software. That said, it''s becoming more and more common to design in a large disk backup device (Thor/Thumper, in particular) as either a staging area for backups, or as the incremental repository. Think of it as a variation on VTL. A typical config for this is with the client machines doing ''zfs send'' over to the Thumper, and the Backup Software running solely on the Thumper to do archival stuff. Doing it this way also means it''s simple to replicate the Thumper''s data elsewhere, so one can have redundant on-line backups, from which it is trivial to get back stuff quickly. Naturally, the bane of this kind of setup is zfs version mismatch between the Thumper and the client(s). I can easily imagine situations where the Thumper has a later version of zfs than a client, as well as one where the Thumper has an earlier version than a client (e.g. Thumper runs 2008.11, client A runs 2009.05, client B runs Solaris 10 Update 6). Some method of easily dealing with this problem would be really good. Personally, I would go with not changing ''zfs receive'', and modifying ''zfs send'' to be able to specify a zfs filesystem version during stream creation. As per Lori''s original RFE CR. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
On 09/16/09 11:56, Erik Trimble wrote:> Lori Alt wrote: >> On 09/16/09 10:48, Marty Scholes wrote: >>> Lori Alt wrote: >>> >>>> As for being able to read streams of a later format >>>> on an earlier version of ZFS, I don''t think that will ever be >>>> supported. In that case, we really would have to somehow convert the >>>> format of the objects stored within the send stream and we have no >>>> plans to >>>> implement anything like that. >>> >>> If that is true, then it at least makes sense to include a "zfs >>> downgrade" and "zpool downgrade" option, does it not? >>> >> Not necessarily. The existence of an upgrade function doesn''t >> automatically mean that downgrade should be provided. What would a >> downgrade function do with, say, properties that weren''t even defined >> in the earlier version? >> Some kind of downgrade could theoretically be done (with appropriate >> messages about capabilities and fields that are not understood by the >> earlier version of the coded), but I don''t think its value would be >> worth the effort, at least not in comparison to other work that >> needs to be done. >> >> Lori > > In my earlier posting, I was more hypothesizing something that I''ve > heard folks talking about. > > Personally, I don''t dump zfs streams to tape. ''zfs send/recive'' is > not (nor do I expect it to be) a dump/receive for zfs. Backups and > archives are to be done by appropriate backup software. > > That said, it''s becoming more and more common to design in a large > disk backup device (Thor/Thumper, in particular) as either a staging > area for backups, or as the incremental repository. Think of it as a > variation on VTL. A typical config for this is with the client > machines doing ''zfs send'' over to the Thumper, and the Backup Software > running solely on the Thumper to do archival stuff. Doing it this way > also means it''s simple to replicate the Thumper''s data elsewhere, so > one can have redundant on-line backups, from which it is trivial to > get back stuff quickly. Naturally, the bane of this kind of setup is > zfs version mismatch between the Thumper and the client(s). I can > easily imagine situations where the Thumper has a later version of zfs > than a client, as well as one where the Thumper has an earlier version > than a client (e.g. Thumper runs 2008.11, client A runs 2009.05, > client B runs Solaris 10 Update 6). Some method of easily dealing > with this problem would be really good. > > Personally, I would go with not changing ''zfs receive'', and modifying > ''zfs send'' to be able to specify a zfs filesystem version during > stream creation. As per Lori''s original RFE CR.But that''s just moving the ''downgrade'' problem from one machine to another. I''m going to modify or delete the RFE, because what I thought made sense before, doesn''t. lori> >
On Sep 16, 2009, at 10:56 AM, Erik Trimble wrote:> Lori Alt wrote: >> On 09/16/09 10:48, Marty Scholes wrote: >>> Lori Alt wrote: >>> >>>> As for being able to read streams of a later format >>>> on an earlier version of ZFS, I don''t think that will ever be >>>> supported. In that case, we really would have to somehow convert >>>> the >>>> format of the objects stored within the send stream and we have >>>> no plans to >>>> implement anything like that. >>> >>> If that is true, then it at least makes sense to include a "zfs >>> downgrade" and "zpool downgrade" option, does it not? >>> >> Not necessarily. The existence of an upgrade function doesn''t >> automatically mean that downgrade should be provided. What would a >> downgrade function do with, say, properties that weren''t even >> defined in the earlier version? >> Some kind of downgrade could theoretically be done (with >> appropriate messages about capabilities and fields that are not >> understood by the earlier version of the coded), but I don''t think >> its value would be worth the effort, at least not in comparison to >> other work that needs to be done. >> >> Lori > > In my earlier posting, I was more hypothesizing something that I''ve > heard folks talking about. > > Personally, I don''t dump zfs streams to tape. ''zfs send/recive'' is > not (nor do I expect it to be) a dump/receive for zfs. Backups and > archives are to be done by appropriate backup software. > > That said, it''s becoming more and more common to design in a large > disk backup device (Thor/Thumper, in particular) as either a staging > area for backups, or as the incremental repository. Think of it as > a variation on VTL.Yes. Another use case is when the primary data has a high performance requirement. For example, http://www.sun.com/software/products/messaging_srvr/wp_messaging_srvr_061909.pdf> A typical config for this is with the client machines doing ''zfs > send'' over to the Thumper, and the Backup Software running solely on > the Thumper to do archival stuff. Doing it this way also means it''s > simple to replicate the Thumper''s data elsewhere, so one can have > redundant on-line backups, from which it is trivial to get back > stuff quickly. Naturally, the bane of this kind of setup is zfs > version mismatch between the Thumper and the client(s). I can > easily imagine situations where the Thumper has a later version of > zfs than a client, as well as one where the Thumper has an earlier > version than a client (e.g. Thumper runs 2008.11, client A runs > 2009.05, client B runs Solaris 10 Update 6). Some method of easily > dealing with this problem would be really good.So the backup system must be running a version of ZFS compatible with the clients. This doesn''t seem like a difficult requirement to me. If you were truly paranoid, you could even run the backups in virtual machines -- one per client. -- richard