# Connecting to repo with different storage type

**URL:** <https://kopia.discourse.group/t/connecting-to-repo-with-different-storage-type/2888>\
**Category:** Support\
**Created:** [May 8, 2024, 9:26pm UTC](https://kopia.discourse.group/t/connecting-to-repo-with-different-storage-type/2888 "2024-05-08T21:26:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![nolan](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@nolan](https://kopia.discourse.group/u/nolan)\
**Post date:** [May 8, 2024, 9:26pm UTC](https://kopia.discourse.group/t/connecting-to-repo-with-different-storage-type/2888/1 "2024-05-08T21:26:17Z")

</div>

Hey folks, I hope this is possible. I used Velero to back up a k8s home lab, which uses kopia under the hood. Unfortunately velero is refusing to connect to remote storage and sync its list of snapshots, so I’m abandoning it. Possibly (hopefully) fortunately, I can get at the underlying kopia repo and have downloaded it locally, so my hope is that I can get at these files somehow. Here’s what I know, what my challenges are, and what I’ve tried.

- Fortunately encryption shouldn’t be an issue since [velero uses a hard-coded password for all repos](https://github.com/vmware-tanzu/velero/blob/main/pkg/repository/keys/keys.go#L36).
- I stored the repo on b2, but I don’t think velero supports b2 natively, so I configured the storage as s3 and used the s3 plugin. Maybe something changed in velero/its kopia integration which is why things are broken now?

In any case, I made a b2 snapshot of the repo, downloaded it, and ran:

```bash
core@lab:~$ kopia repo connect filesystem --path ~/kopia/vm                                                        
Enter password to open repository:                                                                                 
                                                                                                                   
ERROR error connecting to repository: repository not initialized in the provided storage                           

```

I then tried the same with b2 and got the same results, I suspect because the velero s3 plugin used the s3 type instead. So then I tried passing in similar connection parameters to how I use the velero s3 integration:

```bash
core@lab:~$ kopia repo connect s3 --access-key "nope" --secret-access-key "nope" --bucket nolan-lab --endpoint "s3.us-west-001.backblazeb2.com"                                      
ERROR can't connect to storage: error retrieving storage config from bucket "nolan-lab": Malformed Access Key Id   

```

Notably, I used the same b2 access key I used when testing against b2, so I’m pretty sure the creds are right. Any idea where this message might be coming from?

Any thoughts on how I can access this repo, how to confirm what storage location it was created with, etc.? If all else fails, I guess I can launch a minio instance and use that to fake an s3 connection, but hopefully there’s another way.

Thanks.

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [May 9, 2024, 10:14pm UTC](https://kopia.discourse.group/t/connecting-to-repo-with-different-storage-type/2888/2 "2024-05-09T22:14:54Z")

</div>

> [@nolan](#):
>
> ```auto
> core@lab:~$ kopia repo connect filesystem --path ~/kopia/vm                                                        
> Enter password to open repository:                                                                                 
>                                                                                                                    
> ERROR error connecting to repository: repository not initialized in the provided storage                           
> 
> ```

What’s inside `~/kopia/vm`? Do you see a `kopia.repository.f` file?

> [@nolan](#):
>
> Notably, I used the same b2 access key I used when testing against b2, so I’m pretty sure the creds are right. Any idea where this message might be coming from?

Unfortunately I can’t help with B2 as I’ve never used it but [this thread on reddit](https://www.reddit.com/r/backblaze/comments/u9ivrh/malformed_access_key_id/) suggests generating new keys.

---

<div class="post-metadata">

**Author:** ![nolan](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@nolan](https://kopia.discourse.group/u/nolan)\
**Post date:** [May 10, 2024, 12:14pm UTC](https://kopia.discourse.group/t/connecting-to-repo-with-different-storage-type/2888/3 "2024-05-10T12:14:52Z")

</div>

> [@dimejo](#):
>
> What’s inside `~/kopia/vm`? Do you see a `kopia.repository.f` file?

kopia.repository yes, but not kopia.repository.f. Same with all 3 repos I checked.

---

<div class="post-metadata">

**Author:** ![nolan](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@nolan](https://kopia.discourse.group/u/nolan)\
**Post date:** [May 10, 2024, 4:40pm UTC](https://kopia.discourse.group/t/connecting-to-repo-with-different-storage-type/2888/4 "2024-05-10T16:40:56Z")

</div>

Update: Got it, thanks to [this post](https://cloudcasa.io/blog/how-to-restore-velero-backup-data-without-velero/). Turns out I needed both --prefix and --region. With those, I was able to mount the repo directly–no need to access it through the copy. Maybe it’d have worked over b2 with a prefix too, but I just stuck with the format I used to create it to be safe.

Thanks.
