@Rocky I need to setup backup for shared data cluster 4.0.14. I plan to run snapshot on StarRocls every 4-6 hours, what parameters I should change to make sure I can restore after 4-6 hours if metadata got corrupted?

For setting up a backup and disaster recovery strategy for a StarRocks 4.0.14 shared-data cluster with a 4-6 hour recovery window, the most critical configuration is ensuring the underlying data files in object storage are not garbage-collected before you can restore the metadata. 1. Crucial Parameter: Data Retention In shared-data mode, the "backup" (Cluster Snapshot) only stores the metadata (FE state). The actual data stays in object storage (S3/OSS/etc.). StarRocks automatically runs AutoVacuum to clean up old data versions after compactions. To ensure you can restore a snapshot from 4-6 hours ago, you must increase the retention period so the data files referenced by that snapshot aren't deleted: *

lake_autovacuum_grace_period_minutes

(FE Configuration) * Default:

30

(minutes) * Recommended Change: Set this to at least

360

(6 hours) or higher (e.g.,

480

for 8 hours) to provide a safety buffer. * Reason: If a snapshot is taken at 12:00 PM and AutoVacuum deletes old data files at 12:30 PM, your 12:00 PM snapshot will point to non-existent files and become un-restorable. 2. Snapshot Frequency StarRocks 4.0 uses the Cluster Snapshot feature for full metadata recovery. By default, it runs every 10 minutes and keeps only the latest one. *

automated_cluster_snapshot_interval_seconds

(FE Configuration) * Default:

600

(10 seconds) * Recommended Change: Set to

14400

(4 hours) or

21600

(6 hours) if you strictly want to match your 4-6 hour plan. * Note: The system currently only retains one automated snapshot at a time. If you need historical "point-in-time" recovery for multiple versions, you should look into cloud-provider side snapshots (S3 versioning/backup) or manually copying the snapshot metadata images. 3. How to Enable Ensure Automated Cluster Snapshot is active:

sql
-- Enable automated snapshots and specify where to store them
ADMIN SET AUTOMATED CLUSTER SNAPSHOT ON STORAGE VOLUME <your_storage_volume>;

-- Check snapshot status
SELECT * FROM information_schema.cluster_snapshots;

4. Summary of Parameters to Change Parameter | Location | Suggested Value | Description

lake_autovacuum_grace_period_minutes

|

fe.conf

| `360`+ | Keeps data files alive in S3 for at least 6 hours.

automated_cluster_snapshot_interval_seconds

|

fe.conf

|

14400

| Triggers a metadata snapshot every 4 hours.

catalog_trash_expire_second

|

fe.conf

| `86400`+ | (Default 1 day) Keep dropped tables in recycle bin. Important Note on Restoration To restore from these snapshots in case of metadata corruption, you must restart the FE nodes using the

--cluster_snapshot

flag. Refer to the Cluster Snapshot documentation for the detailed recovery workflow. References • administration/cluster_snapshot.md • sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md • administration/management/Backup_and_restore.md

@Rocky what is the downside to keep

lake_autovacuum_grace_period_minutes

as 1 day?

Setting

lake_autovacuum_grace_period_minutes

to 1 day (1440 minutes) is a very safe strategy for ensuring your 4-6 hour snapshots are restorable. However, there are a few trade-offs to consider: 1. Increased Object Storage Costs This is the most significant downside. In a shared-data cluster, StarRocks performs "Compaction" frequently to merge small files. * With a 30-minute grace period: Old versions of data files are deleted almost immediately after they are merged. * With a 1-day grace period: Every "old" version of every file remains in your S3/OSS/GCS bucket for a full 24 hours before being deleted. * Impact: If you have a high ingestion rate (e.g., constant streaming via Routine Load), your storage usage can spike significantly (often 2x to 5x your actual data size) because you are effectively storing many historical "layers" of the same data simultaneously. 2. Slower Storage Reclaim If you delete a large table or partition, the physical files will not be removed from your cloud storage for 24 hours. If you are operating near a storage quota or trying to keep costs strictly minimized, this delay in reclaiming space can be an issue. 3. Metadata Management Overhead (Minor) The StarRocks FE needs to track which files are pending deletion. While usually negligible, if your cluster has a massive number of tables and extremely frequent compactions, keeping a 24-hour backlog of file references increases the size of the metadata the FE has to manage until the vacuum process finally clears them. 4. No Impact on Query Performance Queries always use the latest metadata to find the "current" files. Keeping old files around for 24 hours does not slow down your SQL queries, as the system simply ignores those stale files during normal operations. Recommendation If your storage cost is not a primary concern, 1 day is a great setting because it gives you a massive safety window for disaster recovery. If you want to optimize for cost while still meeting your 4-6 hour requirement: * Set it to 8-12 hours (

480

or

720

minutes). This provides a comfortable buffer for your 4-6 hour snapshots without the extreme storage bloat of a full 24-hour retention. Note: Always ensure your

catalog_trash_expire_second

(default 1 day) is also aligned, so that if you accidentally DROP a table, it stays in the "recycle bin" long enough for you to recover it. References • administration/management/FE_configuration.md • faq/shared_data_faq.md • best_practices/primarykey_table.md • administration/management/compaction.md