# Elastic stack backup **URL:** \ **Category:** Elasticsearch\ **Created:** [December 23, 2018, 5:09am UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935 "2018-12-23T05:09:38Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![DineshTripathi](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@DineshTripathi](https://discuss.elastic.co/u/DineshTripathi)\ **Post date:** [December 23, 2018, 5:09am UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/1 "2018-12-23T05:09:38Z")
Hello, After reading various doc's and discussions about Elastic stack backup, I understand the following and would like someone to validate please :- 1. Elasticseach index backup using snapshot feature which will keep snapshot in shared file system which can be backed up using any tool. 2. No separate requirement for backup of logstash, kibana and beats as the data is stored in indexes which is getting backed up already. Question:- 1. In case of cluster crash, let say i reinstalled the Elastic stack, so should be keep copy of config files directory as well ? e..g /etc/elasticsearch/\* and similarly other components config? 2. Any standard schedule recommendation when we implement backup? e.g. once in a day etc. 3. What is standard way to schedule that backup? do you recommend some tool or we can write the script by own and run per schedule ? ---
**Author:** ![DineshTripathi](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@DineshTripathi](https://discuss.elastic.co/u/DineshTripathi)\ **Post date:** [January 2, 2019, 12:17pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/2 "2019-01-02T12:17:28Z")
Can anyone please help me for this topic? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [January 2, 2019, 1:02pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/3 "2019-01-02T13:02:56Z")
> [@DineshTripathi](#): > > 1. Elasticseach index backup using snapshot feature which will keep snapshot in shared file system which can be backed up using any tool Yes. > [@DineshTripathi](#): > > 1. No separate requirement for backup of logstash, kibana and beats as the data is stored in indexes which is getting backed up already. Much of their data is indeed stored in Elasticsearch, but I think there are some config files that also need backing up: > [@DineshTripathi](#): > > 1. In case of cluster crash, let say i reinstalled the Elastic stack, so should be keep copy of config files directory as well ? e..g /etc/elasticsearch/\* and similarly other components config? Yes. > [@DineshTripathi](#): > > 1. Any standard schedule recommendation when we implement backup? e.g. once in a day etc. That's up to you, based on your desired [RPO](https://en.wikipedia.org/wiki/Disaster_recovery#Recovery_point_objective). Since snapshots are incremental, it's cheap to do them fairly frequently. Taking a snapshot every 30 minutes isn't unusual. > [@DineshTripathi](#): > > 1. What is standard way to schedule that backup? do you recommend some tool or we can write the script by own and run per schedule ? It's up to you, based on your operating environment. [Curator](https://www.elastic.co/guide/en/elasticsearch/client/curator/current/ex_snapshot.html) might be useful. Remember that **backups always succeed, it's the restores that fail**. The only way to be sure your backup process is working reliably is to regularly restore your system from backup. ---
**Author:** ![DineshTripathi](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@DineshTripathi](https://discuss.elastic.co/u/DineshTripathi)\ **Post date:** [January 2, 2019, 1:06pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/4 "2019-01-02T13:06:03Z")
Thanks @DavidTurner for your view. Could you please help me with second question about what all conf files? one i understand may be /etc/elasticsearch, kibana,beats, logstash where we have configuration files. But do you think there are any other configuration files at OS level? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [January 2, 2019, 1:12pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/5 "2019-01-02T13:12:18Z")
A lot of users store this in a version control system and use orchestration tools like Chef, Puppet or Ansible to deploy them. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [January 2, 2019, 1:16pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/6 "2019-01-02T13:16:55Z")
We can't really say which OS configuration you will need to copy. It depends very much on how you will provision new infrastructure during your restore process. The only way you can be sure that your backup process is capturing everything it needs is to regularly restore everything from backup. ---
**Author:** ![DineshTripathi](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@DineshTripathi](https://discuss.elastic.co/u/DineshTripathi)\ **Post date:** [January 2, 2019, 1:19pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/7 "2019-01-02T13:19:47Z")
@DavidTurner I understand this part. In general case let say OS is not crashed then just indices restore will help. Let say in case, where Complete OS is crashed and I need to deploy fresh OS. in those cases config files would be handy else full reconfiguration should be done before restoring the indices backup. Do we have any doc which covers such scenario? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [January 2, 2019, 1:27pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/8 "2019-01-02T13:27:12Z")
> [@DineshTripathi](#): > > Do we have any doc which covers such scenario? The [reference manual](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html) describes how to set up a new cluster. Your restore process needs to do this. ---
**Author:** ![DineshTripathi](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@DineshTripathi](https://discuss.elastic.co/u/DineshTripathi)\ **Post date:** [January 2, 2019, 1:31pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/9 "2019-01-02T13:31:48Z")
Thanks. So basically a fresh setup manually. ---
**Author:** ![DineshTripathi](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@DineshTripathi](https://discuss.elastic.co/u/DineshTripathi)\ **Post date:** [January 2, 2019, 4:30pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/10 "2019-01-02T16:30:45Z")
@DavidTurner one more question i had one this part, since Elasticssearch snapshot backup is incremental, I can restore from any snapshot and will it have dependencies on older ones? I am asking this because, in case i want to remove 30 days older snapshot, i should not loose the data. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [January 2, 2019, 4:39pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/11 "2019-01-02T16:39:58Z")
Yes, the repository keeps the data around while there are any snapshots that still need it. The data is only deleted once there are no more snapshots that reference it. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [January 30, 2019, 4:47pm UTC](https://discuss.elastic.co/t/elastic-stack-backup/161935/12 "2019-01-30T16:47:53Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.