On Thu, Jun 9, 2011 at 1:17 PM, Jim Klimov <jimkli...@cos.ru> wrote:
> 2011-06-09 18:52, Paul Kraus пишет:
>>
>> On Thu, Jun 9, 2011 at 8:59 AM, Jonathan Walker<kall...@gmail.com> wrote:
>>
>>> New to ZFS, I made a critical error when migrating data and
>>> configuring zpools according to needs - I stored a snapshot stream to
>>> a file using "zfs send -R [filesystem]@[snapshot]>[stream_file]".
>>
>> Why is this a critical error, I thought you were supposed to be
>> able to save the output from zfs send to a file (just as with tar or
>> ufsdump you can save the output to a file or a stream) ?
>> Was the cause of the checksum mismatch just that the stream data
>> was stored as a file ? That does not seem right to me.
>>
> As recently mentioned on the list (regarding tape backups, I believe)
> the zfs send stream format was not intended for long-term storage.
Only due to possible changes in the format.
> If some bits in the saved file flipped,
Then you have a bigger problem, namely that the file was corrupted.
That is not a limitation of the zfs send format. If the stream gets
corrupted via network transmission you have the same problem.
> the stream becomes invalid
> regarding checksums and has to be resent. Besides, the format
> is not public and subject to change, I think. So future compatibility
> is not guaranteed.
Recent documentation (the zfs man page) indicates that as of zpool/zfs
version 15/4 I think the stream format was committed and being able to
receive a stream from a given zfs dataset was supported on _newer_ zfs
versions.
> Having said that, I have used dumping "zfs send" to files, rsyncing
> them over a slow connection, and zfs recv'ing them on a another
> machine - so this is known to work.
I suppose to move data or for an initial copy that makes sense, but
for long term replication why not just use incremental zfs sends ?
> However if it were to fail,
> I could retry (and/or use rsync to correct some misreceived
> blocks if network was faulty).
At some level we need to trust that the zfs send stream is intact.
--
{--------1---------2---------3---------4---------5---------6---------7---------}
Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, RPI Players
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
