> On Fri, Jul 07, 2006 at 01:15:19PM -0400, Dennis Clarke wrote:
>>
>> A very good suggestion.
>>
>> However ... there had to be a "however" eh?
>>
>> I seem to have this unwritten expectation that with ZFS I would get
>> everything that I always had with UFS and SVM without losing a feature.
>> The
>> ufsbackup and ufsrestore command will both do a complete dump of a UFS
>> filesystem plus incrementals and all the metadata also.
>>
>> I lose that with ZFS as the backup technology does not exist yet to backup
>> all the metadata also.
>>
>> Perhaps we need to craft a zfsbackup and zfsrestore command ?
>>
>
> You most likely want the age-old RFE:
>
> 5004379 want comprehensive backup strategy
I guess that is age-old.
> The 'zfs send' and 'zfs receive' subcommands form the basis of this
> backup strategy. But they are only primitives, not solutions.
"primitive" is one word.
perhaps "axiom" is a better one and then upon these we may build a solution.
> They are
> intentionally designed this way because they can be used both for
> backup/restore and remote replication.
I agree that replication is a great feature, surely, but this feature is
duplicated in a Java Continuity Suite which works on Solarsi 8 and 9 but not
on 10. I guess there may be a plan to step the Continuity Suite up to
Solaris 10 or perhaps replace that functionality in ZFS. I really don't
know. I do know that the Java Continuity Suite allows me to take rsync to
the Nth degree and actually have synchronous filesystems between nodes. Sun
Cluster then goes the next step and we also have Sun StorEdge SAM-FS to
complicate matters.
Essentially there are a lot of ways to skin the replication cat.
> However, there are several key
> features required to make this a reality:
>
> 6421959 want zfs send to preserve properties ('zfs send -p')
I would think that is an essential.
> 6421958 want recursive zfs send ('zfs send -r')
Ah yes ... let's do one backup and not seven to get all the ZFS children.
> 6399128 want tool to examine backup files (zbackdump)
? eh ? ( insert Canadian accent here )
Is this some sort of "verify" tool or similar to ufsrestore -ivf foo.dump
and then we get to traverse the backup catalog with ls and cd. That sort of
idea?
> I believe Matt is planning on working on these (certainly the first two)
> once he gets back from vacation.
vacation .. another crazy idea I have to wrap my head around.
> Alternatively, an implementation of:
>
> 6370738 zfs diffs filesystems
>
> Would provide the primitive needed to implement a POSIX-level backup
> solution, by quickly identifying which files have changed in between
> given snapshots. This would be quite simple if it weren't for hard
> links.
>
> All of the above provide a rich set of primitives for someone to go off
> and investigate what it would take to implement a backup solution. This
> should probably be integrated with a system of rolling snapshots, as
> some of the functionality is the same (consistent snapshot naming,
> automatically scheduled snapshots, retirement of old snapshots).
All of the necessary bricks seem to be either in place or in the kiln being
baked. The task would be to build the brick house on top of ZFS.
Dennis
ps: yes I am tossing around metaphors as a replacement for wit today. My
apologies. If I roll out a car metaphor just filter me entirely.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
