数据库备份那点事儿

Posted 2020-08-19 KK

写在前面

　　最近一直在整理数据库最佳实践的东西，我也会将各种文章建议，同步到博客园，希望能够帮助更多的人了解数据库，轻松玩转数据库，同时也减轻运维人员的工作压力，毕竟熟能生巧，熟练既是效率。

　　数据库备份老生常谈的话题，一搜索数据库备份可能上千上万篇，那么为什么还要写一篇？因为重要！而往往却不能引起运维人员的重视。上周还帮助一个客户恢复了数据，原因是断电，启动服务器后发现磁盘损坏，重要的系统页大面积损坏。使用常规数据库恢复手段全无用，使用第三方恢复工具也只能恢复部分数据，根本无法满足业务的正常运转，数据是企业的命根子，丢了，找不回来怎么办？ 难道要经历一次这样的洗礼才能体会到备份的重要性么？

　　数据库备份是个很重的话题，太多东西无法写在同一篇文章中，另外这是一篇大量文字的扫盲文章，不足之处希望大家多多包涵。

一些名词

　　完整数据库备份：完整数据库备份就是复制数据库里的所有信息，通过单个完整备份，就能将数据库恢复到某个时间点的状态。

注：由于数据库备份是一个在线的操作，一个大的完整数据库备份可能需要一个小时甚至更长的时间，数据库在这段时间里还会发生变化，所以完整数据库备份还要对部分事务日志进行备份，以便能够恢复数据库到一个事务一致的状态。

　　文件备份：文件备份指备份一个或多个文件或文件组中的所有数据。

注：在完整恢复模式下，一整套完整文件备份和涵盖所有文件备份的日志备份合起来等同于完整数据库备份。

使用文件备份能够只还原损坏的文件，而不用还原数据库的其余部分，从而可加快恢复速度。例如，如果数据库由位于不同磁盘上的若干个文件组成，在其中一个磁盘发生故障时，只需还原这个故障磁盘上的文件的备份，其他磁盘上的文件无须还原，这样会缩短还原时间。
　　部分备份：部分备份与完整数据库备份类似，但是部分备份默认只包含数据库可读写部分，数据库的只读文件将不会被备份。

注：因为只读部分是不会发生变动的，总是去备份它有点浪费时间与精力所以部分备份在希望不备份只读文件组时非常有用。部分备份可以说是数据库备份和文件备份之间的一个中间类型。如果一个数据库里没有只读文件，那么部分备份和数据库备份就没什么差别。　

　　差异备份：差异备份要求数据库之前做过一次完整备份。差异备份仅捕获自该次完整备份后发生更改的数据，这个完整备份被称为差异备份的“基准”。差异备份仅包括建立差异基准后更改的数据。差异备份比差异基准更小且更快，便于执行频繁备份，从而降低了数据丢失的风险。

　　日志备份：数据备份集中精力于数据文件的备份。对于日志文件，相应地有事务日志备份。每个日志备份包括创建备份时处于活动状态的部分事务日志，以及先前日志备份中未备份的所有日志记录。不间断的日志备份序列包含数据库的完整(即连续不断的)日志链。在完整恢复模式下(或者在大容量日志恢复模式下的某些时候)，连续不断的日志链可以将数据库还原到任意时间点。

　　尾日志备份：“结尾日志备份”捕获尚未备份的任何日志记录（“结尾日志”），以防丢失所做的工作并确保日志链完好无损。 在将 SQL Server 数据库恢复到其最近一个时间点之前，必须先备份数据库的事务日志。 结尾日志备份将是数据库还原计划中相关的最后一个备份。

注意：并非所有还原方案都要求执行结尾日志备份。 如果恢复点包含在较早的日志备份中，则无需结尾日志备份。 此外，如果您准备移动或替换（覆盖）数据库，并且在最新备份后不需要将该数据库还原到某一时间点，则不需要结尾日志备份。

　　仅复制备份(Copy-Only)：独立于常规SQL Server备份序列的SQL Server备份。通常，进行备份会更改数据库并影响其后备份的还原序列。但是，有时在不影响数据库全部备份和还原过程的情况下，为特殊目的而进行备份还是有用的。为实现此目的，SQL Server引人了下列两种仅复制备份
　　(1)仅复制完整备份
仅复制完整备份也备份整个数据库的内容。它和正常的完整备份的区别是，做完了以后差异备份的基准不会变，因此不影响差异备份序列。
　　(2)仅复制日志备份
仅复制日志备份只备份当前日志文件里现有的内容，但是不会清空日志文件里备份下的日志。因此，下次再做正常日志备份的时候，这些内容还会被再次备份下来，从而不影响常规日志备份的序列。这种备份主要用在以下情况:数据库上已经有了一个备份计划任务在运行，但是现在需要紧急做一个日志备份，但同时不能影响到原有的备份序列。

