SNAP RAID Recovery using SNAP OS

April 11, 2007 by Dick Correa
Filed under SNAP Server File System
SNAP Server NAS RAID Data Recovery

SNAP Appliance, now owned by Adaptec was one of the pioneers of the Network Attached Storage (NAS) technologies. Through the use of the Berkeley Software Distribution (BSD) and the UNIX File System (UFS), SNAP developed a reliable and easy method for using a mass storage device through a shared network. In order to do this SNAP used an abbreviated version of the file system in conjunction with a set of hard coded variables that allowed for a fast boot up, easier recovery facilities within the spectrum of the operating system, and a ROM based web interface that was closely tied to several of the standard UNIX/Linux/BSD recovery tools. However, that being said, when it came to catastrophic recovery this particular OS/FS marriage made it virtually impossible for any third party standard file system handler, or tool, to recover lost, or deleted data. The following is an outline of one of the basic data structures, the Super Block, and how it differs from the standard UFS file system. These differences are the ‘fly in the ointment’ when it comes to using standard UFS data recovery tools. Read my article on SCO Unix RAID Data Recovery for more insight on the UFS.

On-disk file system data structures are the key to data recovery. The knowledge of how a file system resides on the disk is the only way to recover from catastrophic data loss. Using on-disk data structures and their relationship with each other will help a recovery expert piece together lost data on a file system that will not mount. In essence, the data recovery technician creates a virtual file system using key data elements from the on-disk structure. These data elements go through a mathematical and geometrical scrutiny. This evaluation of the data must be strict enough to allow for corrupt data parsing, but flexible enough to build the file system from a partial data structure. In other words, a sort of ‘artificial intelligence’ is used to compare, evaluate, and assign data values to key data elements through the use of file system structure placement. A basic element of the file system in this particular case is the Super Block.

The Super Block is a broad spectrum definition of the entire file system. Although not defining file placement, and block usage, the Super Block is the crux of on-disk data element placement that will lead the data recovery technician to file name, inode definition, and ultimately data block placement. Data fields that reveal such values as total inodes, total data blocks, total cylinder groups, can be used to define a cohesive file system and in many cases rebuild a corrupted data structure. The Super Block defines coarse data that can be used to calculate cylinder group definitions that inevitably lead to directory definitions, and a methodology to build a file tree.

The Super Block is defined across the disk in each cylinder group. This fact alone can aide the trained data recovery technician in the alignment of the file system. Once aligned, it is a simple matter of back tracing directory name, inode definition, and data block in order to build a file tree. As an example the Super Block designates the primary inode block. When parsing the first cylinder group inode 0, and 1 are undefined and the 128 byte data elements are zeroed. However, inode 2 is defined, and can be traced to the root of the directory structure. Using recursion, one can easily define a full tree by using this single data element.

SNAP UFS File System Data Recovery

There are many more data elements that are an integral part of the SNAP UFS, however, the one basic element that is needed in order for third party UFS handlers to function is missing. Each on-disk data structure maintains an element that is unique to its particular type. This element is defined as a ‘MAGIC NUMBER’. This magic number, however derived, is a tell tale element that can be used by the technician to find certain data structures. For whatever reason, SNAP decided to ignore the magic number and it is not stored on-disk. This may be an indication that the SNAP file system designers did not want to carry extra data elements that were superfluous to the functionality and definition of the file system. It is a good strategy for saving precious space in a ROM perhaps, but is not a sound strategy if one is trying to piece together a file system and has no idea where to start. I am not trying to second guess the SNAP Appliance designers, it is merely a fact of the on disk structure and must be dealt with.

If a software engineer wishes to design, code and implement a SNAP Appliance UFS recovery handler then the magic number must be taken into consideration. There are several other data elements of the super block structure that must have certain values. These values can be boundary tested, and used to find other data elements that have a more traditional on-disk data structure. In other words, if the super block cylinder group element points to a particular sector on the disk, that sector can be loaded and masked with a cylinder group on-disk structure. The structure can then be boundary tested and if the testing proves positive then the original super block placement may be correct. Of course, several other elements must be tested, but if the tests return in a positive manner, it is very likely that you may have found your super block without the use of a magic number.

In the final analysis it is up to the data recovery technician to evaluate each SNAP Appliance, and the possibility of recovery. However, with calculator in hand, and hex editor on screen, a well versed data recovery technician can find the super block, and in that, use that key to unlock his clients lot data.