SAN LUN Mapping error causes file system sharing to conflict data recovery whole process

"User units"

A branch of China Unicom

"Data Recovery failure description"

Sun Fiber Storage System, the central storage of 6 pieces of 300G hard disk RAID6, divided into several lun,map to different services on the server, the server runs the Sun Solaris operating system.

In normal operation, the user needs to add a new application, so an IBM server is added, then a LUN in the store is mapped to the new IBM server in the online state, and unexpectedly, the mapped volume was originally map to a LUN on the Solaris production system, because it was not discovered in time. The LUN has been partially initialized on the IBM server (operation is unknown), then a disk error on Solaris, a problem was found after a reboot, and the volume could not be mounted.

After the Sun engineer detects and executes fsck, the file system can be hung up after completion, but a lot of data loss or size becomes 0, especially the latest data corruption is serious.

"Data Recovery Failure Analysis"

Such failures are common in San environments, but most are caused by human carelessness, as is the case with this failure. Under normal circumstances, the LUN allocated by the SAN is exclusive mode, if it is controlled by several operating systems at the same time, it is very easy to cause the write operation is not mutually exclusive, resulting in file system consistency error.

If you want to recover this part of the data, you need to drill down into the file system to investigate the destruction of its various structures. In this case, because the file system uses UFS, so for any one need to recover the file, priority to the directory information, node, data area is normal, such as the above 3 structures are normal, the data can be fully restored. However, in most cases, the inode will be cleared after fsck, even if the directory information can not be corresponding to data one by one, this time, can only refer to the file internal format for the type of recovery.

"Data recovery process"

1, the full backup failed volume, because the raid is not a fault, so directly in the Solaris environment of the original LUN to do DD backup.

2, in the backup analysis of the file system, to determine the files needed to recover the inode has been completely cleared, cannot be restored. Had to be processed by file type.

3, the user needs to recover the specific file analysis, found that the VFS Official Document System index file has a strong type characteristics, while the file contains directory information.

4, according to the document System index structure characteristics, write procedures extracted, extracted according to the characteristics of the renamed.

5. Recover data files by type, and then manually reorganize the data files according to the index files.

"Data Recovery conclusion"

After 24 hours, the directory index file 99% successfully restored, most of the data files recovered successfully, the rest of the files have been destroyed unrecoverable, the user from the directory index file re-collected to other departments.

Conclusion, the user acknowledges the success of data recovery.

650) this.width=650; "Src=" https://s2.51cto.com/wyfs02/M00/99/7A/wKiom1lIzrLAQ1UPAAIHe-ng2n4214.jpg-wh_500x0-wm_ 3-wmp_4-s_324282992.jpg "title=" Perspective blue. jpg "alt=" wkiom1lizrlaq1upaaihe-ng2n4214.jpg-wh_50 "/>

This article is from the "SUN" blog, be sure to keep this source http://sun510.blog.51cto.com/9640486/1940217

SAN LUN Mapping error causes file system sharing to conflict data recovery whole process