How to restore elastic search snapshot another cluster? without repository-s3, repository-hdfs, repository-azure, repository-gcs.
This answer is wrt Elastic Search 7.14. So, it is possible to host a snapshot repository on a NFS. Since, you would like to restore snapshot of one cluster to another, you would need to meet the following pre-requisites:
The NFS should be accessible from both source and destination cluster.
The version of the source and destination cluster should be the same. At most, the destination cluster can be 1 major version higher than the source cluster. Eg: you can restore a 5.x snaphot. to a 6.x cluster, but not a 7.x cluster.
Ensure that the shared NFS directory is owned by uid:gid = 1000:0 (elasticsearch user), and appropriate permissions are given (chmod -R 777 <appropriate NFS directory> as elasticsearch user)
Now, I am detailing the steps that you could take to copy the data.
Create a registry of type fs on the source cluster:
PUT http://10.29.61.189:9200/_snapshot/registry1
{
"type": "fs",
"settings": {
"location": "/usr/share/elasticsearch/snapshotrepo",
"compress": true
}
}
Take a snapshot on the created registry:
PUT http://10.29.61.189:9200/_snapshot/registry1/snapshot_1?wait_for_completion=true
{
"indices": "employee,manager",
"ignore_unavailable": true,
"include_global_state": false,
"metadata": {
"taken_by": "binita",
"taken_because": "test snapshot restore"
}
}
Create a registry of type url on the destination cluster. Type url will ensure that the same registry (in terms of the shared NFS path) will be read-only wrt the destination cluster. Destination cluster can only restore/read snapshot info, but can not write snapshots.
PUT http://10.29.59.165:9200/_snapshot/registry1
{
"type": "url",
"settings": {
"url": "file:/usr/share/elasticsearch/snapshotrepo"
}
}
Restore the snapshot generated from source cluster (in step no 2) to the destination cluster.
POST http://10.29.59.165:9200/_snapshot/registry1/snapshot_1/_restore
For more info, refer : https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-restore-snapshot.html
Finally i found the solution.it work fine.please read carefully and do.
if you have question contact me waruna94kithruwan#gmail.com.
I have two elastic search cluster.i want a migrate elastic_01 data to elastic_02.
i mean elastic_01 snapshot restore to elastic_02.let's go.
Importent
verify elastic_01 and elastic_02 has this folder "/home/snapshot/".
if not exist create this folder first.
set correct permission to this folder.
please verify elastic_01 and elatic_02 versions same or match.
[elasticsearch snapshot documentation]: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html
(01) set elastic_01 snapshot settings
$ curl -XPUT '/_snapshot/first_backup' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/home/snapshot/",
"compress": true
}
}'
(2) add snapshot location to elasticsearch.yml (elastic_01)
edit elasticsearch.yml file and add this code line and save.
$ path.repo: ["/home/snapshot/"]
(03) create snapshot (elastic_01)
$ curl -XPUT "/_snapshot/first_backup/snapshot_1?wait_for_completion=true"
(04) set elastic_02 snapshot settings
$ curl -XPUT '/_snapshot/first_backup' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/home/snapshot/",
"compress": true
}
}'
(05) add snapshot location to elasticsearch.yml (elastic_02)
edit elasticsearch.yml file and add this code line and save.
$ path.repo: ["/home/snapshot/"]
(06) create snapshot (elastic_02)
$ curl -XPUT "/_snapshot/first_backup/snapshot_1?wait_for_completion=true"
(07) copy elastic_01 snapshot to >>>> elastic_02
delete elastic_02 snapshot folder content $ rm -rf /home/snapshot/*
copy elastic_01 snapshot folder content to elastic_02 snapshot folder
(08) list snapshot
$ curl -XGET '/_snapshot/first_backup/_all?pretty'
it will show backup indexes and snapshot related data
(09) restore elastic search snapshot
$ curl -XPOST "/_snapshot/first_backup/snapshot_1/_restore?wait_for_completion=true"
NOTE: We need to make parameter "include_global_state" to "true" to restore the template as per link " https://www.elastic.co/guide/en/elasticsearch/client/curator/current/option_include_gs.html"
curl -X POST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore?pretty" -H 'Content-Type: application/json' -d'
{
"include_global_state": true
}
'
{
"accepted" : true
}
Your idea is to first create a snapshot on nodeB, then delete its data and overwrite nodeA's data to this location?
But according to elastic's documentation, nodeB should mount the NFS directory in a read-only manner, so it does not have write permissions, such as using the type: url repository.
PUT _snapshot/local
{
"type": "url",
"settings": {
"url": "file:/home/esdata/snapshot"
}
}
Related
I'm using elastiSearch 8.3 on a windows machine, and created a shared file system repository - my_repo:
PUT _snapshot/my_repo
{
"type": "fs",
"settings": {
"location": "relative_path"
}
}
The base path for this repository is set in the .yml file:
path.repo: \\path1\path1
If I'm changing the path in the .yml file (to e.g. \path2\path2), restart elastic and trying to recreate/update the my_repo:
PUT _snapshot/my_repo
{
"type": "fs",
"settings": {
"location": "relative_path"
}
}
I'm getting an error:
"[my_repo] Could not read repository data because the contents of the
repository do not match its expected state. This is likely the result
of either concurrently modifying the contents of the repository by a
process other than this cluster or an issue with the repository's
underlying storage. The repository has been disabled to prevent
corrupting its contents. To re-enable it and continue using it please
remove the repository from the cluster and add it again to make the
cluster recover the known state of the repository from its physical
contents."
Only if I'm changing back to the previuos path (\path1\path1) and set my_repo to readonly = true
I can than change the path (\path2\path2) and update the repository.
I know that only one cluster can register the repository for write, but here I have only one cluster...
The old server will remove, that Elasticsearch version is v6.8, the new server installed same version. Now, I'll migrate all data to the new server. Is my operation correct?
Old server: elasticsearch.yml add path.repo, for example
path.repo:["/data/backup"]
Restart Elasticsearch services
Old server
curl -H "Content-Type: application/json"
-XPUT http://192.168.50.247:9200/_snapshot/my_backup
-d '{ "type": "fs", "settings":
{ "location": "/data/backup","compress": true }}'
Create backup
curl -XPUT http://192.168.50.247:9200/_snapshot/my_backup/news0618
Restore database(new server ip:192.168.10.49 ):
curl -XPOST http://192.168.10.49:9200/_snapshot/my_backup/news0618/_restore
Are these operations can migrate all the data?
If you are using fs as a snapshot repository location then it will not work as your new instance is hosted on different host it will not have access to your old hosts file system. You need to use any shared location like volume mounts, S3 or Azure blob etc.
You should use reindexing rather than snapshot and restore. Its pretty simpler. Refer this link for remote reindexing:
Steps:
Whitelist remote host in elasticsearch.yaml using the reindex.remote.whitelist property in your new Elasticsearch instance:
reindex.remote.whitelist: "192.168.50.247:9200"
Restart new Elasticsearch instance.
Reindexing:
curl -X POST "http://192.168.10.49:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
{
"source": {
"remote": {
"host": "http://192.168.50.247:9200"
},
"index": "source-index-name",
"query": {
"match_all": {}
}
},
"dest": {
"index": "dest-index-name"
}
}
'
Refer this link for reindexing many indices
Warning: The destination should be configured as wanted before calling _reindex. Reindex does not copy the settings from the source or its associated template. Mappings, shard counts, replicas, and so on must be configured ahead of time.
Hope this helps!
I setup a snapshot repository for one node ES cluster running inside a container.
version 7.7.1
path.repo=[/usr/share/elasticsearch/data/snapshot]
PUT /_snapshot/my_backup
{
"type": "fs",
"settings": {
"location": "/usr/share/elasticsearch/data/snapshot"
}
}
It works well.
However in a multinode cluster it fails with RepositoryVerificationException.
How should I change the above code to be able to use it?
I come across these sources but both of them unclear about what to do exactly:
https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html
https://discuss.elastic.co/t/snapshot-and-path-repo-on-one-cluster-node/155717
I need to automate the snapshot and restore from one cluster to a backup cluster , but when I try to restore the snapshot it complains about the indices already exist. Then I either need to delete those indices or close those to be freshly restored. Is there any --force kind of option to overwrite everything from live cluster to backup cluster ?
There is re-indxeing option but that is slow as compared to snapshot and restore.
You can define rename_pattern and rename_replacement as documentation suggests. To make it fully automated you could add time/date:
POST /_snapshot/my_backup/snapshot_1/_restore
{
"indices": "index_1,index_2",
"ignore_unavailable": true,
"include_global_state": true,
"rename_pattern": "(.+)",
"rename_replacement": "$1_20180820"
}
And then use aliases to make this "backup" index look like a "normal" one:
POST /_aliases
{
"actions" : [
{ "add" : { "index" : "index_1_20180820", "alias" : "index_1" } }
]
}
Of course this means that you would have to write some automation scripts that generate that time/date and check the snapshot restore progress.
Hope that helps!
A Kibana newbie would like to know how to set default index pattern programmatically rather than setting it on the Kibana UI through web browser during the first time viewing Kibana UI as mentioned on page https://www.elastic.co/guide/en/kibana/current/setup.html
Elasticsearch stores all Kibana metadata information under .kibana index. Kibana configurations like defaultIndex and advance settings are stored under index/type/id .kibana/config/4.5.0 where 4.5.0 is the version of your Kibana.
So you can achieve setting up or changing defaultIndex with following steps:
Add index to Kibana which you want to set as defaultIndex. You can do that by executing following command:
curl -XPUT http://<es node>:9200/.kibana/index-pattern/your_index_name -d '{"title" : "your_index_name", "timeFieldName": "timestampFieldNameInYourInputData"}'
Change your Kibana config to set index added earlier as defaultIndex:
curl -XPUT http://<es node>:9200/.kibana/config/4.5.0 -d '{"defaultIndex" : "your_index_name"}'
Note: Make sure your giving correct index_name everywhere, valid timestamp field name and kibana version for example if you are using kibana 4.1.1 then you can replace 4.5.0 with 4.1.1 .
In kibana:6.5.3 this can be achieved this calling the kibana api.
curl -X POST "http://localhost:5601/api/saved_objects/index-pattern/logstash" -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d'
{
"attributes": {
"title": "logstash-*",
"timeFieldName": "#timestamp"
}
}
'
the Docs are here it does mention that the feature is experimental.