使用备份恢复的常见场景如下：

• 数据保护：系统崩溃、磁盘损坏、应用错误、人为误操作等因素可能导致数据丢失，对数据库进行定期备份，并在需要时恢复，可以规避数据丢失对业务造成的影响。
• 数据迁移：因某种需求，数据库中的数据需要迁移至其他主库，此时可以借助备份恢复功能实现数据的迁移。

作为业务系统的数据底座，数据库必须要保证其数据的安全性，而对于数据库管理员，制定一份合适的备份策略则至关重要。

传统的备份方法分为冷备（离线备份，数据库停止服务）和热备（在线备份，数据库正常运行），本章将着重介绍YashanDB的热备能力，数据库管理员在使用时可以参考这些文档，并根据自身情况作适当调整，确保企业的数据安全。

YashanDB支持的备份恢复能力主要包括如下内容：

• 全量备份：对某一时间点上的所有目标数据（存算一体分布式集群部署中对所有主节点）进行完全复制，不依赖之前的备份集。一个全量备份集可以恢复出所有数据，恢复时间最短且操作最方便。
• 增量备份：首次执行基线备份（Level 0），后续每次只需备份增量数据（Level 1），备份效率高，节省磁盘空间。恢复时需要从基线备份集开始依次恢复所有增量备份。
• 归档备份：对当前正常运行的数据库产生的归档日志文件进行完全复制，可以灵活指定备份的归档文件范围（包括SEQUENCE、SCN、TIME），生成属于该范围归档文件的独立备份集。
• 单机部署中，还可以只按需备份/恢复表空间（例如，只备份关键数据所在表空间），精简操作与存储成本。
• 全量恢复：从备份集执行恢复后，若在该备份集后生成的归档日志和在线日志连续且完整，YashanDB将应用所有日志，恢复数据库至连续日志序号的最新时间点；若该备份集后生成的归档日志无保留，则只能恢复备份集时间点数据。对于存算一体分布式集群部署，全量恢复指所有的节点都能恢复到备份时间点，并且在恢复后open所有节点。
• 归档恢复：指定已存在的归档日志备份集并指定要恢复的归档范围（包括SEQUENCE、SCN、TIME）即可恢复至数据库。
• 指定时间点恢复：从备份集执行恢复后，若在该备份集后生成的归档日志和在线日志连续且完整，指定让YashanDB继续恢复数据库至任意时间点。
• 通过并行度设置提高备份和恢复的效率。
• 备份压缩：当需要备份的数据量较大、磁盘空间紧张或存在其他数据压缩需求时，可以执行压缩备份，提高磁盘利用率。
• 备份加密：若对数据备份内容有较高安全性要求，在备份时可指定不同的加密算法对备份数据集加密，保证备份数据集的安全性。

单机部署或共享集群部署时，可以使用SQL语句或yasrman工具两种方式进行备份恢复；存算一体分布式集群部署时只能采用yasrman工具进行备份恢复。

Note:

如果数据库中存在本地临时表空间或本地SWAP表空间，备份恢复后不会直接创建本地临时表空间或本地SWAP表空间的文件，待数据库触发到open状态时才会创建相应文件。

通过备份集将数据库从异常状态恢复至正常的常见场景包括：

• 场景1：数据库无法启动

  可能发生原因：

  • 控制文件损坏或丢失

  • 系统关键数据文件损坏或丢失

  • 在线日志文件损坏或丢失

  恢复方式：建议采取全量完整恢复。

• 场景2：表误操作

  可能发生原因：

  • delete或update误操作导致表数据被删除或修改

  • truncate导致表数据被清空

  • drop导致表被删除

  恢复方式：

  • 若能及时发现误操作导致数据丢失，建议采取闪回的方式恢复表数据（参考UNDO_RETENTION/UNDO_FORCE_RETENTION具体含义）。

    • delete或update误操作，若undo被覆盖则可能闪回不成功。

      FLASHBACK TABLE {table_name} TO SCN {SCN};
      FLASHBACK TABLE {table_name} TO TIMESTAMP {TIMESTAMP};
      

    • truncate误操作，需确保回收站开启，若回收站被覆盖则可能闪回不成功。

      FLASHBACK TABLE TO BEFORE TRUNCATE;
      

    • drop误操作，需确保回收站开启，若回收站被覆盖则可能闪回不成功。

      FLASHBACK TABLE TO BEFORE DROP
      

  • 若无法使用闪回的方式恢复，建议采取指定时间点恢复，恢复到表误操作之前的时间点。

• 场景3：主备模式下，主库崩溃时备库自动提升为主库，搭建新备库

  可能发生原因：

  • 主库操作系统崩溃
  • 数据库关键文件被误删除
  • 网络原因导致无法连接至主库

  恢复方式：若数据量大，建议采用完整恢复的方式重建备库；否则可以采用build database方式重建备库。

• 场景4：数据迁移

  可能发生原因：

  • 主库系统崩溃，需要进行异机恢复
  • 数据库克隆

  恢复方式：完整恢复和指定时间点恢复都能完成数据库恢复，根据实际需求选择恢复方式即可。