Hi, for a BYOB DuckLake using R2, does ducklake_cleanup_old_files physically delete Parquet objects from our bucket? And does MotherDuck’s seven-day failsafe actually preserve or allow recovery of those deleted R2 objects—or does it protect only the catalog metadata?
Greetings from The Hatchery! Motherduck's offices are closed in observance of Independence Day. Our on-call teams will still be monitoring for any urgent issues, so please don't hesitate to reach out if something comes up. We'll be back to our regular hours on Monday, July 6th. As always, we're grateful for the opportunity to partner with you.
Hey Greg O., we're looking into this!
ducklake_cleanup_old_files does physically the delete Parquet files on your bucket. However, the failsafe only allows you to recover the metadata catalog for up to 7 days, but it won't cover the objects in R2. Hope this helps!
Thanks—that confirms the seven-day failsafe is metadata-only. For a MotherDuck-hosted DuckLake catalog with BYOB R2:
If we request recovery within seven days to immediately before a ducklake_expire_snapshots operation, will the restored catalog also restore the snapshot and files_scheduled_for_deletion state, provided the R2 objects have not yet been cleaned up?
What is the supported way to export or back up __ducklake_metadata_<database> so it can be paired with our own R2 object backup and used in a tested disaster-recovery procedure?If R2 rejects DeleteObject because of a bucket-lock rule, does ducklake_cleanup_old_files leave the file scheduled and safely retryable without removing its metadata record?
Hey Greg O., to answer your questions:
Yes, the state of the snapshots and files_scheduled_for_deletion will be restored
MotherDuck maintains snapshots of the catalog database, which you can view with MD_INFORMATION_SCHEMA.DATABASE_SNAPSHOTS. In the event you need restore, you can match the snapshot timestamp with your own R2 object backup timestamp to determine the best snapshot to restore from.
If R2 rejects DeleteObject because of a bucket-lock rule, does ducklake_cleanup_old_files leave the file scheduled and safely retryable without removing its metadata record?
When a file cannot be cleaned up due to a bucket-lock rule, you'll get an IO error, and you can retry ducklake_cleanup_old_files again because the files_scheduled_for_deletion record is unchanged Hope this helps!
Thanks. This confirms the bucket-lock behavior we needed. One final operational clarification: the ALTER DATABASE SET SNAPSHOT documentation says DuckLake databases do not support snapshot restore. For a MotherDuck-managed BYOB DuckLake, what exact procedure restores its metadata catalog to a snapshot shown in MD_INFORMATION_SCHEMA.DATABASE_SNAPSHOTS? Is this support-assisted, and can we request an exact SNAPSHOT_ID? During recovery, should we restore the corresponding R2 backup first and keep bucket lock enabled until the restored files_scheduled_for_deletion queue has been reviewed?
Hi Greg O., This is a support-assisted action. We can restore a DuckLake metadata catalog to a specific snapshot ID provided its within the retention period for your plan.
.png)