数据库备份策略在维护系统数据安全起着非同小可的作用，好的备份策略应该考虑保证数据的安全，并且操作较为方便。 基本过程很简单，如下：
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、数据库在恢复时可能出现哪些紧急情况
等等...
欢迎大家就这个主题进行一下讨论，以激发出一些好的想法和经验，以共同增强系统数据的安全性！