Additional info:

• kasten version: 4.5.10
• kubernetes version: 1.20.11
• vsphere CSI version: 2.3.1

Hello @shushu !

Did you specify an additional location profile for the metadata/application specification in your Policy?

As described in the documentation (here):

Only snapshot data is saved in the Veeam Backup Repository. The remaining data associated with the K10 restore point is saved in the location profile identified by the profile field of the exportParameters

Currently, only snapshot data (actual PV/PVC data/content) can be saved in a Veeam Backup Respository.

You still need another Location Profile to store the actual specifications/details of the application, like the Deployments/StatefullSets/Pods/Services/etc.

I hope it helps!

Best regards,

Sylvain Huguet.

Hi @shuguet !

Thanks for the detailed answer.

You still need another Location Profile to store the actual specifications/details of the application, like the Deployments/StatefullSets/Pods/Services/etc.

How was I able to fully restore in the same cluster the backed up applications (statefulsets, services and deployments ) + the pv/pvcs ?

Does Kasten store the k8s resources somewhere else (locally in the cluster) in my case ?

Indeed we do!

When you setup a Policy without an Export, we take local snapshots (for the PV/PVC), and we also store a copy of the metadata (a representation of the Kubernetes objects definitions) into our backup catalog (which is, itself, a volume attached to one of the pods that K10 deploys during the installation).

To persist those data, you need to enable the “Export” part of the policy, so that everything (data + metadata) is exported.

In the case of VBR as your target location for export, only data will be exported there, and you need another location for the metadata parts.

Best regards,

Sylvain Huguet.

Thanks @shuguet !

I tried to export and import only PVCs:

• I have created a policy that snapshots and exports only the PVCs.
• Running the policy resulted in a success.

But, when I try to import the PVCs in a new cluster I still get the error:

cause:
  cause:
    cause:
      cause:
        cause:
          cause:
            cause:
              fields:
                - name: type
                  value: VBR
              file: kasten.io/k10/kio/kopia/profile.go:140
              function: kasten.io/k10/kio/kopia.(*K10Profile).locationType
              linenumber: 140
              message: Unsupported type for the location
            file: kasten.io/k10/kio/kopia/repository.go:327
            function: kasten.io/k10/kio/kopia.repositoryConnectCommand
            linenumber: 327
            message: Failed to generate blob store args
          file: kasten.io/k10/kio/kopia/repository.go:507
          function: kasten.io/k10/kio/kopia.ConnectToKopiaRepository
          linenumber: 507
          message: Failed to generate repository connect command
        file: kasten.io/k10/kio/kopiaapiserver/api_server.go:365
        function: kasten.io/k10/kio/kopiaapiserver.setupAPIServerForCollectionImport
        linenumber: 365
        message: Failed to connect to collections Kopia repository
      file: kasten.io/k10/kio/kopiaapiserver/api_server.go:315
      function: kasten.io/k10/kio/kopiaapiserver.SetupAPIServerForCollectionImport
      linenumber: 315
      message: Failed to initialize Kopia API server
    file: kasten.io/k10/kio/exec/phases/phase/migrate.go:652
    function: kasten.io/k10/kio/exec/phases/phase.importDataFromKopiaCollection
    linenumber: 652
    message: Failed to prepare Kopia API server for migration
  file: kasten.io/k10/kio/exec/phases/phase/migrate.go:503
  function: kasten.io/k10/kio/exec/phases/phase.importUsingKopia
  linenumber: 503
  message: Failed to import collection from kopia repository
message: Job failed to be executed
fields: o]
 

Why is that ? Now its only PVCs I try to restore.

when creating the import policy I get the following warning:

Its the same profiles in both clusters.

You still need both Location Profiles, even if you’re “just” exporting PV/PVCs… because a PV/PVC itself is composed of 2 parts, the PV/PVC “metadata” (the specs of the objects) and the actual data in the volume.

So in order to import a PV, we need to first re-construct its “representation” in the target Kubernetes cluster. In other words, we need to tell the target Kubernetes cluster what the PV “looks like” and where it can find its data, before we can import/restore the actual data.

If you are familiar with virtualisation & VMware, it’s like trying to restore “just” a *-flat.vmdk file, without having access to the actual .vmdk descriptor file that describes it. (Ignore this if you’re not familiar with VMDK file format/structure, it would just confuse you, but leaving this here for others it could help).

Best regards,

Sylvain Huguet.