上一篇博文探讨了各种恢复模式和备份类型，这一节继续来探讨如何设计备份策略。设计一个数据库的最佳备份策略，会面临如何选择使用哪种恢复模式的问题，因为恢复模式控制着备份和还原的行为。一般来讲，简单恢复模式一般适合用于测试或开发数据库。对于生产数据库，最佳选择通常是完整恢复模式，还可以选择大容量日志恢复模式作为补充。但简单恢复模式有时也适合小型生产数据库（尤其是当其大部分或完全为只读时）或数据仓库使用。
若要为特定数据库确定最佳恢复模式，应考虑数据库的恢复目标和要求，数据使用方式，员工因素以及是否可对日志备份进行管理等。
恢复目标要求 ：
l
不丢失任何更改的重要程度如何？
l
重新创建丢失的数据的难易程度如何？
l
是否有两个或两个以上的数据库在逻辑上必须保持一致？
员工因素 ：
是否雇用系统或数据库管理员？如果没有，那么由谁负责执行备份和恢复操作，如何对他们进行培训？
数据使用方式，针对当前数据库考虑下列问题：
l
数据库中的数据多长时间更改一次？
l
是否有些表明显比其他表修改频繁？
l
是否有关键生产周期？如果有，那么在这些周期中的使用方式是怎样的？数据库是否会经历插入操作和其他更新操作的高峰期？
可能需要计划在非高峰期进行数据备份。当大量使用 I/O 系统时，通常只需使用日志备份。
可能需要计划在非高峰期进行数据备份。当大量使用 I/O 系统时，通常只需使用日志备份。
l
数据库是否会遇到可能无法立即检测到的危险更新或应用程序错误？
如果数据库会遇到这些情况，请考虑使用完整恢复模式。这可以使用日志备份将数据库恢复到特定时间点。
如果数据库会遇到这些情况，请考虑使用完整恢复模式。这可以使用日志备份将数据库恢复到特定时间点。
何时使用简单恢复模式？
如果符合下列所有要求，则使用简单恢复模式：
l
不需要故障点恢复。如果数据库丢失或损坏，则会丢失自上一次备份到故障发生之间的所有更新，但你愿意接受这个损失。
l
愿意承担丢失日志中某些数据的风险。
l
不希望备份和还原事务日志，希望只依靠完整备份和差异备份。
何时使用完整恢复模式？
如果符合下列任一要求，则使用完整恢复模式（还可以选择使用大容量日志恢复模式）：
l
必须能够恢复所有数据。
l
必须能够恢复到故障点。
l
希望可以还原单个页。
l
愿意承担事务日志备份的管理开销。
l
数据库包含多个文件组，并且希望逐段还原读/写辅助文件组（以及可选地还原只读文件组）。
何时使用大容量日志恢复模式？
大容量日志恢复模式作为完整恢复模式的附加补充。建议仅在运行大规模大容量操作期间以及在不需要数据库的时间点恢复时使用该模式。
l
数据库是否会发生周期性的数据库大容量操作？
在该恢复模式下，多数大容量操作仅进行最小日志记录。如果使用完整恢复模式，则可以在执行此类大容量操作前临时切换到大容量日志恢复模式。通常，大容量日志恢复模式与完整恢复模式相似，只是它按最小方式记录多数大容量操作。大容量日志恢复模式仅适合在能够以最小方式记录操作的大容量操作期间使用。建议在其余时间使用完整恢复模式。当完成一组大容量操作后，建议立即切换回完整恢复模式。
在该恢复模式下，多数大容量操作仅进行最小日志记录。如果使用完整恢复模式，则可以在执行此类大容量操作前临时切换到大容量日志恢复模式。通常，大容量日志恢复模式与完整恢复模式相似，只是它按最小方式记录多数大容量操作。大容量日志恢复模式仅适合在能够以最小方式记录操作的大容量操作期间使用。建议在其余时间使用完整恢复模式。当完成一组大容量操作后，建议立即切换回完整恢复模式。
下面就以简单恢复模式和完整恢复模式来设计几个备份策略。
一，简单恢复模式下的备份策略设计：
1，
仅完整数据库备份策略
这种策略仅适用于经常备份的小型数据库，数据丢失风险比较大。
此策略仅使用包含数据库中所有数据的完整数据库备份。例如下图完成5个完整数据库备份后发生灾难，只需要还原最近的备份（在 t5 时点执行的备份）。还原此备份会将数据库恢复到 t5 时点。由 t6 框表示的所有后续更新都将丢失。
在这种策略下为了最大程度降低数据丢失的风险，可以增加备份次数和缩短备份间隔，如下图：
2，完整数据库备份+差异数据库备份策略
这种策略比只使用仅完整数据库备份策略，减少了数据丢失风险。例如下图在第一个完整数据库备份完成后，会接着进行三个差异数据库备份。随着时间推移，第三个差异备份已经足够大，因而下一个备份重新使用完整数据库备份。该数据库备份将成为新的差异基准。
在这种备份策略下，如果在t4时进行“差异数据库备份3”完成后而t5时的“完整数据库备份2”还没进行的情况下发生灾难，只需要先还原t1时的“完整数据库备份1”，接着还原最后一次即t4时的“差异数据库备份3”就可以恢复数据库，但是t4以后的数据会丢失。
二，完整恢复模式下的备份策略设计：
1，
完整数据库备份+日志备份策略
例如下图已完成了完整数据库备份 Db_1 以及两个日志备份 Log_1 和 Log_2。在 Log_2 日志备份后的某个时间，数据库出现数据丢失或灾难。在还原这三个备份前，必须备份活动日志（日志尾部，如果能备份的话）。然后依次还原 Db_1、Log_1 和 Log_2，而不恢复数据库（还原时必须使用norecovery选项），接着还原并恢复结尾日志备份 (还原时必须使用recovery选项)。这将把数据库恢复到故障点，从而恢复所有数据。
2，
完整数据库备份+差异数据库备份策略
例如下图在第一个数据库备份完成后，会接着进行三个差异数据库备份。随着时间推移，第三个差异备份已经足够大，因而下一个备份重新使用完整数据库备份。该数据库备份将成为新的差异基准。
在这种备份策略下，如果在t10时进行“差异数据库备份3”完成后而t13时的“完整数据库备份2”还没进行的情况下发生灾难，还原时，
必须先备份活动日志（日志尾部，如果能备份的话）。
然后依次还原t10时的“完整数据库备份1”，最后一次即t4时的“差异数据库备份3”
（还原时必须使用
norecovery
选项）
，
接着还原并恢复结尾日志备份 (还原时必须使用
recovery
选项)
。这将把数据库恢复到故障点，从而恢复所有数据。
3，
完整数据库备份+差异数据库备份+日志备份策略
这种备份策略可以最大程度地降低数据丢失的风险
，也是比较推荐的备份策略！
例如下图从t1到t12时间段内，进行了
一次完整数据库备份，若干日志备份，三个差异数据库备份。
在这种备份策略下，当t12时的日志备份完成后数据丢失或发生灾难，如何还原数据库呢？步骤如下：
第一步：备份活动日志（日志尾部，如果能备份的话）
第二步：还原t1时的“完整数据库备份1”
第三步：还原t10时的“差异数据库备份3”
第四步：还原t11时的日志备份
第五步：还原t12时的日志备份
第六步：还原第一步的“尾日志备份”
其中第二，三，四，五步还原时必须用norecovery选项，第六步用recovery选项。
根据业务系统级别的不同，一般可以一周进行一次完整数据库备份，一天进行一次差异数据库备份，30分钟或1小时进行一次日志备份。
本文转自terryli51CTO博客，原文链接： http://blog.51cto.com/terryli/484434，如需转载请自行联系原作者
