@Rocky In a shared nothing arch, what are the snapshot / backup options?

In StarRocks' shared-nothing architecture (where data is stored on local disks of BE nodes), backup and snapshot operations are handled through a repository-based framework. This allows you to create snapshots of your data and store them in remote storage systems for disaster recovery or migration. Here are the primary options and workflow for snapshots and backups in a shared-nothing setup: 1. Remote Storage Repositories StarRocks does not store backups on local disks; instead, it uses a Repository to interface with remote storage. Supported storage systems include: * HDFS * Object Storage: AWS S3, Google GCS, Azure Blob Storage, and MinIO. To start, you must create a repository using the

CREATE REPOSITORY

command, specifying the location and credentials (via Broker or direct S3/HDFS access). 2. Backup and Restore Mechanism The core mechanism for shared-nothing clusters is the

BACKUP

and

RESTORE

commands. * BACKUP SNAPSHOT: This command takes a snapshot of the specified objects and uploads them to the remote repository. It is an asynchronous operation. * RESTORE SNAPSHOT: This allows you to restore data to the same cluster or a different StarRocks cluster. 3. Supported Objects (v3.x+) You can back up a variety of objects, including: * Data: Internal databases, tables (all types: Duplicate, Primary Key, etc.), and specific partitions. * Metadata: As of v3.4, you can also back up metadata for external catalogs, Materialized Views (Sync/Async), Logical Views, and User-Defined Functions (UDFs). 4. Backup Granularity * Full Database: Backing up all tables within a database. * Table-level: Backing up specific critical tables. * Partition-level (Recommended for Large Tables): This is the best way to implement incremental backups. By backing up only the most recent partitions on a schedule, you reduce backup time and storage costs. 5. Key Commands for Management * Monitor Progress: Use

SHOW BACKUP

or

SHOW RESTORE

to check the status of ongoing tasks. * Cancel Tasks: If a backup is taking too long or was started in error, use

CANCEL BACKUP

. * View Snapshots: Use

SHOW SNAPSHOT ON repository_name

to see what backups are available in your remote storage. Important Comparison: Shared-Nothing vs. Shared-Data * Shared-Nothing (Your Case): Backups are manually initiated (or via a cron job/scheduler) using the

BACKUP SNAPSHOT

syntax. The "snapshot" is essentially a point-in-time copy exported to remote storage. * Shared-Data: These clusters support Automated Cluster Snapshots, which automatically back up metadata and data to object storage every few minutes (controlled by

automated_cluster_snapshot_interval_seconds

). This automated feature is specific to the shared-data architecture. Rocky's Tip: For large production clusters, always prefer partition-level backups to avoid the heavy resource overhead of full table snapshots every time! References • administration/cluster_snapshot.md • data_source/catalog/iceberg/iceberg_timetravel.md • deployment/shared_data/s3.md