Add ability to snapshot to file system of a single node.

[imotov]

Add new "local" snapshot repository type that would be similar to shared filesystem repository but will allow storing all snapshot file on a local file system of a single node.

[jordansissel]

What about an alternative - an API to download a tarball of a snapshot. "GET" a snapshot allows you to download the full snapshot (from the cluster, not just one node) ? I'm OK if my proposal is rejected ;)

[dadoonet]

@jordansissel May be this is something we could work on in the future if at one point we want to deal with "attachments", so stream binary content to a client. But I might be wrong.

My 2 cents.

[saahn]

what is the recommendation for restoring from the current fs repository? if i specify local fs path on each node, a snapshot of each node gets created separately on each individual node. If I want to restore these snapshots to a new cluster in a different datacenter that may not have the same number of nodes, the restore process is not as simple as scp-ing a tarball to each node in the new cluster... do you have any suggestions around this? Thanks.

[clever-trevor]

It looks like since the latest release of ES (1.4.1 is where I noticed this) the location for a snapshot has to be a shared mount, and ES seems to check for this now erroring with something like this when I try to use a local filesystem :

RepositoryVerificationException[[kibana-int] store location [/apps/elk/data/elasticsearch/backup] is not shared between node

In an older version, I could put a local directory and it worked as long as the same directory existed on the nodes.

I like the idea of being able to say "snapshot an entire index to a named node", either through the existing snapshot mechanism with some additional parameters to specify this, or as a tar file, as long as the snapshot is portable to another node where I could restore through that mechanism.

[clintongormley]

@imotov do you still think this is something that we should implement? My inclination would be to say: just set up an NFS mount or similar.

[imotov]

@clintongormley we should definitely implement that. It will help users in several important use cases, including simplifying sharing of marvel data with support.

[ashish-kumar-goel]

I am facing a similar issue. I have placed my cluster nodes on EC2 instances and when I try to take a snapshot on a local FS repository, it gives an error saying that the target location for snapshot is not shared.
Then, I made use of a S3 repository for taking snapshots. It works well, the only problem is that when it is taking snapshots, the process blocks any updates over ES. I read something regarding this which mentioned that ES needs to take into account the details of the previous snapshots taken (figuring out the segments involved) and due to this it takes some time in creating the new one. I already have a cron job setup which deletes a week old snapshots but even after that it takes some time to create the new snapshots.
So, I was wondering if there is a way I can move out of S3, make use of a local repository. Please not that these nodes are not having any shared mount space.

[t33m]

Additionally, encrypted snapshots to nfs share - it's more secure. If it's impossible, we have only one way - make snapshots to local server, compress and encrypt them and then move to nfs share.

Can you add on-the-fly encryption in AES mode to nfs share or add local snapshots type?

[shaharmor]

Is this being worked on?

[imotov]

I am not working on it at the moment. If somebody wants to take over, I will be glad to provide any assistance.

[erdarun]

Is anyone working on this feature?

[DaveCTurner]

This user would benefit from this feature. Rather than setting up a shared filesystem they have instead invented a backup strategy that seems a little delicate.

@erdarun no, I do not know of anyone working on this right now.

[DaveCTurner]

We discussed this again today and feel that there are now a decent number of third-party options that would let you achieve the goals of this feature request without needing any changes in Elasticsearch. For example, Minio will accept snapshots onto a single node, or indeed onto a completely independent cluster. Implementing this feature would, in effect, require us to duplicate all the work that has gone into systems like Minio. We therefore agreed to close this issue.

[AnyCPU]

I would like to see this feature built-in, otherwise it is at least not user friendly. It is very good to have built-in alternative to 3rd party plug-ins. Maybe we should wait for another 6 years to get this feature.

[webmstr]

We discussed this again today and feel that there are now a decent number of third-party options that would let you achieve the goals of this feature request without needing any changes in Elasticsearch. For example, Minio will accept snapshots onto a single node, or indeed onto a completely independent cluster. Implementing this feature would, in effect, require us to duplicate all the work that has gone into systems like Minio. We therefore agreed to close this issue.

According to wikipedia, "MinIO is an Amazon S3 compatible server-side software storage stack". You're saying that's the solution for a local filesystem backup??