Snapshot Management

When you create an SM policy, its document ID is given the name . Because of this, SM policies have to obey the following rules:

• You cannot update the policy name after its creation.

SM-created snapshots have names in the format <policy_name>-<date>-<random number>. Two snapshots created by different policies at the same time always have different names because of the <policy_name> prefix. To avoid name collisions within the same policy, each snapshot’s name contains a random string suffix.

An SM schedule is a custom cron expression. It consists of two parts: a creation schedule and a deletion schedule. You must set up a creation schedule that specifies the frequency and timing of snapshot creation. Optionally, you can set up a separate schedule for deleting snapshots.

An SM configuration includes the indexes and repository for the snapshots and supports all parameters you can define when using the API. Additionally, you can specify the format and time zone for the date used in the snapshot’s name.

One snapshot can contain as many indexes as there are in the cluster. We expect at most dozens of SM policies in one cluster, but a snapshot repository can safely scale to thousands of snapshots. However, to manage its metadata, a large repository requires more memory on the cluster manager node.

Snapshot Management depends on the Job Scheduler plugin to schedule a job that is run periodically. Each SM policy corresponds to one SM-scheduled job. The scheduled job is lightweight, so the burden of SM depends on the snapshot creation frequency and the burden of running the snapshot operation itself.

We don’t recommend creating several SM policies with the same schedule and overlapping indexes in one cluster because it leads to concurrent snapshot creation on the same indexes and hinders performance.

We don’t recommend setting up the same repository for multiple SM policies with same schedule in different clusters, since it may cause a sudden spike of burden in this repository.

If a snapshot operation fails, it is retried a maximum of three times. The failure message is saved in metadata.latest_execution and is overwritten when a subsequent snapshot operation starts. You can view the failure message using the explain API. When using OpenSearch Dashboards, you can view the failure message on the . Possible reasons for failure include red index status and shard reallocation.

The Security plugin has two built-in roles for Snapshot Management actions: snapshot_management_full_access and snapshot_management_read_access. For descriptions of each, see Predefined roles.

The following table lists all functions.