kibana/docs/management/snapshot-restore/index.asciidoc

[role="xpack"]
[[snapshot-repositories]]
== Snapshot and Restore

*Snapshot and Restore* lets you back up a running {es}
cluster using data and state snapshots.
Snapshots are important because they provide a copy of your data in case
something goes wrong. If you need to roll back to an older version of your data,
you can restore a snapshot from the repository.

To get started, open the main menu, then click *Stack Management > Snapshot and Restore*.
With this UI, you can:

* Register a repository for storing your snapshots
* View a list of your snapshots and drill down into details
* Restore data into your cluster from a snapshot
* Create a policy to automate snapshot creation and deletion
* Delete a snapshot to free storage space

[role="screenshot"]
image:management/snapshot-restore/images/snapshot_list.png["Snapshot list"]

Before using this feature, you should be familiar with how snapshots work.
{ref}/snapshot-restore.html[Snapshot and Restore] is a good source for
more detailed information.

[float]
[[snapshot-permissions]]
=== Required permissions
The minimum required permissions to access *Snapshot and Restore* include:

* Cluster privileges: `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
* Index privileges: `all` on the `monitor` index if you want to access content in the *Restore Status* tab

To add privileges, open the main menu, then click *Stack Management > Roles*.

[float]
[[kib-snapshot-register-repository]]
=== Register a repository
A repository is where your snapshots live. You must register a snapshot
repository before you can perform snapshot and restore operations.

{kib} supports three repository types
out of the box: shared file system, read-only URL, and source-only.
For more information on these repositories and their settings,
see {ref}/snapshots-register-repository.html[Repositories].
To use other repositories, such as S3, see
{ref}/snapshots-register-repository.html#snapshots-repository-plugins[Repository plugins].

The *Repositories* view displays a list of registered repositories. Click a
repository name to view information about the repository, verify its status, or
clean it up.

[role="screenshot"]
image:management/snapshot-restore/images/repository_list.png["Repository list"]


[float]
[[kib-view-snapshot]]
=== View your snapshots

A snapshot is a backup taken from a running {es} cluster. You'll find an overview of
your snapshots in the *Snapshots* view, and you can drill down
into each snapshot for further investigation.

[role="screenshot"]
image:management/snapshot-restore/images/snapshot_details.png["Snapshot details"]

If you don’t have any snapshots, you can create them using the
{ref}/create-snapshot-api.html[create snapshot API].

[float]
[[kib-restore-snapshot]]
=== Restore a snapshot

The information stored in a snapshot is not tied to a specific
cluster or a cluster name. This enables you to
restore a snapshot made from one cluster to another cluster. You might
use the restore operation to:

* Recover data lost due to a failure
* Migrate an {es} cluster to a new version
* Move data from one cluster to another cluster

To get started, go to the *Snapshots* view, find the
snapshot, and click the restore icon in the *Actions* column.
The Restore wizard presents
options for the restore operation, including which
data streams and indices to restore and whether to change index settings.
You can restore an existing index only if it’s closed and has the same
number of shards as the index in the snapshot.

Once you initiate the restore, you're navigated to the *Restore Status* view,
where you can track the current state for each shard in the snapshot.

[role="screenshot"]
image:management/snapshot-restore/images/snapshot-restore.png["Snapshot details"]


[float]
[[kib-snapshot-policy]]
=== Create a snapshot lifecycle policy

Use a {ref}/snapshot-lifecycle-management-api.html[snapshot lifecycle policy]
to automate the creation and deletion
of cluster snapshots. Taking automatic snapshots:

* Ensures your {es} data is backed up on a regular basis
* Ensures a recent and relevant snapshot is available if a situation
arises where a cluster needs to be recovered
* Allows you to manage your snapshots in {kib}, instead of using a
third-party tool

If you don’t have any snapshot policies, follow the
*Create policy* wizard.  It walks you through defining
when and where to take snapshots, the settings you want,
and how long to retain snapshots.

[role="screenshot"]
image:management/snapshot-restore/images/snapshot-retention.png["Snapshot details"]

An overview of your policies is on the *Policies* view.
You can drill down into each policy to examine its settings and last successful and failed run.

You can perform the following actions on a snapshot policy:

* *Run* a policy immediately without waiting for the scheduled time. This action
is useful before an upgrade or before performing maintenance.
* *Edit* a policy and immediately apply changes to the schedule.
* *Delete* a policy to prevent any future snapshots from being taken.
This action does not cancel any currently ongoing snapshots or remove any previously taken snapshots.

[role="screenshot"]
image:management/snapshot-restore/images/create-policy.png["Snapshot details"]

[float]
[[kib-delete-snapshot]]
=== Delete a snapshot

Delete snapshots to manage your repository storage space.
Find the snapshot in the *Snapshots* view and click the trash icon in the
*Actions* column. To delete snapshots in bulk, select their checkboxes,
and then click *Delete snapshots*.

[[snapshot-repositories-example]]

[role="xpack"]
[[snapshot-restore-tutorial]]
=== Tutorial: Snapshot and Restore


Ready to try *Snapshot and Restore*? In this tutorial, you'll learn to:

* Register a repository
* Add snapshots to the repository
* Create a snapshot lifecycle policy
* Restore a snapshot

==== Before you begin

This example shows you how to register a shared file system repository
and store snapshots.

Before you begin, you must first mount the file system to the same location on
all master and data nodes. Then add the file system’s path or parent directory
to the
{ref}/snapshots-register-repository.html#snapshots-filesystem-repository[`path.repo`]
setting in `elasticsearch.yml` for each master and data node.

[float]
[[register-repo-example]]
==== Register a repository

Use *Snapshot and Restore* to register the repository where your snapshots
will live.

. Open the main menu, then click *Stack Management > Snapshot and Restore*.
. Click *Register a repository* in either the introductory message or *Repository view*.
. Enter a name for your repository, for example, `my_backup`.
. Select *Shared file system*.
+
[role="screenshot"]
image:management/snapshot-restore/images/register_repo.png["Register repository"]

. Click *Next*.
. In *File system location*, enter the path to the snapshot repository, `/tmp/es-backups`.
. In *Chunk size*, enter `100mb` so that snapshot files are not bigger than that size.
. Use the defaults for all other fields, and then click *Register*.
+
Your new repository is listed on the *Repositories* view.
The repository currently doesn’t have any snapshots.


[float]
==== Add a snapshot to the repository
Use the {ref}/snapshots-take-snapshot.html[snapshot API] to create a snapshot.

. Open the main menu, click *Dev Tools*, then select *Console*.
. Create the snapshot:
+
[source,js]
PUT /_snapshot/my_backup/2099-04-25_snapshot?wait_for_completion=true
+
In this example, the snapshot name is `2099-04-25_snapshot`. You can also
use {ref}/date-math-index-names.html[date math expression] for the snapshot name.

. Return to *Snapshot and Restore*.
+
Your new snapshot is available in the *Snapshots* view.

[[create-policy-example]]
==== Create a snapshot lifecycle policy

Now you'll automate the creation and deletion of snapshots
using the repository created in the previous example.

. Open the *Policies* view.
. Click *Create a policy*.
+
[role="screenshot"]
image:management/snapshot-restore/images/create-policy-example.png["Create policy wizard"]

. As you walk through the wizard, enter the following values:
+
|===
|*Logistics* |

|Policy name
|`daily-snapshots`

|Snapshot name
|`<daily-snap-{now/d}>`

|Repository
|`my_backup`

|Schedule
|Every day at 1:30 a.m.

|*Snapshot&nbsp;settings* |

|Data streams and indices
|Select the data streams and indices to back up. By default, all data streams
and indices, including system indices, are backed up.

|All&nbsp;other&nbsp;settings
|Use the defaults.

|*Snapshot&nbsp;retention* |

|Expiration
|`30 days`

|Snapshots&nbsp;to&nbsp;retain
|Minimum count: `5`, Maximum count: `50`
|===

. Review your input, and then click *Create policy*.
+
Your new policy is listed in the *Policies* view, and you see a summary of its details.

[[restore-snapshot-example]]
==== Restore a snapshot
Finally, you'll restore data streams and indices from an existing snapshot.

. In the *Snapshots* view, find the snapshot you want to restore, for example `2099-04-25_snapshot`.
. Click the restore icon in the *Actions* column.
. As you walk through the wizard, enter the following values:
+
|===
|*Logistics* |

|Data streams and indices
|Toggle to choose specific data streams and indices to restore. Use the default
to restore all data streams and indices in the snapshot.

|Rename data streams and indices
|Toggle to give your restored data streams and indices new names. Use the
default to restore the original data stream and index names.

|All other fields
|Use the defaults.

|*Index&nbsp;settings* |

|Modify&nbsp;index&nbsp;settings
|Toggle to overwrite index settings when they are restored,
or leave in place to keep existing settings.

|Reset&nbsp;index&nbsp;settings
|Toggle to reset index settings back to the default when they are restored,
or leave in place to keep existing settings.
|===

. Review your restore settings, and then click *Restore snapshot*.
+
The operation loads for a few seconds,
and then you’re navigated to *Restore Status*,
where you can monitor the status of your restored data streams and indices.