# Simple backup scenario

**URL:** <https://discuss.elastic.co/t/simple-backup-scenario/6865>\
**Category:** Elasticsearch\
**Created:** [March 2, 2012, 10:21am UTC](https://discuss.elastic.co/t/simple-backup-scenario/6865 "2012-03-02T10:21:45Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![yantsu](https://avatars.discourse-cdn.com/v4/letter/y/b5a626/32.png) [@yantsu](https://discuss.elastic.co/u/yantsu)\
**Post date:** [March 2, 2012, 10:21am UTC](https://discuss.elastic.co/t/simple-backup-scenario/6865/1 "2012-03-02T10:21:45Z")

</div>

After reading posts about backup/restore elasticsearch I came to a  
solution fitting to the simple situation to be supported.

It would be nice to get some feedback if something is wrong or  
overlooked by me.  
Perhaps it can be used be others as a template being in the same  
situation as I didn't found concrete configuration examples so far.

The Situation:  
ES will be deployed on two machines, one machine is in a kind of hot  
standby, i.e. no user activity will happen on it.  
There is no filesystem shared between both machines.  
ES node and client are deployed on the same machine and connected  
locally.  
We want to have ES to spawn a cluster over both machines having all  
data fully replicated on both machines.  
If one machine is getting to be unavailable, the other machine can  
take over without any administrative interaction.  
For the backup, it doesn't matter what machines filesystem is used as  
both are having fully replicated data.  
Network traffic for searches and gets will stay on the same machine.

The configuration: (assuming the machines are having the ips  
192.168.1.200 and 192.168.1.201)

## Machine with ip: 192.168.1.200

cluster:  
name: es-backuped  
routing.allocation.awareness:  
attributes: machine  
force.machine.values: A, B  
node:  
machine: A  
local: false  
discovery.zen.ping:  
multicast.enabled: false  
unicast.hosts: 192.168.1.201

## Machine with ip: 192.168.1.201

cluster:  
name: es-backuped  
routing.allocation.awareness:  
attributes: machine  
force.machine.values: A, B  
node:  
machine: B  
local: false  
discovery.zen.ping:  
multicast.enabled: false  
unicast.hosts: 192.168.1.200

I've used unicast as we do not need any dynamic cluster changes.

To backup the data, we will check the cluster state to ensure nodes  
are in sync, then we can either shutdown the node on the inactive  
machine or we are using the settings api ([http://www.elasticsearch.org/](http://www.elasticsearch.org/)  
guide/reference/api/admin-indices-update-settings.html) to disable  
flush or set all indexes into the readonly mode.  
After backup is done we will start the node again or revert the  
setting changes we've done before.

In fact, if the settings api is used, the configuration might work for  
balanced machines (both active) as well.

Would that work propperly? Is it a propper solution for the given  
scenario?

Thanks

Claas

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:37am UTC](https://discuss.elastic.co/t/simple-backup-scenario/6865/2 "2017-07-06T03:37:36Z")

</div>