zfs discuss - Jun 2009 - Broken snapshot is a bit of a disaster

Did you ever find a solution to this?  I have a similar problem, where my ZFS
snapshot was sent through gzip out to a file.  I tried to gzcat the file out to
a new ZFS, but got the "cannot receive new filesystem stream: invalid
backup stream" error.  At that point I just ran gunzip on the file and it
extracted the zip with no problem, so at least the integrity of the zip file was
OK.  I''ve done this with several other backups with no problems and
can''t figure out why this one fails.  The file is a sparse Zvol 17G in
size containing a virtual machine that I''d really like to get back...

Other details - the original ZFS was created at ZFS version 14 on SNV b105,
trying to be restored to ZFS version 15 on SNV b114.  Any help would be
appreciated.
-- 
This message posted from opensolaris.org

> Other details - the original ZFS was created at ZFS
> version 14 on SNV b105, trying to be restored to ZFS
> version 15 on SNV b114.  Any help would be
> appreciated.
The zfs send/recv format is not warranted to be compatible between revisions.  I
don''t know, offhand, if that is the problem in this specific case or
between these revisions.   You might try running up a VM on b105 and seeing if
it can read the stream.

I''m concerned that, despite clear recommendations and advice against
it, there seem to be a number of solutions appearing (like automated backup to
cloud, via the auto-snapshot hooks) that use the stream format for long term
storage, even from those within Sun.  I think the message needs to be clear,
either way - either endorse stream-format compatibility, or discourage such
usage.
>From my reading of the recommendations regarding the stream format,
it''s concerning enough that it may not be possible to send streams
between two hosts at different versions, even as a direct stream.  You may get
lucky, most of the time, but don''t rely on it.
Which still leaves a question as to what the most appropriate archive format is,
that understands incremental snapshots, properties, and all your other favourite
zfs features, etc. I''m starting to favour using real ZFS pools in zvols
or files (or directly on external media), along with vm images to run them where
needed, since these come with an upgrade process and compatibility assurances
for the content.
-- 
This message posted from opensolaris.org

>>>>> "dc" == Daniel Carosone <no-reply at
opensolaris.org> writes:
    dc> I''m concerned that, despite clear recommendations and advice
    dc> against it, there seem to be a number of solutions appearing
    dc> (like automated backup to cloud, via the auto-snapshot hooks)
    dc> that use the stream format for long term storage, even from
    dc> those within Sun.  

+1

    dc> I think the message needs to be clear, either way - either
    dc> endorse stream-format compatibility, or discourage such usage.

creating a good backup tool 

and creating a good replication tool

might be incompatible goals, in terms of how you design the exception
handling.  One bit flipped in a replication stream should cause the
entire receive to atomically roll back.  One bit flipped in a backup,
no matter where, should be guaranteed to cause minimal data loss (same
as on a zpool itself).
-------------- 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/20090623/8a905561/attachment.bin>