适用场景
StarRocks 离线迁移数据场景，通过备份以及恢复 StarRocks 中的数据，或将数据迁移至新的 StarRocks 集群。
Backup 是 StarRocks 目前提供的一种可将数据与元数据统一导出的方式。Backup 操作也需要 Broker 组件，通过 Broker 将数据备份到远端存储系统中，例如HDFS、OSS、COS 或 S3等。
基于 Backup 的特性，这种方式通常用于对数据进行定期的快照备份，或者用于在不同集群间进行数据迁移。
与 Backup 对应的命令是 Restore，用于将 Backup备份后的数据进行还原。因为 Backup 备份后的文件中已经包含了元数据，所以在进行 Restore 还原操作时，我们无需手动建表。
目前，备份（Backup）操作或还原（Restore）可操作的最小单位是分区，最大单位是表，还不直接支持整库的备份或还原。目前仅支持全量备份，暂不支持增量备份。所以如果需要对数据进行定期备份，我们需要在建表时合理规划表的分区，例如按时间分区，然后在后续业务中，按照分区粒度进行备份或还原。
1. 创建 COS 仓库
创建一个 COS 远端仓库路径，用于备份或恢复，该命令需要借助 Broker 进程访问远端存储，仅 root 或 superuser 用户可以创建仓库。
注意，2个集群上创建相同的远端仓库 oss_repo，若仓库名称不同，即便 COS 信息和路径都一致，也无法进行还原：
#查看集群当前的仓库SHOW REPOSITORIES;————————————————------#创建cos仓库CREATE REPOSITORY `仓库名称`WITH BROKER `broker名称`ON LOCATION "cosn://xxx-xxxxx/路径"PROPERTIES("fs.cosn.userinfo.secretId" = "xxxxxxxxxxxxx","fs.cosn.userinfo.secretKey" = "xxxxxxxxxxxxx","fs.cosn.bucket.endpoint_suffix" = "cos.ap-xxx.myqcloud.com");其中 fs.cosn.userinfo.secretId、fs.cosn.userinfo.secretKey 可以在 https://console.cloud.tencent.com/cam/capi 获取；fs.cosn.bucket.endpoint_suffix 需要按照地域进行修改。————————————————------#删除cos仓库DROP REPOSITORY `repo_name`;
示例：
创建 COS 仓库：
CREATE REPOSITORY `cos_repo`WITH BROKER `Broker_StarRocks`ON LOCATION "cosn://xxx-xxx/starrocks"PROPERTIES("fs.cosn.userinfo.secretId" = "xxxxxxxxxxxx","fs.cosn.userinfo.secretKey" = "xxxxxxxxxxxx","fs.cosn.bucket.endpoint_suffix" = "cos.ap-guangzhou.myqcloud.com");
查看集群当前的仓库：
MySQL [restore]> SHOW REPOSITORIES;+--------+----------+---------------------+------------+------------------------------------+------------------+--------+| RepoId | RepoName | CreateTime | IsReadOnly | Location | Broker | ErrMsg |+--------+----------+---------------------+------------+------------------------------------+------------------+--------+| 11001 | cos_repo | 2022-10-12 15:29:50 | false | cosn://xxx-12532xxxxx/starrocks | Broker_StarRocks | NULL |+--------+----------+---------------------+------------+------------------------------------+------------------+--------+1 row in set (0.00 sec)
2. 备份数据
备份（Backup）操作实际是将指定表或分区的数据，直接以 StarRocks 存储的文件的形式上传到远端仓库中进行存储。
同一数据库下只能有一个正在执行的 BACKUP 或 RESTORE 任务。
#备份命令BACKUP SNAPSHOT [db_name].{snapshot_name}TO `repository_name`ON (`table_name` [PARTITION (`p1`, ...)],...)PROPERTIES ("key"="value", ...);说明：1、ON子句中标识需要备份的表和分区。如果不指定分区，则默认备份该表的所有分区。目前不直接支持整库的备份，如果需要整库备份，需要将库内所有的表都写在这里。2、Backup的PROPERTIES目前只支持以下两个属性："type" = "full"：表示这是一次全量更新（默认），目前也只支持全量，可以省略；"timeout" = "3600"：任务超时时间，默认为一天，单位秒，默认时可省略。3、执行备份命令后，集群首先会对涉及到的tablet进行一次快照，快照耗时很少，快照名称为我们Backup语句中指定的snapshot_name。之后的备份操作实际都是对这个快照进行操作。也即在快照之后，对表进行的导入、修改等操作都不再影响备份的结果。————————————————------#查看备份任务命令SHOW BACKUP FROM db_name\\G ;其中 State 为任务状态，需要着重关注，根据任务的进度可能会有以下8种可能的状态：PENDING：作业初始状态，等待被调度。SNAPSHOTING：正在进行快照操作。UPLOAD_SNAPSHOT：快照结束，准备上传。UPLOADING：正在上传快照，当数据量大时，这一步通常耗时较长。SAVE_META：正在本地生成元数据文件。UPLOAD_INFO：上传元数据文件和本次备份作业的信息。FINISHED：备份完成，任务正常完成的最终状态。CANCELLED：备份失败或被取消，任务超时或出现错误且多次重试失败后的最终状态。————————————————------#查看快照状态SHOW SNAPSHOT ON cos仓库名称 ;其中当Status为OK时表示备份正常，若不为OK，可能表示备份还未完成或出现了其他异常情况。
示例：
将 ssb 库中的全部表 customer、dates、lineorder、lineorder_flat、part、supplier 备份到 COS 仓库中：
BACKUP SNAPSHOT ssb.snapshot_test1TO `cos_repo`ON(customer,dates,lineorder,lineorder_flat ,part,supplier)PROPERTIES ("type" = "full","timeout" = "3600");
查看 ssb 库的备份任务：
MySQL [ssb]> SHOW BACKUP FROM ssb \\G ;*************************** 1. row ***************************JobId: 11925SnapshotName: snapshot_test1DbName: ssbState: UPLOADINGBackupObjs: [default_cluster:ssb.customer], [default_cluster:ssb.dates], [default_cluster:ssb.lineorder], [default_cluster:ssb.lineorder_flat], [default_cluster:ssb.part], [default_cluster:ssb.supplier]CreateTime: 2022-10-12 17:57:21SnapshotFinishedTime: 2022-10-12 17:57:25UploadFinishedTime: NULLFinishedTime: NULLUnfinishedTasks: 11928=10002, 11931=10003, 11934=10004Progress: [11928: 20/48], [11931: 41/48], [11934: 14/47]TaskErrMsg:Status: [OK]Timeout: 36001 row in set (0.01 sec)ERROR: No query specified
查看快照状态：
MySQL [ssb]> SHOW SNAPSHOT ON cos_repo ;+----------------+-------------------------+--------+| Snapshot | Timestamp | Status |+----------------+-------------------------+--------+| snapshot_test1 | 2022-10-12-17-57-21-700 | OK |+----------------+-------------------------+--------+1 row in set (0.20 sec)
3. 还原数据
恢复（Restore）操作需要我们指定一个 COS 仓库中已存在的备份，然后将这个备份的内容恢复到本地集群中。
同一数据库下只能有一个正在执行的 BACKUP 或 RESTORE 任务。
注意，只有当快照状态为 OK 的快照才能恢复。可以使用 SHOW SNAPSHOT ON COS仓库名称命令来确认。
#查看快照状态SHOW SNAPSHOT ON cos仓库名称 ;————————————————------#从COS仓库恢复RESTORE SNAPSHOT [db_name].{snapshot_name}FROM `repository_name`ON (`table_name` [PARTITION (`p1`, ...)] [AS `tbl_alias`],...)PROPERTIES ("key"="value", ...);说明：1、ON子句中指定需要恢复的表和分区。还原时同样不支持直接进行库级别的还原，若要整库还原，需要列出库内所有的表。如果不指定分区，则默认恢复该表的所有分区。所指定的表和分区必须已存在于仓库备份中。2、可以通过AS语句将仓库中备份的表名恢复为新的表，但新表名不能已存在于数据库中。表的其他信息均不能修改。3、可以将仓库中备份的表恢复替换数据库中已有的同名表，但需保证两张表的表结构完全一致。表结构包括：表名、列、分区、Rollup及物化视图等等。同时，特别注意，从恢复作业的COMMIT阶段开始，如果恢复作业失败或被取消，有可能造成之前的数据已损坏且无法访问，因此，如无必要，强烈不建议使用覆盖替换同名表的方式恢复数据，除非确认当前表中的数据已不再使用。4、可以指定恢复表的部分分区，系统会检查分区Range是否能够匹配。在任务中以分区为增量单位来备份并还原数据，这种方式是推荐的。这种情况与上面的不同，不是覆盖，而是为目标表增量添加分区。5、Restore的PROPERTIES目前支持以下属性："backup_timestamp" = "2022-10-12-17-57-21-700"：指定了恢复对应备份的哪个时间版本，必填。该信息可以通过SHOW SNAPSHOT ON cos仓库名称;语句获得。"replication_num" = "3"：指定恢复的表或分区的副本数。默认为3。若恢复已存在的表或分区，则副本数必须和已存在表或分区的副本数相同。同时，考虑到StarRocks的副本策略，必须有足够Host的BE节点来容纳多个副本。————————————————------#查看恢复任务情况SHOW RESTORE from db_name \\G ;其中 State 为恢复作业当前所在阶段，根据任务进度可能会有八种状态：PENDING：作业初始状态，等待调度。SNAPSHOTING：正在进行本地新建表的快照操作。DOWNLOAD：正在发送下载快照任务。DOWNLOADING：快照正在下载。COMMIT：准备生效已下载的快照。COMMITTING：正在生效已下载的快照。FINISHED：恢复完成，作业成功。CANCELLED：恢复失败或被取消，通常为任务超时或任务失败。————————————————------#取消恢复命令CANCEL RESTORE FROM db_name;
示例：
将快照 snapshot_test1 中的还原到 Restore 库中，将 lineorder_flat、part 表分别重命名为 restore_lineorder_flat、restore_part：
RESTORE SNAPSHOT restore.`snapshot_test1`FROM `cos_repo`ON (customer,dates,lineorder,lineorder_flat AS restore_lineorder_flat,part AS restore_part ,supplier)PROPERTIES("backup_timestamp"="2022-10-12-17-57-21-700","timeout" = "3600");
查看 Restore 库的恢复情况：
MySQL [restore]> SHOW RESTORE from restore \\G ;*************************** 1. row ***************************JobId: 11936Label: snapshot_test1Timestamp: 2022-10-12-17-57-21-700DbName: default_cluster:restoreState: DOWNLOADINGAllowLoad: falseReplicationNum: 3RestoreObjs: lineorder_flat, part, supplier, lineorder, dates, customerCreateTime: 2022-10-12 18:38:46MetaPreparedTime: 2022-10-12 18:38:49SnapshotFinishedTime: 2022-10-12 18:38:52DownloadFinishedTime: NULLFinishedTime: NULLUnfinishedTasks: 14904=10002, 14907=10003, 14910=10004Progress: [14904: 85/141], [14907: 85/141], [14910: 85/141]TaskErrMsg:Status: [OK]Timeout: 36001 row in set (0.00 sec)ERROR: No query specified
数据校验
Backup、Restore 过程会保证数据严格一致性，数据校验通常可通过对比表行数（COUNT）完成。
常见问题
1. 源端 StarRocks 备份到 COS 报 Status Code:403错误码,用户没有 COS 访问权限。需要在 COS 控制台对应桶配置用户权限。
2. 单一数据库内，仅可同时执行一个备份或恢复作业。否则 StarRocks 返回错误。
3. 因为备份与恢复操作会占用一定系统资源，建议您在集群业务低峰期进行该操作。
4. 目前 StarRocks 不支持在备份数据时使用压缩算法。
5. 因为数据备份是通过快照的形式完成的，所以在当前数据快照生成之后导入的数据不会被备份。因此，在快照生成至恢复（迁移）作业完成这段期间导入的数据，需要重新导入至集群。建议您在迁移完成后，对新旧两个集群并行导入一段时间，完成数据和业务正确性校验后，再将业务迁移到新的集群。
6. 在恢复作业完成前，被恢复表无法被操作。
7. Primary Key 表无法被恢复至 v2.5 之前版本的 StarRocks 集群中。
8. 您无需在恢复作业前在新集群中创建需要被恢复表。恢复作业将自动创建该表。
9. 如果被恢复表与已有表重名，StarRocks 会首先识别已有表的 Schema。如果 Schema 相同，StarRocks 会覆盖写入已有表。如果 Schema 不同，恢复作业失败。您可以通过
AS 关键字重新命名被恢复表，或者删除已有表后重新发起恢复作业。10. 如果恢复作业是一次覆盖操作（指定恢复数据到已经存在的表或分区中），那么从恢复作业的 COMMIT 阶段开始，当前集群上被覆盖的数据有可能不能再被还原。此时如果恢复作业失败或被取消，有可能造成之前的数据损坏且无法访问。这种情况下，只能通过再次执行恢复操作，并等待作业完成。因此，我们建议您，如无必要，不要使用覆盖的方式恢复数据，除非确认当前数据已不再使用。覆盖操作会检查快照和已存在的表或分区的元数据是否相同，包括 Schema 和 Rollup 等信息，如果不同则无法执行恢复操作。
11. 目前 StarRocks 暂不支持备份恢复逻辑视图。
12. 目前 StarRocks 暂不支持备份恢复用户、权限以及资源组配置相关数据。
13. StarRocks 不支持备份恢复表之间的 Colocate Join 关系。
