# DEPLOY ELK STACK (with eck) using CLONED DISKS **URL:** \ **Category:** Elasticsearch\ **Created:** [January 23, 2023, 3:30pm UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744 "2023-01-23T15:30:07Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Maria\_Gabriela\_Perez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maria_gabriela_perez/32/100571_2.png) [@Maria\_Gabriela\_Perez](https://discuss.elastic.co/u/Maria_Gabriela_Perez)\ **Post date:** [January 23, 2023, 3:30pm UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/1 "2023-01-23T15:30:07Z")
Is it possible to deploy on kubernetes (gke) a new copy of elasticsearch using cloned disks from another elasticsearch deployment in another cluster, without conflicts? Any workarounds ?.. I need to restore logs saved in those disks, so any path besides the one I'm talking about would be helpful and appreciated too. ---
**Author:** ![Ayush\_Mathur](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ayush_mathur/32/77134_2.png) [@Ayush\_Mathur](https://discuss.elastic.co/u/Ayush_Mathur)\ **Post date:** [January 23, 2023, 4:28pm UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/2 "2023-01-23T16:28:51Z")
Hello @Maria_Gabriela_Perez , I believe it's not possible to do what you want to achieve without conflicts or issues. The reason being, ES essentially stores all the cluster and node information on the underlying volumes mounted to it. So if you attach the same volume to another ES node, it will try to join the existing or old cluster with same specs as your older node has - leading to conflict definitely. Instead, if you just want to move logs from one cluster to another, there are few options: 1. Since you are interested in disk based movements, you can copy the indices directory under ${path.data}/nodes/0/ from old node to new node (assuming it's already running on separate cluster). 2. Create a snapshot of required indices from 1st cluster and restore the indices in new cluster. 3. Configure CCR between 2 clusters and assign the index to be followed. ---
**Author:** ![Maria\_Gabriela\_Perez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maria_gabriela_perez/32/100571_2.png) [@Maria\_Gabriela\_Perez](https://discuss.elastic.co/u/Maria_Gabriela_Perez)\ **Post date:** [January 24, 2023, 2:05am UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/3 "2023-01-24T02:05:45Z")
I tried this, the service crashed completely, those are index right?, what about the folder containing only saved logs (from filebeats) ??, which path should I copy? ---
**Author:** ![Ayush\_Mathur](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ayush_mathur/32/77134_2.png) [@Ayush\_Mathur](https://discuss.elastic.co/u/Ayush_Mathur)\ **Post date:** [January 24, 2023, 4:26pm UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/4 "2023-01-24T16:26:31Z")
> [@Maria\_Gabriela\_Perez](#): > > folder containing only saved logs (from filebeats) ?? filebeat doesn't save any logs, those are essentially pushed and stored in Elasticsearch as indices. What exactly have you tried ? ---
**Author:** ![Maria\_Gabriela\_Perez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maria_gabriela_perez/32/100571_2.png) [@Maria\_Gabriela\_Perez](https://discuss.elastic.co/u/Maria_Gabriela_Perez)\ **Post date:** [January 24, 2023, 6:25pm UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/6 "2023-01-24T18:25:21Z")
cp entire 0 folder as you mentioned.. but apparently there's something in there that belongs to the other cluster, so kibana pods crashes, and when I restart elasticsearch pods, those crash too. I kinda figured that out recently, I didn't understand how logs were stored in the elasticsearch folders. Restoring Snapshots are just so slow, and it's giving me too many internal server errors with no further explanation, we have tons of objects to migrate and doing it by hand it's taking way too long. ---
**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 24, 2023, 6:39pm UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/7 "2023-01-24T18:39:26Z")
Cloning disks or copying data at the file system level may have worked in very old versions of Elasticsearch, but that is no longer the case. In order to move data from one cluster to another you either need to use snapshot and restore or reindex the data from remote. ---
**Author:** ![Ayush\_Mathur](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ayush_mathur/32/77134_2.png) [@Ayush\_Mathur](https://discuss.elastic.co/u/Ayush_Mathur)\ **Post date:** [January 25, 2023, 7:28am UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/8 "2023-01-25T07:28:17Z")
You may want to pace up the shnapshot/ restore process by updating settings of your repository. For instance, if S3 is being used, there are some properties defined here: [S3 repository | Elasticsearch Guide [8.6] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/repository-s3.html#repository-s3-repository) Also, there are some properties that can be defined to pace up shard initialization as posted in this thread: [Snapshot restore is very slow to get started - #7 by Guilherme\_Vieira](https://discuss.elastic.co/t/snapshot-restore-is-very-slow-to-get-started/225840/7) and here: [Snapshot is taking too long](https://discuss.elastic.co/t/snapshot-is-taking-too-long/218262) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [February 22, 2023, 7:28am UTC](https://discuss.elastic.co/t/deploy-elk-stack-with-eck-using-cloned-disks/323744/9 "2023-02-22T07:28:49Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.