Context
Some guidance from @agoose77 , storing here so we can tackle this quickly
Q: Is this worth documenting?
A: I think we should document this. My rationale is that we have a publicly visible (Terraform) policy for snapshots, so people can easily see that we do provide backups.
Q: Share a few points about how this works:
A:
- Interfaces like JLab have a staging area for trash. For deletions via the UI, this can help. We could also encourage our communities to use tools like send2trash instead of rm but I think that's pretty hard. Therefore, for actual recovery, the process is presently manual and bespoke to each cloud provider - performed by 2i2c engineers.
- This practice can be applied by anyone with the proper permissions on the cloud infra, iff. their hub has backups turned on (https://infrastructure.2i2c.org/howto/filesystem-management/filesystem-backups/restore-filesystem/). Normally, that's just 2i2c engineers, and on AWS/GCP hubs only. We could define a policy like "send this support ticket template to us" in order to make it more accessible.
- I think rare occasions -- we only store three consecutive daily snapshots.
- Mostly already stated -- this mechanism is really for us to protect against data loss, rather than individual file loss (due to the granularity of snaphots)
There is a cost associated with this, but it will likely be negligible.
Context
Some guidance from @agoose77 , storing here so we can tackle this quickly
Q: Is this worth documenting?
A: I think we should document this. My rationale is that we have a publicly visible (Terraform) policy for snapshots, so people can easily see that we do provide backups.
Q: Share a few points about how this works:
A:
There is a cost associated with this, but it will likely be negligible.