redis数据持久化和配置-15（备份和还原 Redis 数据）

备份和还原 Redis 数据

备份和恢复数据是管理任何数据库系统（包括 Redis）的关键方面。数据丢失可能是由于硬件故障、软件错误、意外删除甚至恶意攻击而发生的。因此，拥有强大的备份和恢复策略对于确保数据持久性和业务连续性至关重要。本课将介绍备份和恢复 Redis 数据的方法，重点介绍上一课中介绍的 RDB 快照和 AOF 文件。我们将探讨创建备份、验证备份完整性以及从备份中恢复数据所涉及的实际步骤。

了解 Redis 中的备份策略

Redis 提供两种主要的持久性机制：RDB（Redis 数据库）快照和 AOF（仅追加文件）。这些机制还用作备份和还原数据的基础。选择正确的备份策略取决于您对数据持久性和恢复时间的特定要求。

用于备份的 RDB 快照

RDB 快照是 Redis 数据的时间点表示形式。它们是紧凑的二进制文件，可以轻松传输和存储。

RDB 备份的工作原理： 当 Redis 配置为使用 RDB 持久性时，它会定期将数据的快照保存到磁盘。此快照是 Redis 数据库在特定时刻的完整副本。
备份过程： 要使用 RDB 备份 Redis 数据，您只需将 RDB 文件复制到安全位置即可。这可以手动或通过自动化脚本完成。
恢复过程： 要从 RDB 备份还原，请将当前 RDB 文件替换为备份文件，然后重新启动 Redis 服务器。然后，Redis 会将 RDB 文件中的数据加载到内存中。

用于备份的 AOF

AOF 持久性方法记录服务器收到的每个写入作。与 RDB 相比，这提供了一种更持久的持久性形式。

AOF 备份的工作原理： AOF 文件包含修改了 Redis 数据库的所有命令的日志。
备份过程： 与 RDB 类似，备份 AOF 文件涉及将其复制到安全位置。
恢复过程： 要从 AOF 备份还原，请将当前 AOF 文件替换为备份文件，然后重新启动 Redis 服务器。然后，Redis 将重放 AOF 文件中的所有命令以重建数据库。

在 RDB 和 AOF 之间进行备份

在 RDB 和 AOF 之间进行备份的选择取决于您的特定需求：

特征	RDB	AOF
数据持久性	下限（时间点快照）	更高（每个写入作）
备份大小	较小	较大
恢复时间	更快	较慢（需要重放所有命令）
复杂性	简单	更复杂（尤其是重写）

RDB 适用于： 一些数据丢失是可以接受的，并且快速恢复很重要的应用程序。
AOF 适用于： 数据持久性至关重要且您无法承受丢失任何数据的应用程序。

在实践中，许多 Redis 部署结合使用 RDB 和 AOF 来最大程度地保护数据。RDB 提供了一种从最近的快照还原的快速方法，而 AOF 可确保您可以恢复所有数据，直到最后一次写入作。

创建 Redis 备份

让我们探讨一下使用 RDB 和 AOF 创建备份所涉及的实际步骤。

备份 RDB 快照

找到 RDB 文件： RDB 文件的位置在 redis.conf 文件中使用 dir 和 dbfilename 指令指定。默认情况下，RDB 文件名为 dump.rdb，位于 Redis 工作目录中。
启动备份： 您可以通过多种方式触发 RDB 快照：
- 使用 SAVE 命令： 此命令将数据库同步保存到磁盘。它会阻止 Redis 服务器，直到快照完成，因此通常不建议将其用于生产环境。
```
SAVE
```
- 使用 BGSAVE 命令： 此命令在后台异步将数据库保存到磁盘。它不会阻止 Redis 服务器，允许它继续为请求提供服务。
```
BGSAVE
```
- 自动快照： Redis 可以配置为根据指定的保存间隔自动创建快照。这些间隔在 redis.conf 文件中使用 save 指令定义。例如：
```
save 900 1       # Save the DB if after 900 sec (15 min) if at least 1 key changed
save 300 10      # Save the DB if after 300 sec (5 min) if at least 10 keys changed
save 60 10000    # Save the DB if after 60 sec if at least 10000 keys changed
```
复制 RDB 文件： 创建 RDB 快照后，将 dump.rdb 文件复制到安全备份位置。这可以是本地目录、网络共享或云存储服务。
```
cp /var/lib/redis/dump.rdb /mnt/backup/redis/dump_$(date +%Y%m%d_%H%M%S).rdb
```
此命令将 dump.rdb 文件复制到 /mnt/backup/redis 目录，并使用时间戳重命名该文件，以便为每个快照创建唯一的备份文件。

备份 AOF 文件

找到 AOF 文件： AOF 文件的位置在 redis.conf 文件中使用 dir 和 appendfilename 指令指定。默认情况下，AOF 文件名为 appendonly.aof，位于 Redis 工作目录中。
确保 AOF 已启用： 通过将 appendonly 指令设置为 yes，验证是否在 redis.conf 文件中启用了 AOF。
```
appendonly yes
```
复制 AOF 文件： 与 RDB 类似，将 appendonly.aof 文件复制到安全的备份位置。
```
cp /var/lib/redis/appendonly.aof /mnt/backup/redis/appendonly_$(date +%Y%m%d_%H%M%S).aof
```

自动备份

手动创建备份可能很繁琐且容易出错。最好使用脚本或工具自动执行备份过程。

