<@U0A71G31CDV> let's say I have a shared data clus...
# questions-and-troubleshooting
g
@Rocky let's say I have a shared data cluster in my K8S. I want to perform cluster snapshots every day, and keep the last 30 days of data. I'm using AWS S3 for the storage of the data itself. I'd like to be able to restore the metadata to any day in the last 30 days I'd also like to be able to restore client data in this 30 days timeframe. How can I do that?
r
To achieve a 30-day recovery window for a shared-data cluster (compute-storage separation) on Kubernetes using AWS S3, you cannot use the traditional
BACKUP
and
RESTORE
commands, as they are not supported for shared-data mode. Instead, you must use the Cluster Snapshot feature (introduced in v3.4.2 and enhanced in v3.5). Here is how you can set this up to meet your 30-day requirement: 1. Enable Automated Cluster Snapshots Enable the built-in snapshot feature. By default, this saves the cluster state (metadata) to S3 every 10 minutes.
Copy code
sql
-- Enable automated snapshots to your S3 storage volume
ADMIN SET AUTOMATED CLUSTER SNAPSHOT ON STORAGE VOLUME your_s3_volume;
*Note: By default, StarRocks only keeps the latest snapshot and deletes previous ones to save space.* 2. Preserve 30 Days of Metadata Since StarRocks automatically deletes old snapshots, you need an external mechanism to preserve them: * Option A (Recommended): Use a CronJob in your K8S cluster to copy the snapshot metadata folder from S3 to a "history" prefix every day. The snapshots are located at:
s3://<bucket>/<cluster_id>/meta/image/automated_cluster_snapshot_<timestamp>
* Option B: Enable S3 Versioning on your bucket and use an S3 Lifecycle Policy to retain versions for 30 days. 3. Retain 30 Days of Physical Data In shared-data mode, data files (segments) in S3 are physically deleted by the "AutoVacuum" process once they are no longer referenced by the current metadata. To ensure a 30-day-old snapshot can still find its data, you must increase the retention period for "stale" data versions:
Copy code
sql
-- Set the grace period to 30 days (43200 minutes)
ADMIN SET FRONTEND CONFIG ("lake_autovacuum_grace_period_minutes" = "43200");
Warning: This will significantly increase your S3 storage costs, as all data deleted or changed (via compaction/updates) over the last 30 days will be physically kept in S3. 4. How to Restore To restore the cluster to a specific day: 1. Identify the Snapshot Path: Find the specific metadata snapshot path in S3 for that day (e.g., from your daily copy or S3 versions). 2. Configure Restoration: Create/modify a
cluster_snapshot.yaml
file on your FE node and point it to the snapshot path:
Copy code
yaml
    cluster_snapshot:
        cluster_snapshot_path: <s3://your-bucket/path/to/snapshot/meta/image/automated_cluster_snapshot_TIMESTAMP>
        storage_volume_name: your_s3_volume
3. Start FE in Snapshot Mode: Restart the Leader FE with the
--cluster_snapshot
flag.
Copy code
bash
    ./fe/bin/start_fe.sh --cluster_snapshot --daemon
4. Recover Nodes: Clean the local
meta
directories of other FEs and the
storage_root_path
of CN nodes, then restart them. They will reload the metadata from the snapshot and reference the existing data in S3. Summary of Requirements * StarRocks Version: v3.4.2 or higher (v3.5+ recommended for stability). * Metadata Retention: External script or S3 Versioning to keep 30 days of snapshot folders. * Data Retention: Set
lake_autovacuum_grace_period_minutes
to 43200. Referencesadministration/management/FE_configuration.mdknowledge/admin_and_operation/shared_data_garbage_cleanup.mdfaq/shared_data_faq.mddeployment/shared_data/gcs.mdknowledge/admin_and_operation/shared_data_compaction.md