CockroachDB-备份与恢复(2)全量备份与增量备份
因为cockachdb设计了高容错性，所以备份主要用于灾难恢复(也就是说，如果您的集群失去了大部分节点)。孤立的问题(如小规模节点中断)不需要任何干预。然而，作为一项操作上的最佳实践，我们建议对数据进行定期备份。
备份主要有两种类型:
- 全量备份
- 增量备份
您可以使用BACKUP语句将集群的模式和数据高效地备份到流行的云服务(如AWS S3、谷歌云存储或NFS)，还可以使用RESTORE语句在必要时高效地恢复模式和数据。有关更多信息，请参见使用云存储进行批量操作。
注：
BACKUP…TO和RESTORE…FROM语法从v22.1起已弃用，将在未来的版本中删除。
我们建议使用BACKUP…INTO {collectionURI}语法，它在您的存储位置创建或添加备份集合。对于恢复备份，我们建议使用RESTORE FROM {backup} IN {collectionURI}，其中{backup}为LATEST或一个特定的子目录。
有关备份和恢复语法的指导，请参阅BACKUP和RESTORE示例。
备份集
备份集定义了一组备份及其元数据。该集合可以包含多个完全备份及其后续的增量备份。备份路径是使用基于日期的命名方案创建的，并存储在与backup语句一起传递的集合URI中。
在某些特定情况下，部分集合数据存储在不同的URI中:
支持位置的备份。备份集合将根据与backup语句一起传递的uri进行存储:backup INTO LATEST IN {collectionURI}， {localityURI}， {localityURI}。这里，collectionURI表示默认的位置。
从v22.1开始，可以将增量备份存储在与相关全量备份不同的URI上。这意味着一个或多个存储位置可以保存一个备份集合。
默认情况下，全量备份存储在集合URI的根目录中基于日期的路径中，增量备份存储在/incrementals目录中。下面的示例显示了使用这些默认值创建的备份集合，其中所有备份都位于一个存储桶中:
Collection URI:
|—— 2022
|—— 02
|—— 09-155340.13/
|—— Full backup files
[...]
|—— incrementals
|—— 2022
|—— 02
|—— 25-172907.21/
|—— 20220325
|—— 17921.23
|—— incremental backup files
SHOW BACKUPS IN {collectionURI}将显示集合URI处的完整备份子目录列表。
全量备份
执行全集群备份时，使用backup语句:
BACKUP INTO '{collectionURI}';
要恢复备份，使用restore语句，指定要恢复的内容以及集合的URI:
恢复表的最新备份
RESTORE TABLE bank.customers FROM LATEST IN '{collectionURI}';
恢复数据库的最新备份
RESTORE DATABASE bank FROM LATEST IN '{collectionURI}';
恢复完整集群的最新备份
RESTORE FROM LATEST IN '{collectionURI}';
从指定的子目录恢复备份
RESTORE DATABASE bank FROM {subdirectory} IN '{collectionURI}';
要查看可用的备份子目录，请使用SHOW BACKUPS。
增量备份
如果您的集群变得太大，不适合进行夜间全量备份，您可以使用夜间增量备份进行不太频繁的全量备份(例如，每周)。对于较大的集群，增量备份比全量备份更节省存储时间和速度。
增量备份比全量备份更小，生成速度也更快，因为它们只包含自您指定的基本备份集(必须包括一个完全备份，并且可以包括多个增量备份)以来更改的数据。您可以根据给定的时间戳或完整的修订历史进行增量备份。
垃圾回收及备份
通过查找自备份链中最后一个备份的时间戳以来已创建、删除或修改的数据，可以创建具有修订历史的增量备份。对于链中的第一个增量备份，此时间戳对应于基本(完全)备份的时间戳。对于后续的增量备份，此时间戳是链中前一次增量备份的时间戳。
垃圾收集生存时间(GC TTL)决定了数据库保留一个键的修订的时间。如果备份目标的GC TTL小于使用修订历史进行增量备份的频率，那么在对修订进行备份之前，修订就容易受到垃圾收集的影响。这将导致具有修订历史记录的增量备份失败。
我们建议将垃圾收集周期配置为至少与增量备份的频率相同，并在理想情况下使用缓冲来考虑减速。可以使用ttlseconds复制区域设置配置垃圾收集周期。
如果在垃圾收集周期之外创建了增量备份，您将收到一个受保护的ts验证错误…要解决此问题，请参阅常见错误页面。
执行增量备份
定期运行BACKUP命令对集群进行完全备份:
BACKUP INTO '{collectionURI}';
然后，在已经创建的完整备份的基础上创建每晚的增量备份。要将增量备份附加到在集合URI处创建的最近的完全备份，请使用LATEST语法:
BACKUP INTO LATEST IN '{collectionURI}';
v22.1新增功能:这将把增量备份添加到备份集合目录根目录的默认/incrementals目录中。使用/incrementals目录中的增量备份，您可以根据需要将云存储提供商提供的不同生命周期/保留策略应用到/incrementals目录。
如果有必要，可以使用RESTORE语句恢复集群、数据库或表。从增量备份恢复需要以前的完全备份和增量备份。
要从备份集的/incrementals子目录中的最新备份进行恢复，请运行:
RESTORE FROM LATEST IN '{collectionURI}';
从集合中的特定备份进行恢复:
RESTORE FROM '{subdirectory}' IN '{collectionURI}';
从增量备份恢复时，将恢复整个表、数据库或集群。在此过程中，cockachdb同时使用最新的(或特定的)增量备份和完全备份。如果没有完全备份，则不能恢复增量备份。此外，不可能使用现有数据对表、数据库或集群进行恢复。
带有显式指定目标的增量备份
v22.1新增功能:要显式控制增量备份的存放位置，请使用incremental_location选项。默认情况下，增量备份存储在集合根目录的/incrementals子目录中。但是，在一些高级情况下，您可能希望将增量备份存储在不同的存储位置。
在以下示例中，{collectionURI}指定包含完全备份的存储位置。{explicit_incrementalsURI}是可以存储增量备份的替代位置:
BACKUP INTO LATEST IN '{collectionURI}' AS OF SYSTEM TIME '-10s' WITH incremental_location = '{explicit_incrementalsURI}';
尽管增量备份将位于不同的存储位置，但它仍然是逻辑备份集合的一部分。
为了对备选方案{explicit_incrementalsURI}进行增量备份，必须在{collectionURI}中提供完全备份。如果在使用incremental_location进行增量备份时，{collectionURI}中没有完整的备份，则会返回不包含已完成的最新备份的错误路径。
要恢复使用incremental_location选项进行的增量备份，必须运行restore，其中包含完整备份的位置，并使用incremental_location选项引用在原始backup语句中传递的位置:
RESTORE TABLE movr.users FROM LATEST IN '{collectionURI}' WITH incremental_location = '{explicit_incrementalsURI}';