Error restoring cluster: scope 'scope1' with id 0x8 exists with a different name/id on the cluster, a manual remap using '--map-data' is required

Error restoring cluster: scope ‘eventing’ with id 0x8 exists with a different name/id on the cluster, a manual remap using ‘–map-data’ is required

there is bucket1 we have with data, indexes we are restoring from other cluster.
bucket1 have scope1 and collection1 is there. while we are doing restore only for indexes we are facing this error.

i could not understnd what done wrong here.

cbbackupmgr restore -u Admin -p pass -a path -r repo -c [ip]:8091 --include-data bucket1 --disable-data.

inside that collection1 we are saving eventing services output. there is no indexes also there for that scope and collection.
have done below one as well but it is not helping

eg :

1. --map-data bucket1._default.collection1=bucket1._default.collection1
2. --map-data bucket1.scope1.collection1=bucket1.scope1.collection1

both the eg are not worked for me.

i just dropped that collection and triggered the same index restore --disable-data this time it has worked and also it has created dropped collection in previous step with data, this behaviour we could not able to understand totally.

Using the --map-data flag with the argument bucket._default.collection1=bucket._default.collection1 would cause cbbackupmgr to treat collection1 (with id 8) as collection1 (with the id it exists with in the target).

REMAPPING A SCOPE/COLLECTION WITHOUT RENAMING

Error restoring cluster: scope ‘eventing’

It’s complaining about the scope ‘eventing’, not scope1. Using --include-data to include only scope1 (and _default if desired) should avoid that, but that is an Enterprise feature. cbbackupmgr restore | Couchbase Docs
If you are using Community, then I suppose you would also need to --map-data that scope.

yesh @mreiche that’s correct we are using evening is scope and plan_mgmt is collection in my env. i just represent it here as scope1 and collection1.

and that option is there, thank you much for letting me know. but what we need to do while we are getting this error when we are restoring all the scopes and collections in a bucket?

From the message - the scope that it finds - even though it has the same name - is not the same scope. This would be the case if it was deleted and recreated. The behavior is to prevent the accidental restoring on to the wrong scope.

It’s like if you went to pickup your kid from school - just picking up a kid with the same name is not the intention.