【故障描述】
某地法院一台hp eva8400儲存，2組擴充套件櫃，物理磁碟由12個1t fata磁碟（ag691a 454414-001）和10個300g 15k fc磁碟（ag690a 454411-001）組成，lun數量不確定，主機環境為windows，儲存法院歷史案例審理材料。
因本案多方轉手，所以我們也無法直接得知故障原因。
【初檢及分析】
1、**初檢，確定得知，資料出現故障後再未重用。通常按hp-eva的故障可能推斷，資料恢復的可靠性較高。
2、eva主機及擴充套件櫃正常關機，之後將所有硬碟標好位置序號，拿出。在資料成功恢復之前，不再開啟eva 8400控制器。
3、接手磁碟後，按如下鏈路對磁碟進行連線。
4、進入windows環境，用winhex檢視磁碟情況，發現所有磁碟均可正常識別。
5、檢視每個磁碟資訊，發現300g fc磁碟存在pv head，而1t fata磁碟上均無pv head。檢視300g磁碟中儲存的metadata，發現僅描述了乙個rss組組成的lun,大小不足2t，成員為所有300g磁碟。而1t fata磁碟中殘留的lun資訊則至少包括5組資訊。上述資訊表明，極有可能地，某種原因導致刪除了1t 磁碟組成的disk group內所劃分的所有vdisk，並ungroup了所有1t fata磁碟。
6、分析1t fata磁碟上保留的metadata，大致判斷可恢復率較高。
【恢復過程】
1、對所有磁碟做完整映象，參見《如何對磁碟做完整備份》或本人部落格中的其他文章。
2、使用frombyte recovery for hp-eva對300g 磁碟所屬的lun進行恢復。
3、因1t磁碟已全部ungroup，關於rss的分配，以及本身的磁碟id均無法得知。故需進行人工方式分析rss配置表。通過meta資訊的對照，以及通過xor資訊區的校驗驗證，得到如下rss組配置表：
3-0 hd6
3-1 hd8
3-2 hd2
3-3 hd9
3-4 hd10
3-5 hd5
2-0 hd0
2-1 hd7
2-2 hd1
2-3 hd11
2-4 hd3
2-5 hd4
4、重組及整合所有lun的儲存分配表。
5、根據儲存分配表，及rss磁碟分配表，對所有lun進行提取。提取過程中，對不通過的xor條帶進行人工分析，確定離線情況(本例沒有掉線磁碟)，確定得到最佳重組結論，再通過frombyte recovery for hp-eva進行恢復。
【資料恢復結論】
資料100%恢復成功。
oracle刪除資料後的恢復
要達到刪除資料，有以下幾種方式都可以 1 delete 2 drop乙個表 3 truncate乙個表 重要的不是怎麼刪除乙個表，而是誤刪除資料後怎麼立即恢復 不考慮全庫備份和利用歸檔 日誌 對於delete方法,可以利用oracle提供的閃回方法 如果在刪除資料後還沒做大量的操作 只要保證被刪除資...
oracle刪除資料後的恢復
要達到刪除資料，有以下幾種方式都可以 a 確定刪除資料的時間 在刪除資料之前的時間就行，不過最好是刪除資料的時間點 b 用以下語句找出刪除的資料 select from 表名 as of timestamp to timestamp 刪除時間點 yyyy mm dd hh24 mi ss c 把刪除...
Oracle表資料被刪除後的恢復
在oracle資料庫使用過程中，會存在表中資料被誤刪除的情況，如果被刪除的資料有備份，則可從備份中獲取，若表資料被刪除至發現被刪除期間沒有進行備份，則可使用oracle閃回技術進行資料恢復 適用於短時間內被刪除的資料 可恢復資料的時間根據資料庫的配置有所不同 select from 表名 as of...