[EMAIL PROTECTED] wrote: >> 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 ;-)
Sounds like a good topic for here: http://opensolaris.org/os/project/forensics/ -- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