　　恢复模式：SQL Server 备份和还原操作发生在数据库的恢复模式的上下文中。 恢复模式旨在控制事务日志维护。 “恢复模式”是一种数据库属性，它控制如何记录事务，事务日志是否需要（以及允许）进行备份，以及可以使用哪些类型的还原操作。 有三种恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式。 通常，数据库使用完整恢复模式或简单恢复模式。 数据库可以随时切换为其他恢复模式。

恢复模式	说明	工作丢失的风险	能否恢复到时点？
Simple	无日志备份。 自动回收日志空间以减少空间需求，实际上不再需要管理事务日志空间。 有关简单恢复模式下数据库备份的详细信息，请参阅完整数据库备份 (SQL Server)。 简单恢复模式不支持要求事务日志备份的操作。 在简单恢复模式中不能使用以下功能： -日志传送 -AlwaysOn 或数据库镜像 -没有数据丢失的介质恢复 -时点还原	最新备份之后的更改不受保护。 在发生灾难时，这些更改必须重做。	只能恢复到备份的结尾。 有关详细信息，请参阅完整数据库还原（简单恢复模式）。  有关简单恢复模式的更多深入说明，请参阅由 MSSQLTips! 人员提供的 SQL Server 简单恢复模式。
Full	需要日志备份。 数据文件丢失或损坏不会导致丢失工作。 可以恢复到任意时点（例如应用程序或用户错误之前）。 有关完整恢复模式下的数据库备份的信息，请参阅 完整数据库备份 (SQL Server) 和完整数据库还原（完整恢复模式）。	正常情况下没有。 如果日志尾部损坏，则必须重做自最新日志备份之后所做的更改。	如果备份在接近特定的时点完成，则可以恢复到该时点。 有关使用日志备份还原到故障点的信息，请参阅将 SQL Server 数据库还原到某个时间点（完整恢复模式）。 注意：如果有两个或更多必须在逻辑上保持一致的完整恢复模式数据库，则最好执行特殊步骤，以确保这些数据库的可恢复性。 有关详细信息，请参阅包含标记的事务的相关数据库的恢复。
大容量日志	需要日志备份。 是完整恢复模式的附加模式，允许执行高性能的大容量复制操作。 通过使用最小方式记录大多数大容量操作，减少日志空间使用量。 有关尽量减少日志量的操作的信息，请参阅事务日志 (SQL Server)。 有关大容量日志恢复模式下的数据库备份的信息，请参阅完整数据库备份 (SQL Server) 和完整数据库还原（完整恢复模式）。	如果在最新日志备份后发生日志损坏或执行大容量日志记录操作，则必须重做自该上次备份之后所做的更改。 否则不丢失任何工作。	可以恢复到任何备份的结尾。 不支持时点恢复。

常规建议

　生产系统不要使用简单恢复模式

　　建议说明：简单恢复模式并不适合生产系统。因为对生产系统而言，丢失最新的更改是无法接受的，我们建议使用完整恢复模式。

　　基础小知识：在简单模式下，可以采用两种备份方式：全备份和差异备份。这两种备份消耗都会比较大，所以不是可以频繁备份的类型，所以在两次备份间隔的时间段内数据都存在丢失的风险。微软官方文档 ：简单恢复模式下的备份

　　实际场景小故事：很多维护人员喜欢简单模式，因为简单模式自动回收日志空间以减少空间需求，实际上不再需要管理事务日志空间。但实际情况时因为明白这其中的奥妙原理么？并不是，甚至相反，我在很多的客户系统看到跑着上TB的数据，而数据库备份模式竟然是简单模式，只有每天的全备份，连差异备份都没有。

　　我一般会问：“现在的备份模式可能会丢一天的数据，公司能接受么？”　　

　　维护人员：“那肯定不能接受呀！”

　　我又问：“那为什么不采用更好的备份方式呢？”

　　维护人员：“我也不太懂，不知道该怎么做，数据库跑这么久了，没那么容易坏吧？”

　　

 

　使用完整恢复模式，要有日志备份计划

　　建议说明：完整恢复模式使用日志备份在最大范围内防止出现故障时丢失数据，这种模式需要备份和还原事务日志（“日志备份”）。使用日志备份的优点是允许您将数据库还原到日志备份中包含的任何时点（“时点恢复”）。可以使用一系列日志备份将数据库前滚到其中一个日志备份中包含的任意时点。

　　基础小知识：完整模式下，可以采用日志的频繁备份来缩小数据丢失的时间，比如：00:00点做了全备份，每10分钟一次日志备份，那么当23：50数据库损坏，只需要使用0点的全备份和损坏之前日志备份就可以还原到23:50的数据，而不是丢失整个近一天的数据。日志备份会使不活动的日志重用，这样也解决了完整模式下日志不断增长的问题。微软官方文档 ：在完整恢复模式下备份

