Findbill looks for UFS backup superblocks on Solaris servers.


Example senario: you have a power outage. When the server powers on it
does not boot fully, stopping with an fsck error to say that the super block
is corrupted. You try "fsck -o b=32 ...", which trys the first backup. 
Usually this works. If not you need the second backup or the third.
"newfs -N ..." will print where they should be by default, however if
you tuned your UFS and those backups are elsewhere then it's time to 
use findbill to search for where they really are.


Example 1: here we run findbill then "newfs -N" to compare.

   # findbill /dev/rdsk/c0t0d0s0
   Searching /dev/rdsk/c0t0d0s0,
   
   Type     Block    Time last written         Mountpoint
   UFS      16       Tue Jan 10 19:12:46 2006  /
   UFS      32       Thu Dec 15 20:04:40 2005  
   UFS      88800    Thu Dec 15 20:04:40 2005  
   UFS      177568   Thu Dec 15 20:04:40 2005  
   UFS      266336   Thu Dec 15 20:04:40 2005  
   UFS      355104   Thu Dec 15 20:04:40 2005  
   UFS      443872   Thu Dec 15 20:04:40 2005  
   UFS      532640   Thu Dec 15 20:04:40 2005  
   UFS      621408   Thu Dec 15 20:04:40 2005  
   ^C

   #
   # newfs -N /dev/rdsk/c0t0d0s0
   /dev/rdsk/c0t0d0s0:     16751952 sectors in 16619 cylinders of 16 tracks,
   63 sectors
           8179.7MB in 189 cyl groups (88 c/g, 43.31MB/g, 5504 i/g)
   super-block backups (for fsck -F ufs -o b=#) at:
    32, 88800, 177568, 266336, 355104, 443872, 532640, 621408, 710176, 798944,
    15878240, 15967008, 16055776, 16144544, 16233312, 16322080, 16410848,
    16499616, 16588384, 16677152,

Note how newfs in Solaris 9 only prints the first ten and last ten 
backup super blocks rather than a screenfull of them all. Not a bad idea,
since if you really were looking for your eleventh backup super block
you should be reading from your backup tapes instead!


Example 2: Here we run findbill on a disk with suprising results,

   # findbill /dev/rdsk/c0t1d0s7
   Searching /dev/rdsk/c0t1d0s7,
   
   Type     Block    Time last written         Mountpoint
   MTB_UFS  16       Tue Jan 10 19:18:04 2006  /mnt
   MTB_UFS  32       Tue Jan 10 19:17:54 2006  
   UFS      4768     Fri Dec 29 13:48:07 2000  
   UFS      5520     Wed May  1 10:28:48 2002  
   UFS      7792     Fri Sep  3 15:05:56 2004  
   UFS      11008    Mon Apr 11 09:05:25 2005  
   UFS      64608    Tue Jan 10 16:41:57 2006  
   UFS      76400    Wed Aug  1 09:56:04 2001  /export/home
   UFS      92592    Wed Aug  1 09:56:04 2001  /export/home
   UFS      94288    Wed May  1 10:28:48 2002  
   UFS      96560    Fri Sep  3 15:05:56 2004  
   ^C

Firstly, the superblocks at 16 and 32 are both MTB_UFS - MultiTerabyte UFS,
a new UFS variant from Solaris 10. This variant of UFS supports filesystems
greater than 1 TB, and is tuned to perform well for such large filesystems.

Secondly, numerous older UFS superblocks were found on this filesystem - some
dating back to the year 2000. These are FALSE POSITIVES. This disk has been
repurposed several times over the years, but never filled with data. When 
newfs creates a new filesystem, it doesn't blank the disk first - it leaves
the original data there and writes a new filesystem structure. This means
that it's possible for findbill to discover older superblocks from the past,
and is why findbill prints the time column.

There is the remote possibility for a false positive when something looks
like a superblock but isn't. Check whether the time is a sensible value.