般類型提示
eth1: Too much work at interrupt, IntrStatus=0x0001
這條提示的含意為. 某網(wǎng)卡的中斷請求過多. 如果只是偶爾出現(xiàn)一次可忽略. 但這條提示如果經(jīng)常出現(xiàn)或是集中出現(xiàn),那涉及到的可能性就比較多有可能需要進行處理了.。可能性比較多,如網(wǎng)卡性能;服務器性能;網(wǎng)絡(luò)攻擊..等等。
IPVS: incoming ICMP: failed checksum from 61.172.0.X!
服務器收到了一個校驗和錯誤的ICMP數(shù)據(jù)包。 這類的數(shù)據(jù)包有可能是非法產(chǎn)生的垃圾數(shù)據(jù).但從目前來看服務器收到這樣的數(shù)據(jù)非常多.一般都忽略。
一般代理服務器在工作時會每秒鐘轉(zhuǎn)發(fā)幾千個數(shù)據(jù)包.收到幾個錯誤數(shù)據(jù)包不會影響正常的工作.這是問我多的一類提示了。
NET: N messages suppressed.
服務器忽略了 N 個數(shù)據(jù)包.和上一條提示類似.服務器收到的數(shù)據(jù)包被認為是無用的垃圾數(shù)據(jù)數(shù)據(jù). 這類數(shù)據(jù)多是由攻擊類的程序產(chǎn)生的。
這條提示如果 N 比較小的時候可以忽略.但如果經(jīng)常或是長時間出現(xiàn)3位數(shù)據(jù)以上的這類提示.就很有可能是服務器受到了垃圾數(shù)據(jù)類的帶寬攻擊了。
UDP: bad checksum. From 221.200.X.X:50279 to 218.62.X.X:1155 ulen 24
UDP: short packet: 218.2.X.X:3072 3640/217 to 222.168.X.X:57596
218.26.131.X sent an invalid ICMP type 3, code 13 error to a broadcast: 0.1.0.4 on eth0
服務器收到了一個錯誤的數(shù)據(jù)包.分別為 UDP校驗和錯誤; 過短的UDP數(shù)據(jù)包; 一個錯誤的ICMP類型數(shù)據(jù). 這類信息一般情況下也是非法產(chǎn)生的。但一般問題不大可直接忽略。
kernel: conntrack_ftp: partial 227 2205426703+13
FTP_NAT: partial packet 2635716056/20 in 2635716048/2635716075
服務器在維持一條FTP協(xié)議的連接時出錯. 這樣的提示一般都可以直接忽略。
網(wǎng)絡(luò)通信嚴重出錯提示
NETDEV WATCHDOG: eth1: transmit timed out
eth1: link down
eth1: link up, 10Mbps, half-duplex, lpa 0x0000
eth2: link up, 100Mbps, full-duplex, lpa 0x41E1
setting full-duplex based on MII #24 link partner capability of 45e1
這些提示是網(wǎng)絡(luò)通信中出現(xiàn)嚴重問題時才會出現(xiàn).故障基本和網(wǎng)絡(luò)斷線有關(guān)系. 這幾條提示分別代表的含意是 某塊網(wǎng)卡傳送數(shù)據(jù)超時; 網(wǎng)卡連接down; 網(wǎng)卡連接up,連接速率為10/100Mbps,全/半雙功.這里寫到的后三行的提示比較類似. 出現(xiàn)這類提示時必須注意網(wǎng)絡(luò)連接狀況進行處理!!!
NIC Link is Up 100 Mbps Full Duplex
情況和 kernel: eth1: link up,...相同.指某塊網(wǎng)卡適應的連接速率. 一般認為沒有說明哪個網(wǎng)卡down,只是連續(xù)出現(xiàn)網(wǎng)卡適應速率也是通信有問題。如果是網(wǎng)線正常的斷接可以忽略這類的信息。
eth0: Transmit timed out, status 0000, PHY status 786d, resetting... eth0: Reset not complete yet. Trying harder.
條提示 網(wǎng)卡關(guān)送數(shù)據(jù)失敗. 復位網(wǎng)卡. 第二條提示 網(wǎng)卡復位不成功.... 這些提示都屬于嚴重的通信問題。
eth1: Transmit error, Tx status register 82. Probably a duplex mismatch. See Documentation/networking/vortex.txt Flags; bus-master 1, dirty 9994190(14) current 9994190(14) Transmit list 00000000 vs. f7171580. 0: @f7171200 length 800001e6 status 000101e6 1: @f7171240 length 8000008c status 0001008c ....
這個提示是3com網(wǎng)卡特有的. 感覺如果出現(xiàn)量不大的話也不會影響很嚴重. 目前看維一的解決辦法是更換服務器上的網(wǎng)卡。 實在感覺3com的網(wǎng)卡有些問題...
服務器報警程序的提示
0001 ##WMPCheckV001## 2005-04-13_10:10:01 Found .(ARP Spoofing sniffer)! IP:183 MAC:5 0002 ##WMPCheckV001## 2005-04-07_01:53:32 Found .(MAC_incomplete)! IP:173 mac_incomplete:186 0003 ##WMPCheckV001## 2005-04-17_16:25:11 Found .(HIGH_synsent)! totl:4271 SynSent:3490 0004 ##WMPCheckV001## 20......
這是由報警程序所引起的提示. 詳細的信息需要用報警程序的客戶端進行實時接收.詳細情況請查看"告警模塊和日志"。
巧妙設(shè)置掃描的簇范圍
設(shè)置掃描簇的范圍是一個有效加快掃描速度的方法。像EasyRecovery的高級自定義掃描方式、FinalData和File Recovery的默認掃描方式都可以讓你設(shè)置掃描的簇范圍以縮短掃描時間。當然要判斷目的文件在硬盤上的位置需要一些技巧，這里提供一個簡單的方法，使用操作系統(tǒng)自帶的硬盤碎片整理程序中的碎片分析程序（千萬小心不要碎片整理啊，只是用它的碎片分析功能），在分區(qū)分析完后程序會將硬盤的未使用空間用圖形方式清楚地表示出來，那么根據(jù)圖形的比例估計這些未使用空間的大致簇范圍，搜索時設(shè)置只搜索這些空白的簇范圍就好了，對于大的分區(qū)，這確實能節(jié)省不少掃描時間。
一、服務器租用的存儲非常重要的，這個我想大家都知道，硬盤作為服務器的主要存儲設(shè)備，硬盤是一種技術(shù)含量高、制造精密的設(shè)備，現(xiàn)在的服務器硬盤已經(jīng)達到1萬轉(zhuǎn)以上，普通的SATA硬盤也非常接近這個轉(zhuǎn)速，在實際的應用中，一點小問題都可能造成服務器硬盤的故障，所以一般服務器租用都采用 Raid磁盤陣列存儲，這樣就可以增加服務器硬盤的抗故障能力。
二、除了以上的方法外，對于一些重要的數(shù)據(jù)還要進行實時的備案，推薦企業(yè)用戶、商務用戶架構(gòu)的網(wǎng)絡(luò)服務器，選用磁帶機配合專業(yè)備份軟件(VeritasNetbackup、CAArcserver)，定時進行備份，如果條件允許的話能每天備份。
三、因為個人的錯誤操作原因，導致服務器文件不小心被刪除或者丟失的話，可在網(wǎng)上下載一些恢復軟件(DataRecove,Easyrecove 等)嘗試來進行恢得，當然，做之前可以先用Ghost軟件做個磁盤全備份，同時在恢復時是接從盤。如果你對自己的恢復結(jié)果不滿意，還可以到電腦城找專業(yè)的數(shù)據(jù)恢復公司幫你進行硬盤數(shù)據(jù)恢復。
四、要經(jīng)常關(guān)心服務器的運行狀況，對于服務器的指示和警示燈要多留意。一般來講，服務器租用外觀都有每一塊硬盤指示燈，正常情況下一般會是綠色，指示燈出現(xiàn)特殊情況時，就需要采用相關(guān)措施，仔細檢查硬盤設(shè)備是否正常。一旦硬盤受損或者出現(xiàn)故障，不要擅自處理，要找有經(jīng)驗的技術(shù)人員作出詳細檢查再作處理方案。