Kvindo™ Cloud Docs
Moving an existing OpenSearch corpus into a Kvindo Cloud OpenSearch cluster. The corpus is usually a pile of per-tenant or per-day indices — <id>_event, logs-2026.10.22 — which shapes the whole approach: there are many small indices rather than a few large ones, so the per-index cost of touching each one matters more than raw throughput.
• Snapshot and restore. There is no snapshot repository on a Kvindo Cloud cluster and no restore action, so you cannot hand the platform a backup and ask it to load it.
• Reindex from a remote cluster. _reindex with a remote source is a cluster-level operation, and a tenant OpenSearch User has no cluster permissions by design. The allow-list it would also need (reindex.remote.allowlist) is a node setting, not a tenant one.
What remains is a client-side copy: read from the source with your own credentials, write into the target with an OpenSearch User. That is what the guide describes, and it has a real advantage — you control the pace, the retry policy and the checkpointing, and the source is only ever read.
• An OpenSearch User on the target cluster with ReadWrite on the index patterns you are creating, and its password
• The target's CA certificate (status.caCertificate) — the cluster speaks TLS only, including inside the VPC
• A network path from wherever the script runs to both clusters: the same VPC as the target, or spec.createPublicIpv4 on the target plus your own egress
• Enough free space on the target's data volumes for the whole corpus — the copy duplicates the data, it does not move it
Step-by-step, with the measured timings and the traps that cost real hours: reading the source's index settings, creating the target index correctly, bulk-loading with a script you can re-run, verifying, and cutting over.
More in this section