Hi,
Can you clarify the end-goal here so we can work back on what’s the best way to achieve this?
Would it be that you wish to create an immediate clone of your application, potentially as a dev/test space? Or for recovery validation efforts etc? On your same cluster “a”?
You can leverage transforms in the restore to change namespaces for example.
https://docs.kasten.io/latest/api/transforms.html?highlight=transforms
So for example restore to namespace = nginx_restored
my only question would be about the pv’s but I believe you can transform those as well to duplicate, and of course you can change the storageClass through a transform as well.
@seb2020 Thanks for posting the question.
The import is not required to be done in the same cluster(it would fail even if you do).
Import operation is designed to import the restorepoints in a secondary cluster(cluster “b”).
However, you will already have that restorepoint in the primary cluster(cluster “a” in your case) and you can use that to restore your application.
Thank for the information. I understand now with your comment @jaiganeshjk
@MicoolPaul The main goal is to backup some namespace (4-5 namespaces) with a policy and then restore all the namespace with the policy (run the policy and all namespaces are restored) instead going to applications, select each namespace and restore them.
