On Wed, Sep 2, 2009 at 4:06 PM, <cindy.swearin...@sun.com> wrote:
> Hi Mike,
>
> I reviewed this doc and the only issue I have with it now is that uses
> /var/tmp an an example of storing snapshots in "long-term storage"
> elsewhere.
One other point comes from zfs(1M):
The format of the stream is evolving. No backwards com-
patibility is guaranteed. You may not be able to receive
your streams on future versions of ZFS.
Others have argued that it is not as flexible of a long-term storage
mechanism because a restore is all or nothing. In comparison to some
other backup formats the implications are:
- You cannot selectively restore files.
- There is no integrity check or error correction capability in the stream.
As such, if you have a 1 TB stream and somewhere around 1 MB
a bit is flipped, all is lost.
The most conservative (and somewhat common) advice with the output of
zfs send is that it should only be trusted if it is immediately
consumed by zfs receive. Of course, different people have different
needs. For most of my needs, the level of reliability that I would
get out of storing the output of zfs send is sufficient.
> For short-term storage, storing a snapshot as a file is an acceptable
> solution as long as you verify that the snapshots as files are valid
> like you would for any important data. I test root pool snapshot
> recovery for every Solaris 10 release and have also for Nevada releases.
>
> The point that needs to be clear is that you verify the file or
> snapshot. I have updated our root pool recovery steps to be performed
> either using snapshots as remotely stored files or remotely stored
> snapshots, here:
Storing the output itself on zfs + testing a "zfs receive" of the
stored file would go a long ways toward ensuring that the stored file
is usable for restores. Storing a strong hash (e.g. SHA*) of the the
file would help for the inevitable transfer of that file to some other
file system or between file systems. But this is all beyond newbie
level of documentation, I think.
> http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#Complete_Solaris_ZFS_Root_Pool_Recovery
>
> I will follow-up on this particular marketing document.
>
> Thanks for pointing it out...
>
> Cindy
>
> On 09/02/09 12:37, Mike Gerdts wrote:
>>
>> I just received a special offer from Sun (marketing...) promising that
>> I will learn "How to use ZFS snapshots for backup and restore
>> purposes." The relevant doc is at...
>>
>> https://www.sun.com/offers/docs/zfs_snapshots.pdf
>>
>> It says:
>>
>> === Begin quote ===
>> Archiving and Restoring Snapshots
>>
>> Another use of snapshots is to create archives for long-term storage
>> elsewhere.
>>
>> In the following sequence of commands, we send the snapshot into a
>> file and then compress it. It can then be
>> retrieved from the file when required. This is also shown:
>>
>> # zfs send pool/filesys...@thursday > /var/tmp/thursday.snap
>> # gzip -9 -v /var/tmp/thursday.snap
>> # zfs create pool/thursday
>> # gzip -d -c /var/tmp/thursday.snap.gz | zfs receive -F pool/thursday
>> === End quote ===
>>
>> There have been several threads on this list saying not to do that.
>> It seems that this guide aimed at new users is inviting people to do
>> things that will lead them to unsympathetic ears if things go poorly.
>>
>
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
