第一代与第二代备份的比较
第2代
第一代实例的备份与第二代实例的备份（快照）在范围和机制上均有所不同。 传统备份（第 1 代）在文件级别进行，会捕获数据库文件和预写日志（WAL）。 该方法依赖于与数据库引擎的深度集成，以确保事务一致性和数据完整性。 相比之下，第 2 代采用基础设施级快照，利用了 IBM VPC 的块存储和文件共享功能。 这些快照可生成近乎即时的卷级副本，不仅速度快、可扩展性强，而且即使面对大型数据集，对性能的影响也微乎其微。 与第 1 代备份类似，每个实例都有计划备份，这些备份会在每日的备份时段内自动运行。 您可以查看实例的备份列表，触发按需备份，并可将备份恢复到新实例中。
Gen 2 提供两种类型的备份：关联备份（适用于大多数服务）和独立备份。 独立备份是独立的服务实例，在数据库删除后仍会保留；而关联备份则与数据库实例的生命周期紧密相关。
目前，独立备份功能仅适用于 Databases for MySQL。 所有其他第二代服务均采用耦合备份。
无法使用第 2 代实例来恢复第 1 代实例，因为卷快照恢复过程需要完整的块级映像，而不是单个数据库文件。
第一代与第二代的主要功能差异
| 差异化因素 | 第 1 代 | 第 2 代 |
|---|---|---|
| 机制 | 文件级备份：此类备份属于文件级备份，通过复制单个数据库文件和 WAL 段来实现，系统会为备份中的每个文件计算校验和，并在还原或验证操作期间重新检查这些校验和。 该备份机制在产品应用程序层级运行，需要与数据库引擎深度集成，以确保事务一致性和数据完整性。 | 基础设施级备份：备份利用基础设施级卷快照，在块级别捕获整个存储状态，即使对于多太字节级的数据库，也能将备份窗口从数小时大幅缩短至数分钟。 无论数据库大小如何，这种方法都能实现近乎即时的备份创建。 |
| 性能 | 会消耗 CPU 和内存资源，从而影响数据库进程的性能。 | 备份操作独立于数据库进程运行，因此不会影响数据库对 CPU 和内存的占用。 |
| 访问还原操作 | 恢复操作的访问延迟。 在数据库启动之前，备份需要进行完整的文件恢复。 在恢复期间无法访问。 | 在恢复操作开始后，可立即访问数据，但I/O性能会降低，直至数据加载完成。 从快照恢复卷。 |
| 恢复时间目标 (RTO) | RTO 较慢。 随着数据量的增长，恢复对数据的访问所需的时间几乎呈线性增长，对于大型数据库而言，这可能需要数小时。 | 快速的RTO：恢复数据访问仅需几分钟，且与数据量无关。 不过，在恢复过程中，I/O 性能可能会暂时下降，其影响程度取决于数据大小。 |
| 恢复点目标 (RPO) | 按固定间隔安排，可能会造成数据丢失的风险。 | 可以频繁使用，对性能的影响微乎其微。 |
| 特定时间点恢复（PITR） | 是 | 未来将发布。 |
独立备份功能
Gen 2 为 Databases for MySQL 引入了独立备份功能。 这些备份提供的功能超越了传统的耦合备份：
| 功能 | 第 1 代 | 第2代（耦合型） | 第2代（独立版） |
|---|---|---|---|
| 生命周期 | 与实例关联 | 与实例关联 | 与实例无关 |
| 账户级视图 | 不支持 | 不支持 | 具有集中视图的数据库枢纽 |
| 备份删除 | 仅限自动挡 | 仅限自动挡 | 手动和自动 |
| 备份局部性 | 固定 | 地区锁定 | 受地区限制，未来版本将支持备份副本 |
| 持久性 | 随实例一起删除 | 随实例一起删除 | 在实例删除后仍可保留 |
| 管理 | 数据库 API | 仅限用户界面 | 数据库中心、资源列表、实例用户界面 |
目前，独立备份功能仅适用于 Databases for MySQL。 所有其他第二代服务均采用耦合备份。
有关独立备份的更多信息，请参阅 “管理独立备份”。
管理第二代备份
如需了解如何管理您的第二代备份：