Cron 工作： 您可以使用 cron 作业来安排 Redis 数据的定期备份。创建一个脚本，用于执行 BGSAVE 命令（如果使用 RDB）并将 RDB 或 AOF 文件复制到备份位置。

cron 作业条目示例：
```
0 2 * * * /path/to/redis_backup.sh
```
此 cron 作业在每天凌晨 2：00 运行 redis_backup.sh 脚本。
Redis 企业版： Redis Enterprise 提供内置的备份和还原功能，包括自动备份、时间点恢复以及与云存储服务的集成。

还原 Redis 数据

还原 Redis 数据包括将当前 RDB 或 AOF 文件替换为备份文件，然后重新启动 Redis 服务器。

从 RDB 快照还原

停止 Redis 服务器： 在从 RDB 快照还原之前，请停止 Redis 服务器以防止数据损坏。
```
redis-cli shutdown
```
替换 RDB 文件： 将备份 RDB 文件复制到 Redis 工作目录，替换现有的 dump.rdb 文件。
```
cp /mnt/backup/redis/dump_20231027_100000.rdb /var/lib/redis/dump.rdb
```
调整文件所有权： 确保 Redis 用户对还原的 RDB 文件具有正确的所有权和权限。
```
chown redis:redis /var/lib/redis/dump.rdb
```
启动 Redis 服务器： 启动 Redis 服务器。它将自动从还原的 RDB 文件中加载数据。
```
redis-server /etc/redis/redis.conf
```

从 AOF 文件恢复

停止 Redis 服务器： 与 RDB 一样，在从 AOF 文件还原之前停止 Redis 服务器。
```
redis-cli shutdown
```
替换 AOF 文件： 将备份 AOF 文件复制到 Redis 工作目录，替换现有的 appendonly.aof 文件。
```
cp /mnt/backup/redis/appendonly_20231027_100000.aof /var/lib/redis/appendonly.aof
```
调整文件所有权： 确保 Redis 用户对还原的 AOF 文件具有正确的所有权和权限。
```
chown redis:redis /var/lib/redis/appendonly.aof
```
配置 AOF： 确保在 redis.conf 文件中设置了 appendonly yes。
启动 Redis 服务器： 启动 Redis 服务器。它将重放还原的 AOF 文件中的所有命令以重建数据库。
```
redis-server /etc/redis/redis.conf
```

处理 AOF 损坏

在某些情况下，AOF 文件可能会因服务器意外关闭或其他问题而损坏。Redis 提供了一个名为 redis-check-aof 的工具来修复损坏的 AOF 文件。

运行 redis-check-aof： 使用 redis-check-aof 工具分析和修复 AOF 文件。
```
redis-check-aof --fix /var/lib/redis/appendonly.aof
```
此命令尝试修复 AOF 文件中的任何不一致或错误。
重新启动 Redis 服务器： 修复 AOF 文件后，重启 Redis 服务器加载数据。

优先考虑 AOF 而不是 RDB

如果 RDB 和 AOF 文件都存在，Redis 将默认优先从 AOF 文件加载数据，因为它代表数据库的最新状态。如果要强制 Redis 从 RDB 文件加载，则可以在启动服务器之前临时重命名或删除 AOF 文件。

验证备份完整性

验证备份的完整性以确保它们有效并可用于成功还原数据，这一点至关重要。

RDB 完整性检查

虽然没有直接工具来“检查”RDB 完整性，但您可以通过以下方式间接验证它：

还原到暂存环境： 将 RDB 文件还原到单独的暂存环境，并验证数据是否一致且完整。
比较键数： 在备份之前和之后，使用 DBSIZE 命令记录数据库中的键数。还原后，将密钥计数与记录的值进行比较。重大差异可能表示数据损坏。

AOF 完整性检查

如前所述，redis-check-aof 工具可用于验证和修复 AOF 文件。

在 Check 模式下运行 redis-check-aof： 使用不带 --fix 选项的 redis-check-aof 工具分析 AOF 文件是否有错误，而无需修改它。
```
redis-check-aof /var/lib/redis/appendonly.aof
```
此命令将报告在 AOF 文件中发现的任何不一致或错误。

一般备份验证做法

定期测试： 计划定期测试从备份中恢复，以确保该过程正常工作并且恢复的数据有效。
监测： 监视备份过程是否存在错误或故障。设置警报以通知您任何问题。
冗余： 将备份存储在多个位置，以防止因硬件故障或其他灾难而丢失数据。

实际应用

考虑一个使用 Redis 存储会话数据、购物车信息和产品目录的电子商务平台。该平台的流量很高，并依赖 Redis 进行快速数据访问。

备份策略： 该平台使用 RDB 和 AOF 实施混合备份策略。RDB 快照每天凌晨 2：00 拍摄，以便在发生重大故障时提供快速恢复点。AOF 每 sec（ 每秒）启用 appendfsync，以确保在服务器崩溃时将数据丢失降至最低。
备份自动化： cron 作业配置为自动触发 BGSAVE 命令并将 RDB 和 AOF 文件复制到云存储服务。备份文件使用时间戳命名，以维护备份的历史记录。
恢复过程： 如果发生数据丢失事件，平台的运营团队会遵循记录在案的还原程序。他们首先尝试从最新的 AOF 文件还原。如果 AOF 文件已损坏或不可用，它们将从最新的 RDB 快照中恢复。
验证： 每次还原后，运营团队都会通过比较密钥计数并手动检查关键数据元素（如用户会话和购物车）来验证还原数据的完整性。