3.7 数据故障与备份

数据库安全与恢复：一张表讲清权限、备份和日志

适合人群：数据库课程复习、软考/考研基础梳理、想搞懂"备份到底怎么备"的开发者
核心主线：事前防（安全）→ 事中记（日志）→ 事后救（备份+恢复）

---

一、数据库安全性控制

安全性要解决的是：防止不合法使用造成的数据泄露、篡改或破坏。常用手段按"事前—事中—事后"排成五道防线：

措施	说明	通俗样例
用户标识和鉴别	系统最外层的安全保护。先让用户报上身份（用户名/账号），再核对凭证（口令、动态口令、生物特征、智能卡、多因素认证），通过后才允许进入系统	公司门禁：先刷工牌（标识），再刷脸或输密码（鉴别）。没刷卡的人连大门都进不来
存取控制	对合法用户授权，包含两个维度：① 操作类型（SELECT 查询、INSERT 插入、UPDATE 修改、DELETE 删除等）；② 数据对象（哪张表、哪个字段、甚至哪一行）。分为自主存取控制 DAC（GRANT/REVOKE，权限可转授）和强制存取控制 MAC（主体/客体打密级标签，绝密>机密>可信>公开，"向下读、向上写"）	同样是员工，HR 能改"工资"字段，普通员工只能看"姓名+部门"；实习生只有 SELECT 权限，没有 DELETE 权限
视图机制	为不同用户定义不同的视图，把保密数据对无权者隐藏起来，再对视图授权。视图是虚表，只存定义不存数据	给部门经理看 v_dept_salary（只看本部门汇总），给财务看完整工资表。经理就算会写 SQL，也查不到别的部门工资
审计	建立专用审计日志（独立存储以防篡改），自动记录用户对数据库的所有操作（登录、DDL、DML、授权等），供 DBA 事后追查"谁、在什么时候、干了什么"	像银行的监控录像 + 流水账：钱少了不要紧，要紧的是能查出是哪笔交易、哪个柜员操作的
数据加密	对存储的数据（透明加密 TDE、字段级加密、口令哈希加盐）和传输的数据（SSL/TLS、链路加密、端到端加密）做加密处理，使不知道密钥的人无法读懂内容	快递单上的手机号打了星号（存储脱敏/加密）；快递员在路上用密封袋运送（传输加密）

两点容易漏：

• 口令不能明文存，应哈希加盐存储；
• 高安全场景还要考虑推理控制（防止用 SUM/AVG 等聚合查询反推出个人敏感信息）与隐蔽信道防护。

---

二、故障类型与恢复方法

恢复的基本原理就四个字：冗余——用别处保存的冗余数据，重建被破坏或不正确的数据。两大实现技术是数据转储（备份）和登记日志文件。

故障类型	故障原因	影响范围	恢复方法
事务内部故障（可预期）	程序逻辑事先能判断：余额不足、库存不够、用户主动取消等	只影响本事务	由应用程序在程序中预先设置 ROLLBACK 语句回滚
事务内部故障（不可预期）	运算溢出、违反完整性约束、非法输入、死锁被选为牺牲品	只影响本事务	由 DBMS 恢复子系统自动完成：反向扫描日志，对该事务的更新做逆操作（UNDO），直到读到事务开始标记，用户无感知
系统故障（软故障）	断电、操作系统崩溃、DBMS 代码错误、CPU 故障等造成系统停止运转	内存缓冲区全部丢失，外存数据未破坏，所有运行中事务非正常终止	系统重启时自动执行：正向扫描日志 → 已提交事务进 REDO 队列、未完成事务进 UNDO 队列 → 反向扫描 UNDO（用更新前的值覆盖）→ 正向扫描 REDO（用更新后的值重写）。检查点（Checkpoint）不是替代方案，而是用来缩小日志扫描范围、提高恢复效率的优化手段
介质故障（硬故障）	磁盘损坏、磁头碰撞、强磁场干扰等，外存被破坏（最严重，发生概率小但破坏性最大）	数据库或日志文件本身被破坏	需要 DBA 介入：① 装入最近一次转储的后备副本，恢复到转储时的一致性状态；② 装入相应日志文件副本，重做（REDO）自转储以来已提交的事务

一句话区分三类故障：

• 事务故障 = 一个人算错账 → 把这一笔抹掉重来；
• 系统故障 = 停电了，账本没坏但桌上的草稿没了 → 已盖章的重做，没盖章的撤销；
• 介质故障 = 账本被水泡了 → 拿出上个月的备份账本，再把这月的流水重新过一遍。

---

三、数据转储（备份）

1. 按"转储时是否允许并发"分

方式	含义	优点	缺点
静态转储（冷备份）	转储期间不允许对数据库做任何存取、修改，必须在系统中无运行事务时进行	得到的一定是一致性副本；实现简单	降低了数据库可用性：转储要等正在运行的事务结束，新事务也要等转储结束；只能恢复到转储时刻的状态
动态转储（热备份）	转储期间允许存取和修改，转储与用户事务可并发执行	不用停机等待，不影响新事务；可在表空间/文件级备份	转储结束时副本中的数据不一定正确有效，因此必须同时登记日志文件；后备副本 + 日志文件才能恢复到某一时刻的正确状态；若热备份中途出错，结果基本无效

