數據庫備份策略在維護系統數據安全起著非同小可的作用，好的備份策略應該考慮保證數據的安全，並且操作較為方便。 基本過程很簡單，如下：
1．備份到本地硬盤：
dump transaction with truncate_only
dump database … to …
dump transaction
。。。
2．當裝載數據庫和事務日志時，為防止其他用戶對數據庫的操作，須把數據庫設置為 dbo use only。
進行裝載時的順序為：
dump transaction with no_truncate
load database database_name from ...
load transaction database_name from ...
。。。
online database
也可以用until指定恢復到某個時間
使用阈值管理
可以使用阈值管理，在阈值管理中安排當超過某個阈值時自動轉儲事務日志。當超過閥值以後，SQL Serve中斷或掛起試圖寫這個日志的用戶事務。對每一個掛起的事務 向errorlog 發一條消息；然後執行sp_thresholdaction
sp_thresholdaction用戶自己編寫
create procedure sp_thresholdaction
@dbname varchar（30）,
@segmentname varchar（30）,
as
dump transaction @dbname to "DEVICE"
print "LOG DUMP: %1! for %2! dumped", @segmentname, @dbname
其中參數 ：
@dbname 為達到閥值的數據庫名；
@segmentname 為達到閥值的段名；
用戶數據庫損壞的處理
如果數據庫處於suspect狀態，無法用drop database 刪除時：
dbcc dbrepair (db_name, dropdb)
create database db_name on dev_name for load
load database db_name from dump_device
master庫損壞的處理
使用 buildmaster -m 重建一個新的master數據庫；
buildmaster 建立 master 設備並在這個設備上建立 master， model， tempdb 庫。
-m 選項只重新寫 master 庫， 而不修改配置塊或初始化 master 設備。
以單用戶方式重啟動服務器， 如果需要的話， 則需增加轉儲設備；
從備份裝載master數據庫；
用 startserver 重啟 SQL Server；
檢查一致性： 對每一個數據庫運行 dbcc checkalloc，並對重要的表進行檢查；
但是，當我們問及Sybase的技術支持是否建議使用threshold 時，他們並不積極建議這樣做，理由是自動化操作往往會出現一些難於預料的結果。當然，要是有那麼負責的dba，天天定時手工備份，當然是再好不過了。
基本的備份操作是簡單，但是我們在實際實施備策略時，往往會考慮這樣那樣的問題，也會出現一些意想不到的問題，比如：
1、是整庫備份還是增量備份
2、每天什麼時候備份，備份時間怎麼安排
3、萬一需要恢復數據庫，當前的備份能恢復到一個什麼程度
4、數據庫在恢復時可能出現哪些緊急情況
等等...
歡迎大家就這個主題進行一下討論，以激發出一些好的想法和經驗，以共同增強系統數據的安全性！
