Skip to main content
Question

Does KDR + immutability really protect from "unintended deletion of restore points" ?

  • April 14, 2026
  • 3 comments
  • 29 views
S

Hi everyone,

I’ve been running tests on K10 DR and immutability features for the past 3 weeks. Despite trying many different configurations, I can’t seem to recover a fully functional restore point after restoring Kasten via K10 DR... specifically when I simulate an “unintended deletion of the restore point” before performing the Kasten restoration.

Here’s my use case:

  1. Create the location profile (with immutability enabled)
  2. Enable K10 DR
  3. Run a backup policy (In my test, I’m using an etcd-backup policy based on the official Kasten Blueprint: https://docs.kasten.io/latest/kanister/etcd/ocp/install)
  4. Run the K10 DR policy
  5. Delete all existing restore points from the Kasten UI
  6. Completely destroy Kasten
  7. Reinstall Kasten
  8. Create the location profile pointing to the same S3 Bucket
  9. Restore Kasten via "Kasten Restore" (K10 DR)
  10. Launch the ETCD restore using the Restore Point, which is now visible again in the Kasten UI after executing "Kasten Restore"

(N.B.: Kasten version used in my tests: v8.5.5)

 

Observed result:

  • Kasten successfully restores the etcd-details secret in the etcd-restore namespace.
  • The prepare-data-job-xxxx pod, which is supposed to fetch the ETCD backup from S3 and place it under /mnt/data/ on one of the master nodes, returns the following error:
    "Error: Failed to load kopia snapshot with ID: snapshot not found"
  • No restore errors are visible in the Kasten UI.

Could someone explain why I’m getting this error, given that KDR + Immutability should theoretically allow me to restore my ETCD backup? Is this a limitation related to using a Kanister Blueprint? If so, since database backups (e.g., PostgreSQL) also require Kanister Blueprints, won’t I run into the same issue: where Kopia can’t find the snapshot ID if I try to use a restore point that was "unintended deleted” and then restored via K10 DR?

Any help or insight regarding Kasten's behavior would be greatly appreciated 🙏🙏🙏


Regards,
Samuel

    3 comments

    Chris.Childerhose
    Forum|alt.badge.img+21

    ​@Madi.Cristil ​@safiya - please move to the Kasten board for better visibility.

    Chris Childerhose (Enterprise Architect) - VMCA | VMCE | VMCE-SP | Veeam Vanguard 8* | Veeam Legend 5* | VUG Canada Leader | vExpert 7* | Toronto VMUG Leader | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
      Jason Orchard-ingram micro
      Forum|alt.badge.img+2

      Following topic for learning reason.

      S

      Little update:

      I tested with a Crunchy Postgres Blueprint and it works well: I was able to backup and restore my database successfully even after intentionally deleted the restore point (and then restore it thanks to the K10 DR feature).
      So the issue seems to be specific to the ETCD Blueprint… not a big issue at the end because in case of a real Disaster (OpenShift cluster lost) we will never try to restore the ETCD database.

      But I’m still curious to understand why it does not work for the ETCD Blueprint 🤔

      Terms & ConditionsAccessibility statement