@Rocky Does StarRocks support PITR on shared nothing?

StarRocks does not support Point-in-Time Recovery (PITR) for internal tables in the shared-nothing architecture. In StarRocks, recovery capabilities for shared-nothing clusters are limited to the following: *

RECOVER

Command: Allows you to restore accidentally dropped databases, tables, or partitions within a configurable retention window (default 1 day), based on the

catalog_trash_expire_second

setting. * Snapshot Backup/Restore: You can manually or periodically back up data to external storage (S3, HDFS, etc.) using

BACKUP

and restore it using

RESTORE

. However, this is snapshot-based and does not allow rolling back to an arbitrary point in time between snapshots. * Replica Repair: StarRocks automatically handles data recovery from failed nodes by cloning healthy replicas from other Backend (BE) nodes. PITR and Time Travel in Other Contexts While shared-nothing doesn't have PITR, StarRocks has introduced similar features for other architectures and catalogs: * Shared-data (Cloud-native): Supports a "second-level recovery mechanism" using

ADMIN REPAIR TABLE

. This allows you to roll back tablet metadata to a previous healthy version if data is lost or corrupted in object storage. * Iceberg Catalog: Starting with v3.4, StarRocks supports Time Travel for Iceberg tables using

FOR VERSION AS OF

or

FOR TIMESTAMP AS OF

, allowing you to query historical data versions. For mission-critical data in shared-nothing clusters, the recommended practice is to use the

BACKUP

and

RESTORE

features regularly to a remote repository. References • introduction/Architecture.md • deployment/shared_data/feature-support-shared-data.md • release_notes/release-3.4.md • table_design/table_design.md