# Understanding Remote-Backed Storage

**URL:** <https://forum.opensearch.org/t/understanding-remote-backed-storage/20269>\
**Category:** OpenSearch\
**Created:** [July 12, 2024, 7:29pm UTC](https://forum.opensearch.org/t/understanding-remote-backed-storage/20269 "2024-07-12T19:29:58Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rookuu](https://avatars.discourse-cdn.com/v4/letter/r/ea5d25/32.png) [@rookuu](https://forum.opensearch.org/u/rookuu)\
**Post date:** [July 12, 2024, 7:29pm UTC](https://forum.opensearch.org/t/understanding-remote-backed-storage/20269/1 "2024-07-12T19:29:59Z")

</div>

**Versions** (relevant - OpenSearch/Dashboard/Server OS/Browser):

2.15.0

**Describe the issue** :

I’ve been testing out the remote-backed storage implementation as described [here](https://opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/remote-store/index/) and want to understand the expected behaviour.

I have a cluster with remote-backed storage fully enabled, including state. If the cluster has a catastrophic failure, I would expect that it could be rebuilt from the remote state as described in the documentation.

When testing the feature, I noted that when the cluster was re-created after the failure whilst it did sync the `.opendistro_security` index - it remained in an uninitialized state. Are their additional steps required before the cluster is made functional?

The output suggested running the `securityadmin.sh` tool, but I didn’t expect this to be required, and would lose my existing security configuration.

Am I missing something here?

---

<div class="post-metadata">

**Author:** ![pablo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/pablo/32/10363_2.png) [@pablo](https://forum.opensearch.org/u/pablo)\
**Post date:** [August 14, 2024, 11:57pm UTC](https://forum.opensearch.org/t/understanding-remote-backed-storage/20269/2 "2024-08-14T23:57:47Z")

</div>

@rookuu The .opendistro\_security index can be accessed only by superadmin user and its certificate and key.  
Any snapshots including .opendistro\_security index also require superadmin user.

Could you describe the exact recovery steps?