>
> As others have noted, the COW nature of ZFS means that there is a
> good chance that on a mostly-empty pool, previous data is still intact
> long after you might think it is gone. A utility to recover such data is
> (IMHO) more likely to be in the category of forensic analysis than
> a mount (import) process. There is more than enough information
> publically available for someone to build such a tool (hint, hint :-)
> -- richard
Veritas, the makers if vxfs, whom I consider ZFS to be trying to
compete against has higher level (normal) support engineers that have
access to tools that let them scan the disk for inodes and other filesystem
fragments and recover. When you log a support call on a faulty filesystem
(in one such case I was involved in zeroed out 100mb of the first portion
of the volume killing off both top OLT's -- bad bad) they can actually help
you at a very low level dig data out of the filesystem or even recover from
pretty nasty issues. They can scan for inodes (marked by a magic number),
have utilities to pull out files from those inodes (including indirect
blocks/extents). Given the tools and help from their support I was able to
pull back 500 gb of files (99%) from a filesystem that emc killed during a
botched powerpath upgrade. Can Sun's support engineers, or is their
answer pull from tape? (hint, hint ;-)
-Wade
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
