Skip to content

Back up and restore

Elasticsearch snapshots provide the primary data-recovery mechanism for the managed platform.

Snapshots can protect:

  • Elasticsearch indices and data streams;
  • supported cluster state;
  • selected feature state.

Snapshot storage is separate from the active Elasticsearch data volumes.

Understand your backup configuration

The exact snapshot schedule, retention, and recovery options depend on the deployed configuration and service plan.

You can review snapshot status in Kibana when your role allows access to Snapshot and Restore.

Useful information includes:

  • configured snapshot repository;
  • most recent successful snapshot;
  • snapshot frequency;
  • retention period;
  • failed or partial snapshots.

Do not assume that an Azure storage account alone means a complete backup policy is active.

Managed backup monitoring

iVedha monitors supported platform backup and snapshot conditions as part of managed operations.

Customers should still understand their business recovery requirements, including:

  • how much data loss is acceptable;
  • how far back data might need to be recovered;
  • which indices or workloads are business critical.

If your recovery requirements change, contact iVedha so the platform configuration can be reviewed.

Before a significant change

For changes that could materially affect data, configuration, or mappings, a recent snapshot may be appropriate.

When the change is performed through a supported iVedha workflow, the platform process can determine whether additional recovery protection is required.

Customers do not need to create manual snapshots before every routine managed operation.

Request a restore

Restore operations should be coordinated through iVedha.

Use:

  • AI chat: https://copilot.opsflw.io
  • Support portal: https://support.ivedha.com/

Provide:

  • the deployment reference;
  • the approximate recovery point required;
  • the affected index, data stream, or workload;
  • whether the request is for accidental deletion, corruption, testing, or another recovery scenario.

Do not attempt a broad restore directly against production unless it is part of an approved recovery procedure.

Restore scope

Depending on the recovery scenario, a restore can involve:

  • one or more indices;
  • data streams;
  • selected feature state;
  • a larger Elasticsearch recovery.

Restoring data can conflict with existing index names or current writes, so the recovery scope should be agreed before the operation begins.

Validate recovered data

A restore is not complete until the recovered workload is validated.

After recovery, confirm:

  • expected indices or data streams are present;
  • document counts are reasonable;
  • important searches return expected results;
  • Kibana content works where applicable;
  • application indexing and queries behave normally;
  • users and roles behave as expected;
  • Elastic Agent and OpenTelemetry ingestion continue normally for observability workloads.

Full-platform recovery

Elasticsearch snapshots protect Elasticsearch data and supported state. They are not a backup of the complete Azure or Kubernetes infrastructure.

Full-platform recovery is managed by iVedha using the supported platform recovery process.

Recovery planning

For business-critical workloads, define:

  • recovery point objective (RPO);
  • recovery time objective (RTO);
  • critical indices and applications;
  • validation owners;
  • escalation contacts.

iVedha can help review the platform configuration against these recovery requirements.

Need help

For snapshot, backup, or recovery assistance:

  • AI chat: https://copilot.opsflw.io
  • Support portal: https://support.ivedha.com/

Provide the deployment reference and recovery requirement. Do not include passwords, API keys, private keys, or other secrets.

Next step

Continue with prepare for upgrades.