作为数据库管理员最最痛苦的莫过于，当数据库宕机的时候需要找备份，但在这个时候突然发现备份文件也是坏的，这就意味着数据会丢失，为此可能会丢掉职位，饭碗不保，所以为此，我们一定要保证好备份的完整性，一般发生这种情况的原因莫过于一下几种：

1、备份文件和数据库放在同一个（或一组）的物理磁盘上。磁盘出现故障，备份也保不住了。

2、备份介质随坏，或者做的是网络备份，数据在网络传输中发生了损坏。

3、数据库在做完整备份、文件备份或者文件组备份的时候，里面的内容就已经有了随坏。

所以基于此，我们要避免的就是以上三种情况的发生，此外还有一种情况就是SQL Server在做数据库备份的时候为节省时间，基本只是很简单的把数据页面拷贝下来，不会做一致性检查。但是在恢复的时候，需要将数据库恢复（Recover）到事务一致性的一个时间点。如果备份中的损坏妨碍了SQL Server的前滚后滚（Redo和Undo）、恢复动作就会遇到错误，这时候我们该如何做呢？

其实在现实坏境中，遇到此问题大部分是硬件错误导致，但是该类错误往往会永久的随坏备份文件里的内容，在SQL 2005之前的版本，遇到此问题只能去找更早的备份。但这就意味着会有产生很多的数据丢失。

所以在SQL 2005之后引入了一个新的“忽略错误”的恢复功能，这种情况在危难的是时候可以很好的发挥作用。

该命令为：CONTINUE_AFTER_ERROR

该命令是会恢复（RESTORE）命令里的一个新选项。它将使还原操作跳过错误继续进行，并还原SQL Servr现有所有功能还原的所有内容。数据还原结束后，可以应用后续事务日志备份，将数据库恢复。如果日志恢复时遇到错误，SQL Server会在日志中报告，并且不让用户访问和操作这些事务有关的页面。数据库将在尽可能的情况相爱联机。所以大部分情况下，数据库整体还是能恢复出来，只是部分数据有可能会丢失。

数据丢失取决于遇到的错误。例如，一般数据页中的错误只会引起该页进入可可疑状态，但数据库恢复还是会继续。有问题的页面编号将被写入磁盘并记录到suspect_pages表和错误日志中，提醒管理员在恢复结束后继续处理他们。如果不设置CONTINUE_AFTER_ERROR，SQL Server只要遇到一个页面有问题，整个恢复动作都会停止。

如果错误发生在一些比较关键的地方，比如某个数据文件的文件头信息，那么恢复还是有可能完全失败，数据库无法恢复。所有这个方法只供救火的时候用，不能保证每次使用的效果。

在使用该命令完成还原数据库后，记得要检查错误日志以了解有关的详细信息。

该命令语法如下：

RESTORE DATABASE database_nameFROM backup device WITH CONTINUE_AFTER_ERROR,NORECOVERY....

管理员在忽略错误继续执行还原顺序结束时，使用DBCC CHECKDB修复数据库。要使得CHECKDB在使用RESTORE CONTINUE_AFTER_ERROR 后以最大的一致性运行，建议在DBCC CHECKDB命令中使用WITH TABLELOCK选项。在极个别情况下，可能没有没有足够的信息来修复数据库，CHECKDB也没有办法修好数据库，数据丢失将不可避免。不是说，有了RESTORE CONTINUE_AFTER_ERROR,备份坏掉也没关系。

其实最关键的是还是建立备用服务器，改变单一磁盘的尴尬。

CONTINUE_AFTER_ERROR只不过是通过命令跳过一切它能够跳过错误，将所有还能读出来的数据恢复出来，从而最大程度的挽回数据。但是有些数据对一致性要求比较高的系统这样是不能接受的。

对于这样的系统，在建立备份和选择恢复策略的时候，就要考虑到最坏的情况，预先想好方案，将损失降到最低。

可以找一台备用机，做Log Shipping，这个方法值得推荐，主要是成本低

有以下几点优点：

1、比起物理镜像之类的技术，这种方案比较经济。备用服务硬件的要求不高，只要硬盘足够大。

2、虽然SQL Server提供了若干备份校验机制，但是确保备份完整可靠性的唯一办法就是真正的去恢复它。

3、提前恢复备份，使得真正灾难发生时，只需要恢复最后一个日志备份即可。而不需要在火烧眉毛的时候，去等那漫长的完整备份恢复，可以大大节约灾难恢复时间。

4、备用机上的数据库虽然不能修改，但是可以使用standby参数将数据库恢复到只读模式。可以将一些报表查询工作转移到备用机上，减轻生产服务器的负担。

总之，数据安全非常重要，灾难恢复时间要求很短的数据库，如果没有镜像技术的保证，备用服务器非常必要的。

《SQL Server企业级平台管理实践》读书笔记——当我们的备份都已经损坏的时候该怎么办