　　实际场景小故事：很多客户的系统采用了完整恢复模式，但是缺少日志备份，那么这样和简单模式有什么区别呢？有区别，没有降低数据丢失的风险反而增加了日志的空间消耗。很多时候被问到这样的问题，数据库日志很大，怎么收缩？很多数据库新手可能完全不知道日志备份的作用，而采用把恢复模式改成简单，然后收缩！再改回完整模式！比较搞笑的问题还有数据库搭建了镜像或AlwaysOn可用组（必须完整恢复模式），竟然把镜像拆掉，然后改成简单，收缩后

再重新搭建....很多时候只需要一个日志备份就可以解决的问题！

 

　系统数据库备份

　　SQL Server 维护一组系统级数据库（称为“系统数据库”），这些数据库对于服务器实例的运行至关重要。 每次进行大量更新后，都必须备份多个系统数据库。 必须备份的系统数据库包括 msdb、 master和 model。 如果有任何数据库在服务器实例上使用了复制，则还必须备份 distribution 系统数据库。 备份这些系统数据库，就可以在发生系统故障（例如硬盘丢失）时还原和恢复 SQL Server 系统。

　　而往往系统数据库得不到关注，在维护任务中是缺失的。

　使用压缩备份

　　数据库往往比较大，那么同样备份文件占用的空间也很大，由于常常要保留几天甚至一周的数据在本地磁盘，压缩备份可以极大的减少备份文件对磁盘空间的占用。同时因为文件小了，备份产生IO的压力也会降低，但会对消耗比较多的CPU。

　　

 

　使用校验和（CHECKSUM）

　　此选项主要是在备份的时候校验是否存在残缺页（也可以理解成是否有数据页损坏），开启此选项可以在备份时及时发现数据是否存在问题。

　　

 

　　详细说明请参见：数据库备份checksum选项你会用么？

　验证备份可用性

　　验证备份但不还原备份，检查备份集是否完整以及整个备份是否可读。 但是，RESTORE VERIFYONLY 不尝试验证备份卷中的数据结构。 在Microsoft SQL Server 中，RESTORE VERIFYONLY 得到了增强以对数据进行附加检查，从而提高检测到错误的可能性。 其目标是尽可能接近实际的还原操作。

　　RESTORE VERIFYONLY 执行下列检查：

• 备份集是否完整以及所有卷是否可读。

• 数据库页中的一些标头字段，例如页 ID（就如同要写入数据一样）。

• 校验和（如果介质中提供的话）。

• 目标设备中是否有足够的空间。

 

　有异地备份

　　防止本地磁盘损坏或者整个机房故障，对这种至关重要的数据，必须采取异地备份的办法。

　定期检查磁盘空间

　　很多客户运维的策略不完善，同时又缺少巡检的过程，很多时候备份作业创建后没有及时维护，导致磁盘空间被占满，备份作业失败。

 

简单与完整模式下的备份详细描述

　　简单恢复模式下的备份

　　简单恢复模式是最简单的备份和还原形式。该恢复模式同时支持数据库备份和文件备份，但不支持日志备份。事务日志数据仅与关联的用户数据一起备份。缺少日志备份可简化备份和还原的管理。但是，数据库只能还原到最近备份的末尾。

　　下图显示了简单恢复模式下最简单的备份与还原策略。此策略仅使用包含数据库中所有数据的完整数据库备份。存在五个完整数据库备份，但只需要还原最近的备份（在 t5 时点执行的备份）。还原此备份会将数据库恢复到 t5 时点。由 t6 框表示的所有后续更新都将丢失。

 

 

　　最大程度地降低工作丢失的风险

 

　　在简单恢复模式下，在执行下次完整备份或差异备份前，所做工作丢失的风险会随时间的推移而增加。与完整备份不同的是，差异备份仅包括自上次完整备份以来所做的更改。因此，我们建议您在不影响备份管理的前提下时常备份，以免丢失大量数据。

下图显示了仅使用数据库备份的备份计划的工作丢失风险。此策略仅适用于可经常备份的小型数据库。

下图显示的备份策略通过使用差异数据库备份对数据库备份进行补充，从而减少了工作丢失风险。在第一个数据库备份完成后，会接着进行三个差异数据库备份。第三个差异备份足够大，因而下一个备份为完整数据库备份。该数据库备份将成为新的差异基准。

 

 

　　在完整恢复模式下备份

