[feature request]copy_index api(reindex with file copy not doc insert)

[riverbuilding]

use case: copy old index as a backup to support rollback and then update the original index to move forward in the same cluster.

ES provide re-index API which can be used to copy index with many flexibility like schema change, doc filter etc.
although with many limitations, from performance side, the file copy method is much fast than reindex, especially when index size is big.

API:

POST _copyindex
{
"source": {
"index": "twitter"

},
"dest": {
"index": "new_twitter"
"replica": Number//must eq or less than orginal index replica, otherwise, fail request
}
}

it's really like snapshot-restore process only repository is ES itself

[elasticmachine]

Pinging @elastic/es-distributed

[original-brownbear]

@riverbuilding just to understand this feature request better:

Your motivation is to effectively have ES be the repository instead of using another repository implementation to save the complexity of setting up a repository?

[ywelsch]

As far as I understand, this could be the index split functionality with the additional option of keeping the number of primary shards the same in the target index.

[riverbuilding]

@ywelsch split is really what I need in this situation. thanks a lot.

[riverbuilding]

@ywelsch I'd like to ask: when split index, can the "can't select recover from shards if both indices have the same number of shards" be omit? I mean, can the target index be set the same shard number with the original index?

[ywelsch]

Right now, it can't. If we were to allow this, I would rather prefer to expose it via a new endpoint _clone than enable this on _split.

[elasticmachine]

Pinging @elastic/es-core-features