OK, I changed them to "elasticsearch" and restart service and elasticsearch is running.
I run commands and got:
{
"acknowledged": true
}Is it OK? If yes, Where is my backup?
Which command gave the acknowledged: true? The repository creation?
PUT /_snapshot/my_backup
{
"type": "fs",
"settings": {
"compress": true,
"location": "/var/log/back-long/repo"
}
}You haven't created a snapshot yet. You've created a repository. When you perform a snapshot, you can now select my_backup as the repository. It will write data to /var/log/back-long/repo.
How can I do it?
This was answered already in this very thread, here.
Excuse me, I'm a beginner. I did:
GET /_snapshot/my_backupAnd result is:
{
"my_backup": {
"type": "fs",
"settings": {
"compress": "true",
"location": "/var/log/back-long/repo"
}
}
}Then:
curl -XPUT 'http://localhost:9200/_snapshot/my_backup' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/var/log/back-long/repo",
"compress": true
}
}'And result is:
{"acknowledged":true}Can you forward me to the right code?
While you can use the snapshot API to make snapshots, it can be easier in Curator. See the snapshot action documentation.
There is also an example configuration file.
I found it. I have written:
PUT /_snapshot/my_backup/snapshot-number-one?wait_for_completion=trueAnd got:
{
"snapshot": {
"snapshot": "snapshot-number-one",
"uuid": "fsCaA1ZTSCWgvSMO7Ukz7A",
"version_id": 5040199,
"version": "5.4.1",
"indices": [
"index_name-2017.10.02",
"index_name-2017.10.03",
"server2-2017.08.28",
"beat-2017.10.02",
"server1-2017.09.01",
"server1-2017.08.28",
".kibana",
"beat-2017.10.03"
],
"state": "SUCCESS",
"start_time": "2017-10-10T16:04:56.216Z",
"start_time_in_millis": 1507651496216,
"end_time": "2017-10-10T16:04:59.461Z",
"end_time_in_millis": 1507651499461,
"duration_in_millis": 3245,
"failures": [],
"shards": {
"total": 36,
"failed": 0,
"successful": 36
}
}
}And the content of the "repo" directory is:
[root@localhost repo]# ls
index-0 indices snap-fsCaA1ZTSCWgvSMO7Ukz7A.dat
index.latest meta-fsCaA1ZTSCWgvSMO7Ukz7A.datIs it OK?
Yes. Here's why:
Thank you. I created an archive from the directory and want to delete all data and restore it. Which command remove all indexes?
What does that mean? I'm not sure what you are talking about.
I want to delete the indexes and restore it on another server.
I did "curl -XDELETE 'http://localhost:9200/_all'" and I guess this command delete all indexes. I created a directory with the name "myback" under "/home/elastic/" and move archive file to there and extract it:
[root@localhost myback]# tar -tf my-data.tar
var/log/back-long/repo/
var/log/back-long/repo/meta-fsCaA1ZTSCWgvSMO7Ukz7A.dat
var/log/back-long/repo/indices/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/meta-fsCaA1ZTSCWgvSMO7Ukz7A.dat
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/2/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/2/__0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/2/snap-fsCaA1ZTSCWgvSMO7Ukz7A.dat
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/2/index-0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/3/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/3/__0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/3/snap-fsCaA1ZTSCWgvSMO7Ukz7A.dat
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/3/index-0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/4/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/4/__0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/4/snap-fsCaA1ZTSCWgvSMO7Ukz7A.dat
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/4/index-0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/__0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/__1
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/__2
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/__3
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/snap-fsCaA1ZTSCWgvSMO7Ukz7A.dat
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/0/index-0
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/1/
var/log/back-long/repo/indices/plOVySQlQuGucWeH0EhMhA/1/__0
...then I changed the owner of directory to "elasticsearch":
drwxr-xr-x. 2 elasticsearch elasticsearch 24 Oct 11 15:35 mybackAfter it, I opened the "elasticsearch.yml" file and added below line:
path.repo: ["/home/elastic/myback/"]Then I restart "elasticsearch" service, But I got an error:
Caused by: java.nio.file.AccessDeniedException: /home/elastic/myback
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:1.8.0_131]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:1.8.0_131]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:1.8.0_131]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:1.8.0_131]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:1.8.0_131]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:1.8.0_131]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:1.8.0_131]
at org.elasticsearch.bootstrap.Security.ensureDirectoryExists(Security.java:455) ~[elasticsearch-5.4.1.jar:5.4.1]
at org.elasticsearch.bootstrap.Security.addPath(Security.java:411) ~[elasticsearch-5.4.1.jar:5.4.1]
at org.elasticsearch.bootstrap.Security.addFilePermissions(Security.java:296) ~[elasticsearch-5.4.1.jar:5.4.1]
at org.elasticsearch.bootstrap.Security.createPermissions(Security.java:224) ~[elasticsearch-5.4.1.jar:5.4.1]
Why?
This is not how this works. Snapshot and Restore are not archives in the traditional sense. You performed a snapshot, now to get the data back, you need to perform a restore. You cannot move files from a snapshot to another physical machine and expect Elasticsearch to just magically read them due to the metadata, node count, and several other conditions that cannot be predicted in a new, target cluster. Restore just pulls the shards out and creates new indices from the segments in the repository (the target index will have the same number of shards as the source at snapshot time).
What this also means is that the cluster you're trying to restore to must also have read/write access to the shared filesystem defined in path.repo. This should not be an issue if you're restoring to the same cluster the snapshots came from.
I know that for restore it I need some commands. I created a directory and put backup on it for execute the next steps but as you see I got an error about permission. The directory name is myback and as you see elasticsearch has permission but it show me an error.
How to solve it?
Thank you.
What is your opinion?
You have to create the exact same repository on both the source and target clusters. If they're the same, then you only need to issue the restore API call (or the restore action in Curator). The rest is just filling in the necessary bits as required by the API call (or action).
Same location? What does it mean? For example, If on server 1 my backup located at "/var/log/back" then on server 2 for restore it I must create a directory with the name "back" under "/var/log" ?
Both clusters must have the same repository configured using the exact same shared file path (i.e., both clusters need access to the same shared filesystem, and should have the same options configured).
Once the repository is configured, it's roughly the same process as performing a snapshot. You specify the repository, not a path, and the snapshot you want to restore (and optionally, any indices you want to restore, or if not specified, all).
To be more clear, you need to do this on both clusters, and both must have access to /var/log/back-long/repo: