Shulou(Shulou.com)06/02 Report--

In the AIX environment, if the LV is accidentally deleted because of maintenance misoperation, storage mapping error and so on, this kind of loss is usually huge. The improper protection and recovery operation after deletion may make the data unable to recover, and may also increase the processing time and algorithm complexity. How to protect the site effectively and choose the correct data recovery scheme is very important.

The storage layer of AIX has too many articles to describe, as a groundwork, a brief description. PV is the equivalent of a physical disk (for storage, it is the volume mapped to the storage, for the operating system, it is equivalent to the physical hard disk), and several PV form a VG, which means that storage space of different capacities can be uniformly allocated. To achieve this, AIX arranges all the PV of the same VG according to the same size of storage particles, which is called PP. When allocating space, several PP (possibly on different PV) are used as a collection, which is called LV.

The LVM layer VGDA area of AIX has a fixed PP-to-LV mapping table called PPMAP. All PP of each PV starts with the first (PP#1) and records which LV the PP belongs to in a fixed size of 32 bytes. To delete a LV of the VG in the AIX, the most fundamental thing at the bottom is to release the PP originally occupied by the LV, that is, all 32-byte PPMAP entries that occupy the PP before clearing 0. in addition, some work will be done, such as cleaning the LV name, cleaning the summary information of the LV device, and so on.

After LV is deleted, it is not recommended to rashly attempt to use operations such as mklv to attempt disaster recovery. Although mklv essentially does not clear the pp content area, data can be corrupted in some cases, such as if the PP allocation table before and after the failure is different, but the previous PP table is allocated correctly, so that the file system may be recognized or even mounted. The trouble, however, is that some structures may go wrong after they are hung up, so that they are automatically corrected by the system, and things get worse. Even read-only mount is not the most preferred approach.

If time permits, the recovery plan after AIX LV deletion is roughly as follows:

1. Keep VG status and do not create any new LV.

2. Use backup means to make a complete image of all the PV in VG.

3. Perform data extraction and recovery in the mirror. Or protect the image to analyze the good PPMAP and reconstruct the lost LV.

The purpose of the above scheme is: all operations can be traced back as far as possible.

[how to fully mirror a failure volume]

Let's talk about how to fully mirror the PV in AIX (judging from the current data recovery technology, most of the processing and analysis processes are based on WINDOWS environment, so the mirrored data can be accessed directly under WINDOWS as far as possible.)

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 hold the pv that needs to be mirrored, you can mirror the pv into a file (or LV). If it is a file, it can be transmitted through FTP and other means. (this method is not recommended)

The third method: build another NFS server and mirror the pv to the nfs with dd in the way of nfs. Of course, if cifs can be mounted on aix, it can even be mirrored directly to the shared folder of windows. However, if you generate large files under windows, it may become slower and slower, so you can try to use WINDOWS2008 or choose another scheme.

The fourth method: the proposed scheme. Specifically, the building block device mapping to aix environment is mirrored directly from the block device to the block device. The optional block devices are fc lun,iscsi and so on. If there is no support for the fc environment, at least iscsi (which can be soft iscsi) is a good enough solution.

Take the iscsi target,AIX environment on the windows as an example, the following is a detailed process:

1. Configure the network environment to ensure the connectivity between AIX and WINDOWS.

2. Build ISCSI TARGET on WINDOWS, and take the following figure starwind as an example, create an iscsi disk named pv0.

Figure 1:

3. Return to the aix platform and determine whether to install iscsi initiator:

Lsdev | grep iscsi. If the prompt "iscsi0 Available iSCSI Protocol Device" indicates that the ISCSI client has been installed, the device number is iscsi0. You can also use lslpp-L | grep-I iscsi to confirm that the ISCSI package is installed. If not, install iscsi initiator first.

4. Modify the / etc/iscsi/targets file in the aix environment and add a line at the end (in this case, the ip of windows iscsi target is 192.168.1.9). 192.168.1.9 3260 iqn.2008-08.com.starwindsoftware:tel-pv0

5. Execute cfgmgr-l iscsi0 on the aix platform (see the equipment number in step 3), and rescan the iscsi device.

6. Lspv to see if the iscsi device is recognized. The results of this example are as follows:

Figure 2:

You can see that hdisk3 has recognized it and can use lsattr-El hdisk3 to view the device details. The result of the command is:

Figure 3:

You can see the clear details of the iscsi device, and you can use the bootinfo-s hdisk3 to see if the target iscsi capacity is correct (in MB, for this example, only an ISCSI storage volume of 4GB size has been created).

Figure 4:

7. Use the dd command to fully mirror the fault storage (it is recommended to use the block device path for mirroring): ddif=/dev/rhdisk0 of=/dev/rhdisk3 bs=4096k conv=noerror,sync.

[AIX LV erroneous deletion data recovery scheme]

After a full backup of the failed PV, you can begin to recover the data. There are roughly three options for data recovery.

Option 1:

The PPMAP of the original LV is analyzed, and then the same allocation table as the original LV is reconstructed by mklv-m to activate the original LV and recover the data.

Option 2:

The PPMAP of the original LV is obtained by analysis, and the JFS2 file system is interpreted directly through the third-party software (North Asia develops JFS2 file system interpretation software with windows). If it is a bare device (RAW), it can be fully read out and then re-written back as a block.

Option 3:

If the ORACLE database is stored in the original LV, according to the characteristics of the oracle data files, we can extract and assemble all the specific data files from all PP in a fragmented way, and then recover the oracle system in a disaster way.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.