In the AIX environment, due to maintenance misoperation, storage mapping error, and so on accidentally deleted LV mistakenly, this loss is usually huge. Improper protection and recovery operations after deletion may cause data to be unrecoverable or increase processing time and algorithmic complexity. How to effectively protect the site and choose the right data recovery program is very important.
AIX's storage layer has too many articles to describe, as a foreshadowing, a brief description. PV is the equivalent of a physical disk (for storage, the volume mapped, for the operating system, equivalent to the physical hard disk), a number of PV composed of a VG, which means that the capacity of different storage space can be unified allocation. To do this, AIX spaces all PV of the same VG by the same size storage particle, which is pp. And when allocating space, with a number of PP (may be different PV), as a use set, this set is LV.
AIX's LVM layer Vgda region has a fixed pp to LV mapping table, called Ppmap. All pp for each PV starts with the first (pp#1), with a fixed size of 32 bytes to which lv the PP belongs. Remove some of the AIX VG of the LV, the bottom of the most fundamental is to release the original LV occupied PP, that is, 0 before the clearance of all the PP 32-byte ppmap entries, but also do some such as LV name cleaning, LV equipment summary information clean-up and so on.
After the LV has been removed, it is not recommended to attempt a disaster recovery with MKLV and other operations. Although the PP content area is not mklv by nature, there are cases where the data is corrupted, such as if the PP allocation table is not the same before and after the failure, but the front PP table is allocated correctly, so that the file system may be recognizable or even hung up. The trouble, though, is that some of the structures may be wrong when they hang up, so that the system automatically fixes things that get worse. Even a read-only approach to mount is not the best choice.
If time permits, the recovery scenario after AIX LV removal is roughly:
1, maintain VG State, do not create any new LV.
2, using Backup means, all the PV in VG to do a complete mirror.
3, in the mirror data extraction and recovery. or protect the mirror to analyze the good ppmap, rebuild the lost LV.
The purpose of the above scheme is: All operations can be traced as far as possible.
"How to Complete mirror failed volumes"
To say how to do a full image of the PV in Aix (from the current data recovery technology, most processing and analysis process is preferred to the Windows environment, so the mirroring scheme as much as possible to accommodate the mirrored data can be directly accessed under Windows):
The first method: If the storage itself has a volume mirroring function, you can try it.
The second method: if there is enough space in the AIX environment to place the PV that needs to be mirrored, the PV can be mirrored into a file (or LV). If it is a file, it can be transmitted by means of FTP. (This method is not recommended)
The third approach is to build an NFS server that mirrors the PV to NFS using DD in NFS mode. Of course, if you can mount CIFS on AIX, you can even mirror it directly to a shared folder in Windows. However, if a large file is generated under Windows, it is likely to become more and more slow, and you can use WINDOWS2008 or other options as much as possible.
The fourth approach: the proposed scheme. Specifically, the building block device mapping to the AIX environment and is mirrored directly to a block device to a block device method. The optional block device has FC Lun,iscsi and so on. If the FC environment is not supported, at least iSCSI (which can be soft iSCSI) is a good enough solution.
Take the iSCSI initiator as an example of Windows-side iSCSI Target,aix environments, the following is a detailed procedure:
1, in the configuration network environment, to ensure that Aix and Windows network access.
2. To build iSCSI TARGET on Windows, the following figure Starwind, for example, creates an iSCSI disk called Pv0.