常见误解：静态转储的优点不是"速度最快"，而是一致性好、实现简单；动态转储也不是"更快"，它的价值在于不停机。

2. 按"转储内容"分

方式	含义	特点
完全备份（海量转储）	备份全部数据	恢复最简单（只需一份），但数据量大、耗时长，通常每周/每月做一次
差量备份	仅备份上一次完全备份之后变化的数据	数据量和耗时介于两者之间；恢复只需"完全备份 + 最近一次差量备份"，恢复速度快于增量
增量备份	备份上一份备份（完全或增量）之后变化的数据	备份最快最省空间；恢复时要依次加载完全备份和每一份增量备份，链条长、出错风险高

样例（一周备份计划）：

• 周日做完全备份（100 GB）；
• 周一～周六做增量备份（每天 5 GB）；周五坏了 → 恢复顺序：周日全备 + 周一 + 周二 + ... + 周五，共 6 份；
• 若周三、周五改为差量备份：周五坏了 → 只需周日全备 + 周五差量（约 30 GB）两份。

3. 转储策略举例

每天晚上做动态增量转储，每周做一次动态海量转储，每月做一次静态海量转储——既兼顾可用性，又保证有干净的"基准点"。

---

四、日志文件：为什么备份必须配日志

1. 日志记什么

日志文件是记录事务对数据库更新操作的文件，常见内容：

• 各事务的开始标记（BEGIN TRANSACTION）
• 各事务的结束标记（COMMIT / ROLLBACK）
• 各事务的所有更新操作（事务标识、操作对象、操作类型、更新前的值和更新后的值、时间戳）

格式主要有两种：以记录为单位、以数据块为单位。

2. 两条铁律（保证"可恢复"的前提）

1. 登记次序严格按并行事务执行的时间顺序；
2. 先写日志文件，后写数据库（WAL）。否则一旦写完数据库还没来得及记日志就宕机，这条修改既无法 REDO 也无法 UNDO，数据库将不可恢复。

3. 日志的作用

作用	说明
事务故障恢复	反向扫描日志，UNDO 故障事务的所有更新
系统故障恢复	建立 REDO/UNDO 队列，分别重做已提交、撤销未完成的事务
配合后备副本做介质故障恢复	动态转储必须配日志；静态转储也可用日志重做已完成事务
（附加）审计	审计日志可用于核查违规操作

4. 为什么"备份有节点、日志才实时"

备份只是某个时间点的快照。假设每天凌晨 2 点备份，上午 10 点磁盘损坏：重装备份只能回到凌晨 2 点，2 点到 10 点之间的 8 小时数据全部丢失。

引入日志后：先装凌晨 2 点的备份，再把 2 点到 10 点的日志重放一遍（REDO 已提交事务），就能把数据库拉到故障前某一时刻的一致状态，把损失从 8 小时压缩到几秒（取决于日志归档频率）。这就是 RPO（恢复点目标）从"一天"降到"接近零"的原理。

生活化类比：

• 备份 = 每月给手机做一次整机备份；
• 日志 = 微信聊天记录实时云同步；
• 手机丢了：只靠整机备份，只能恢复到上个月；有了实时同步，聊天记录一条不少。

---

五、知识地图小结

数据库可靠性
├─ 安全性（防人）
│   ├─ 用户标识和鉴别 ← 最外层防线
│   ├─ 存取控制（DAC / MAC）← 谁能对什么做什么
│   ├─ 视图机制        ← 看不见就不泄露
│   ├─ 审计            ← 事后能追责
│   └─ 数据加密        ← 拿到也看不懂
│
└─ 恢复性（防事故）
    ├─ 原理：冗余
    ├─ 建冗余：数据转储（静态/动态 × 完全/差量/增量）+ 日志文件（先写日志后写库）
    └─ 用冗余：
        ├─ 事务故障 → UNDO（自动）
        ├─ 系统故障 → UNDO 未完成 + REDO 已提交（检查点加速）
        └─ 介质故障 → 装后备副本 + 日志 REDO（DBA 介入）

---

六、易错点速查

错误说法	正确说法
密码存储和传输是单独一类安全措施	归入数据加密（存储加密 + 传输加密），口令应哈希加盐存储
"视图的保护"就是给视图授权	核心是视图机制：用视图隐藏敏感数据，再对视图授权
系统故障用检查点法恢复	检查点只是优化手段，真正恢复靠 UNDO/REDO；且系统故障不破坏外存数据
介质故障直接用日志重做	必须先装入最近一次转储的后备副本，再用日志重做已提交事务
静态转储优点是"非常快"	优点是一致性好、实现简单；代价是降低可用性
动态转储可以单独用来恢复	必须配合日志文件，否则副本可能不一致
增量备份和差量备份是一回事	差量参照上一次完全备份；增量参照上一次任何类型的备份
先写数据库，再写日志	先写日志，后写数据库