　　完整恢复模式使用日志备份在最大范围内防止出现故障时丢失数据，这种模式需要备份和还原事务日志（“日志备份”）。使用日志备份的优点是允许您将数据库还原到日志备份中包含的任何时点（“时点恢复”）。可以使用一系列日志备份将数据库前滚到其中一个日志备份中包含的任意时点。请注意，为了最大程度地缩短还原时间，可以对相同数据进行一系列差异备份以补充每个完整备份。

假定可以在发生严重故障后备份活动日志，则可将数据库一直还原到没有发生数据丢失的故障点处。使用日志备份的缺点是它们需要使用存储空间并会增加还原时间和复杂性。

 

　　下图显示了在完整恢复模式下的最简单的备份策略。在此图中，已完成了完整数据库备份 Db_1 以及两个例行日志备份 Log_1 和 Log_2。在 Log_2 日志备份后的某个时间，数据库出现数据丢失。在还原这三个备份前，数据库管理员必须备份活动日志（日志尾部）。然后还原 Db_1、Log_1 和 Log_2，而不恢复数据库。接着数据库管理员还原并恢复结尾日志备份 (Tail)。这将把数据库恢复到故障点，从而恢复所有数据。

 

　　最大程度地降低工作丢失的风险

 

 在第一个完整数据库备份完成并且常规日志备份开始之后，潜在的工作丢失风险的存在时间仅为数据库损坏时以及执行最新的常规日志备份时。因此，建议经常执行日志备份，以将工作丢失的风险限定在业务要求所允许的范围内。

下图显示的备份策略使用差异数据库备份来补充完整数据库备份和日志备份。事务日志备份可缩短潜在的工作丢失风险的存在时间，使该风险仅在最新日志备份 t14 之后存在。进行一系列差异备份（三次备份）来减少在出现故障时需要还原的事务日志数。第三个差异备份很大，足以使下一个备份成为完整数据库备份。该数据库备份将成为新的差异基准。

在此图中的第一个数据库备份创建之前，数据库存在潜在的工作丢失风险（从时间 t0 到时间 t1）。该备份建立之后，例行日志备份将工作丢失的风险降为丢失自最近日志备份之后所做的更改（在此图中，最近备份的时间为 t14）。如果在最新备份后出现故障，数据库管理员将尝试备份日志尾部（尚未备份的日志）。如果结尾日志备份成功，则数据库管理员可以通过将数据库还原到故障点来避免任何工作丢失。

更多建议

1. 定期进行数据备份（完备或差异备份）和日志备份。
2. 使用压缩备份来减少磁盘空间占用和提高备份效率。
3. 定期检查磁盘剩余空间和备份文件增长情况，以确保有足够空间进行下一次备份。
4. 使用校验和（CHECKSUM）来检查数据完整性。
5. 使用RESTORE VERIFYONLY来验证备份可用性。
6. 根据数据变动情况决定完整备份和差异备份的频率。
7. 根据日志生成速度来决定日志备份的频率。
8. 优先使用脚本来备份数据库。
9. 如果使用维护计划备份，请确认是否需要生成“报告和记录”。
10. 定期检查日志文件大小和VLF数量。
11. 定期清理msdb数据库中备份和还原记录。
12. 在磁盘空间充足条件下，应在本地保留一份最新备份（最后一次完备及之后备份文件）。
13. 定期复制数据库备份至其他服务器，并定期检查异地备份。
14. 在备用服务器上还原数据库以测试备份可用性，并运行DBCC CHECKDB来检查数据完整性。
15. 定期归档历史数据，条件允许情况下，应将历史数据归档到专门存放历史记录的数据库。
16. 除有特殊需求修改数据库恢复模式外，应保证数据库运行在完整恢复模式下。
17. 当数据库从简单恢复模式切换到完整恢复模式下，应立即完整备份或差异备份来修复断裂的日志链。
18. 当数据库从大日志恢复模式切换到完整恢复模式下，应立即日志备份，以保证此后可按照时间点还原。
19. 在做任何可能存在风险的操作前，请确保先确保备份有效。
20. 维护一个列表，记录数据库进行备份的频率、路径以及异地备份的路径等信息，以便故障时能第一时间找到备份。
21. 关于备份的误区：SQL Server误区30日谈-Day30-有关备份的30个误区

 

--------------博客地址---------------------------------------------------------------------------------------

原文地址: http://www.cnblogs.com/double-K/

如有转载请保留原文地址! 

 

-----------------------------------------------------------------------------------------------------

 

　　总结 ：备份真的很重要！文章讲述的东西很少，只想起到一个引起重视的目的！

　　备份的更多更详细的文章，请参见：微软官方文档，备份概述

 ----------------------------------------------------------------------------------------------------

注：此文章为原创，欢迎转载，请在文章页面明显位置给出此文链接！
若您觉得这篇文章还不错请点击下右下角的推荐，非常感谢！