# Snapshot backup **URL:** \ **Category:** Elasticsearch\ **Created:** [February 11, 2020, 1:29pm UTC](https://discuss.elastic.co/t/snapshot-backup/218775 "2020-02-11T13:29:33Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![vijay\_kaali](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vijay_kaali/32/59998_2.png) [@vijay\_kaali](https://discuss.elastic.co/u/vijay_kaali)\ **Post date:** [February 11, 2020, 1:29pm UTC](https://discuss.elastic.co/t/snapshot-backup/218775/1 "2020-02-11T13:29:33Z")
is there any option to backup elasticsearch direct to tape as shared file system will require equal to all index size ? ---
**Author:** ![Magnus\_Kessler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnus_kessler/32/42001_2.png) [@Magnus\_Kessler](https://discuss.elastic.co/u/Magnus_Kessler)\ **Post date:** [February 11, 2020, 2:00pm UTC](https://discuss.elastic.co/t/snapshot-backup/218775/2 "2020-02-11T14:00:38Z")
No. The only safe and supported way to back up a running Elasticsearch index is via the [Snapshot and Restore API](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html). Snapshotting brings all shards of an index into the same location, the repository, after the shards (Lucene) have been informed of the snapshot being in progress. If you simply try to copy the raw lucene segments, you'll likely end up with corrupted shards, as Lucene may be doing background tasks. In addition, as Elasticsearch is responsible for the assignment of shards to nodes, there is no guarantee that a shard belongs to the same node later on. ---
**Author:** ![vijay\_kaali](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vijay_kaali/32/59998_2.png) [@vijay\_kaali](https://discuss.elastic.co/u/vijay_kaali)\ **Post date:** [February 25, 2020, 6:51pm UTC](https://discuss.elastic.co/t/snapshot-backup/218775/3 "2020-02-25T18:51:09Z")
thanks for your update. i dont have space to backup. so i will create repository for each index and backup each index and delete it after backup ---
**Author:** ![vijay\_kaali](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vijay_kaali/32/59998_2.png) [@vijay\_kaali](https://discuss.elastic.co/u/vijay_kaali)\ **Post date:** [February 28, 2020, 5:01am UTC](https://discuss.elastic.co/t/snapshot-backup/218775/4 "2020-02-28T05:01:02Z")
if i backup an index . will each node write its shard into shared mount point ---
**Author:** ![Magnus\_Kessler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnus_kessler/32/42001_2.png) [@Magnus\_Kessler](https://discuss.elastic.co/u/Magnus_Kessler)\ **Post date:** [March 2, 2020, 11:46am UTC](https://discuss.elastic.co/t/snapshot-backup/218775/5 "2020-03-02T11:46:05Z")
Yes, that's correct. During a full cluster snapshot, all shards from all nodes are written to the shared repository. If backing up individual indices, all shards from these indices are written there. ---
**Author:** ![vijay\_kaali](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vijay_kaali/32/59998_2.png) [@vijay\_kaali](https://discuss.elastic.co/u/vijay_kaali)\ **Post date:** [March 4, 2020, 2:25pm UTC](https://discuss.elastic.co/t/snapshot-backup/218775/6 "2020-03-04T14:25:26Z")
thanks for update. one final question. does the shared file system should be NFS . and suppose if we have 100 nodes , then this shared file system mount across all 100 nodes. will it not exceed storage or os limitation of maximum share ? what kind of file system zfs/ext3 ? ---
**Author:** ![Magnus\_Kessler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/magnus_kessler/32/42001_2.png) [@Magnus\_Kessler](https://discuss.elastic.co/u/Magnus_Kessler)\ **Post date:** [March 5, 2020, 10:46am UTC](https://discuss.elastic.co/t/snapshot-backup/218775/7 "2020-03-05T10:46:37Z")
It has to be a shared filesystem if you use filesystem based repositories. Typically this would be implemented with NFS, but other network filesystems might work, too. The same filesystem must be available on _all_ nodes of the cluster. There are [alternatives](https://www.elastic.co/guide/en/elasticsearch/plugins/current/repository.html) to filesystem based repositories, such as S3, GCS, etc. With these, the chosen service provides the disk space, which of course has to be provisioned big enough for the data held in a snapshot. Hope this helps. Good luck snapshotting! ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 2, 2020, 10:46am UTC](https://discuss.elastic.co/t/snapshot-backup/218775/8 "2020-04-02T10:46:39Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.