毛病一：備份工作不力
按時做好服務器數據備份，這是防止數據丟失最使用的方法之一。但是，在數據備份這樣一件簡單的工作上，我們有些網絡管理員，也會犯毛病。
1. 備份文件名字不按日期編寫，難以區分。
如一個朋友，他在一家商場中做網絡管理員。商場采用了一套管理系統，用來記錄日常的業務。但是，這套軟件有個不好的方面就是備份作業設計得不好。其可以自動備份，但是，都只能以一個文件名字備份。如此的話，每天都要去手動地拷貝一下備份文件，這顯然很麻煩，也是很不安全的一件事情。后來我朋友聽從了我的建議，利用服務器的任務計劃，每當服務器備份好數據以后，就自動把備份文件考到其他目錄上去，并自動改名，在原先的名字后面加上日期的編號。
2. 備份文件不在異地備份，出了問題后悔莫及。
備份文件一般不僅要在本機進行備份，而且，還必須要在異地也進行備份。如此，才能夠防止因為服務器硬盤的損壞，而導致數據的丟失。
以前有家企業，規規矩矩地每天對數據進行備份，一周六天差異備份、一次完全備份。但是，問題是其只把備份文件在本機上備份，而沒有在其他機器上備份。雖然說，硬盤一般來說不容易損壞，但是，天有不測風云。一天，他們企業的服務器不知道怎么回事情，竟然被偷了。而因為其備份文件都存在本機上，在異地上的備份文件還是一個月以前的。到這個時候，網絡管理員再后悔也來不及了，畢竟沒有后悔藥吃。后來沒辦法，只好加好幾個通宵，把辦公室文員都掉過來輸單據，才把一個月的單據補齊。從此之后，網絡管理員就學聰明了，不但在本機上保存備份文件，而且，還在異地的兩個硬盤上，保存備份文件，以防不時之需。
3. 備份文件沒做測試，不知道是否可用。
這是筆者以前犯的一個錯誤。那時候，筆者的公司采用了一套平臺型的進銷存管理軟件，其后臺數據庫是ORACLE的。當時，筆者對數據庫的了解也不是很多，只是會一些簡單的操作，于是根據用戶的需要，在這個軟件平臺上，添加了一些簡單的應用。如在后臺，增加了一些表格及視圖。本來沒什么問題的，但是，在后來數據庫還原的時候，卻出現了問題。筆者自己新建的一些表格或者視圖，有些竟然恢復不了。是怎么一回事情呢?經過測試，原來在筆者所建的視圖當中，有些字段運用的是中文名字。而有中文名字字段的視圖，在恢復的時候，恢復不過去。筆者初步估計是在備份的時候，就出現了問題。怎么辦呢?沒辦法，只要重新建視圖。還好，筆者平時對所做的更改都有詳細的文檔說明，所以，修改起來，難度也不是很大。要是那時做自定義功能的時候，沒有制作說明文檔的話，那筆者現在真的不知道該如何是好了。
所以，我們數據備分策略制定好以后，一定要對其進行測試，看備份文件是否可用。不要到了需要用到的時候，才發現不可用，那時候，發現的就太遲了一點。在生產管理上，不是有首件檢測嗎;在文件備份上，也需要如此。
4. 文件備份策略制定不合理。
有家企業在每個客戶端上安裝了數據備份軟件。其備份的策略是，在電腦關機之前，自動向服務器備份特定文件夾下的文件。大家想想，一個企業有近200臺的電腦，每次下班關機之前，一起向文件服務器發送文件，那網絡擁堵有多厲害?用戶抱怨，每次下班電腦關機都要等個十分鐘;有些等不及了，看電腦停在關機畫面上，遲遲沒有動作，就直接按電源關掉了，導致文件備份沒有成功;而有些人呢，掌握了其中的訣竅，提前半個小時就關機了，那速度非常得快。
這明顯是文件備份策略制定的不合理，人為地導致網絡的擁塞。后來，該企業改進了備份策略。對于公司不同的部門，采取了不同的備份時間。如此，就分散了網絡流量，再也不會出現遲遲關不了機的情況。
最后，還需要再強調一下，對于備份文件的管理，一定要注意測試。一是對于備份策略的測試，包括時間是否起作用，差異備份是否成功;二是對于備份的文件要進行恢復測試，看準備份的內容是否準確。事先花點小時間做好測試工作，以后在遇到問題時，才能夠快速有效地解決。
