8

Is it safe to replicate from a Solaris 10 ZFS v22 to a FreeBSD 8.3 ZFS v28?

Are there someone that have done this with specific versions of ZFS, where it worked perfectly?

Louise Hoffman
  • 476
  • 2
  • 6
  • 12
  • what version of solaris are you replicating from? What is the ZFS file system version? – n8whnp Jul 30 '11 at 13:09
  • What do you mean with replicate ? – jlliagre Jul 30 '11 at 15:44
  • 1
    ZFS replication – Louise Hoffman Jul 30 '11 at 15:46
  • 1
    Sure but that doesn't really answer my question. It would help if you clarify what you want to duplicate (eg: a pool or a dataset), how (eg: zfs send/receive or something else), and with what constraints (eg: on-line/real time vs off-line/batch, shared or removable media). – jlliagre Jul 30 '11 at 21:05
  • @jlliagre : So what's what you meant. It is a pool, with one volume, and one file system. I was thinking about doing the replication with snapshots `zfs send -i`, so the replication is on file system level and not volume level. Would pool or volume level be better? It should be done online, but e.g. each 20 minutes or so. – Louise Hoffman Jul 30 '11 at 22:10

2 Answers2

5

There should be no issue sending a Solaris 10 ZFS v22 snapshot to a FreeBSD server supporting v28. Reciprocally, that saved snapshot, or any snapshot of a clone/descendant of the initial snapshot should be sent back to that Solaris box with no issue as long as you never upgrade the ZFS filesystem on the FreeBSD server.

What matters really are the zfs versions, not the OSes, given the fact the (Open)Solaris code base is used on both sides. Preserving upward compatibility for datasets (filesystems, volumes and snapshots) and pools is likely one of the rules that can't be broken by the ZFS developers.

Note: this somewhat happened in the past but ZFS was still beta: http://hub.opensolaris.org/bin/view/Community+Group+on/2008042301

Current zfs manual pages state about the zfs send stream:

       *The format of the stream is committed. You will be able to receive
       your streams on future versions of ZFS.*
jlliagre
  • 8,691
  • 16
  • 36
  • Excellent! What tests would you recommend that I preform when I have set it up, so I know that I am not corrupting any data? – Louise Hoffman Jul 30 '11 at 23:12
  • Btw. You mentioned "a pool or a dataset". I thought that a dataset was a snapshot on either pool/volume/file system level? Or is a dataset something else? – Louise Hoffman Jul 30 '11 at 23:15
  • 1
    No tests required ! ZFS can't corrupt data and this is by design ;) Of course, there would be many things to test anyway but that depends on what you plan to do with the file system on the each side. You should test procedures, performance, potential limitations (eg: I'm not sure FreeBSD supports sharesmb), etc. About your dataset question, I guess you are confusing terms. A pool is something built on the top of disks or similar things providing various levels of redundancy. Inside a pool you can create datasets which are file systems, volumes and snapshots. All datasets share the same pool. – jlliagre Jul 30 '11 at 23:27
  • So I can be sure that v28 of ZFS won't change the content in the v22 snapshot? Thanks for the dataset explanation. – Louise Hoffman Jul 30 '11 at 23:31
  • 1
    A snapshot is read-only so whatever the version supported by the code mounting it, it can't be changed. If you are really talking about clones, the content might be changed but in a compatible way unless of course you upgrade. – jlliagre Jul 30 '11 at 23:40
  • The reason I want to make the snapshot replication is for backup purposes. So right now I am thinking. Couldn't I just scp/netcat the snapshots to many Linux box, and store them there as files? In case of recovery then just pipe the snapshots files back to ZFS on the Solaris box? Very nice addition you made your answer :) – Louise Hoffman Jul 31 '11 at 00:17
  • 1
    In the above scenario, why would upgrading the FreeBSD ZFS filesystem break compatibility? Wouldn't upgrading, to say v34, still recognize the data as having come from v22, and preserve the fact? – Joe Internet Jul 31 '11 at 04:33
  • 1
    The machine storing the zfs stream doesn't even need to know anything about ZFS if you goal is just to be able to send it back to the original sender. However, you won't be able to restore individual files in that case. @Joe Internet, upgrading doesn't preserve the previous version. Any upgrade breaks compatibility by design. – jlliagre Jul 31 '11 at 08:16
  • Do you have a reference I can read for more info? I'm not understanding how comaptibility gets broken. IMO, the upgrade should still see the v22 data as v22 compatible, and send it back to a v22 system as v22 data. To not do this seems like a "bad thing". Thanks. – Joe Internet Jul 31 '11 at 08:22
  • 1
    The data is just the data. It has no version as far as ZFS is concerned. Of course, the newer system is still able to send the file data (and optionally its posix metadata) back to the original machine using a file transfer or file sharing protocol. However, we are here talking about zfs send/receive which processes more than the data and basic metadata. The file system structure is what is affected by version changes. They are bumped when one or more incompatible changes are made. – jlliagre Jul 31 '11 at 13:29
  • @jlliagre : Is it possible to check that the transfer of the snapshot haven't been corrupted in the transfer? I mean, if a snapshot is 5TB, then it will take some time. Does zfs e.g. have a command that can be run to verify a 5TB snapshot file? – Louise Hoffman Aug 01 '11 at 10:10
  • 1
    The should be no need to verify. AFAIK, if `zfs receive succeeds`, the snapshot has been fully transfered with no data corruption. ZFS checksums every piece of information so any transmission error would be detected immediately. – jlliagre Aug 01 '11 at 13:18
  • @jlliagre: What if `zfs receive` fails? Have I then destroyed the destination as well? – Louise Hoffman Aug 01 '11 at 15:26
  • 1
    You can't destroy something that doesn't exist yet. The destination starts being available only after the receive succeeds. However, there is no way to resume a failed transfer so you'll have to restart from the beginning. – jlliagre Aug 01 '11 at 16:36
  • @jlliagre : Great. And I could just pipe the snapshot through gzip before netcat, so I can check that the transfer wend well. Would it be possible to make "incremental" snapshots? So if only 1GB changes since last snapshot, then the snapshot is 1GB rather then 5TB? – Louise Hoffman Aug 02 '11 at 10:20
  • 1
    You certainly can send incremental streams by using the `zfs send -i oldsnapshot newsnapshot` command. – jlliagre Aug 02 '11 at 13:20
0

In that direction, it should work. I don't know if it would work in reverse with the FreeBSD ZFS going to the older Solaris ZFS.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 1
    I can tell for sure it won't work from a lower version to a newer. Sun have made updates to ZFS that once upgraded, you can't downgrade. What are you basing it on, that replication should work across OS'es? – Louise Hoffman Jul 30 '11 at 16:35