# Has anyone performed a restore from Storj?

**URL:** <https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135>\
**Category:** General\
**Created:** [May 15, 2022, 6:18pm UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135 "2022-05-15T18:18:02Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mattzab](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/mattzab/32/276_2.png) [@mattzab](https://kopia.discourse.group/u/mattzab)\
**Post date:** [May 15, 2022, 6:18pm UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135/1 "2022-05-15T18:18:02Z")

</div>

I’m curious about this interesting decentralized storage system. Looks to be very cost effective with high redundancy.

If nobody has tried it, I’ll perform a backup/restore and see how the performance goes. I’ve only tried to use Google Drive to restore, which was so slow it was unusable. Basically GDrive isn’t set up for this kind of storage retrieval. S3 style buckets like B2 work better. Storj is a decentralized version of this.

My current process is to back up to GDrive since it’s free (B2 charges API calls).  
Storj might be a great alternative for basic backup/restore purposes.

I’ll report my findings.

---

<div class="post-metadata">

**Author:** ![gogolathome](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@gogolathome](https://kopia.discourse.group/u/gogolathome)\
**Post date:** [May 17, 2022, 9:30pm UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135/2 "2022-05-17T21:30:08Z")

</div>

I am very new to this since a week or so, but I use Google Drive Stream Files and it is superfast. The repository is on a local filesystem (mapped Google Drive).  
I also tested it with a repository on Google Drive mapped folder, but that was much slower with uploading so I abandoned that.

---

<div class="post-metadata">

**Author:** ![gogolathome](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@gogolathome](https://kopia.discourse.group/u/gogolathome)\
**Post date:** [May 17, 2022, 11:26pm UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135/4 "2022-05-17T23:26:29Z")

</div>

Yes we are talking about Google’s sync agent. It is using my maximum upload speed constantly so I am happy with that. I don’t know if it has more overhead than rclone.  
The sync agent and also the mapped Google Drive is using no more than 20% of the free space of my SSD system drive (windows and macOS)

---

<div class="post-metadata">

**Author:** ![gogolathome](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@gogolathome](https://kopia.discourse.group/u/gogolathome)\
**Post date:** [May 18, 2022, 5:01am UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135/6 "2022-05-18T05:01:00Z")

</div>

Not using the space is wasting space in my opinion; why not use it as a speed advantage? Snapshot is taken at ~10GB/min.  
Furthermore I make disk images with Macrium Reflect and Time Machine locally every day and recently I am using Kopia (I used Goodsync before) for my files in the cloud in case of a local disaster. I think is is a good strategy that works for me 😉

---

<div class="post-metadata">

**Author:** ![gogolathome](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@gogolathome](https://kopia.discourse.group/u/gogolathome)\
**Post date:** [May 18, 2022, 4:52pm UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135/8 "2022-05-18T16:52:35Z")

</div>

The idea of Google File Stream is that you keep everything in the cloud until it is locally needed. That is done in a cache directory. It is a one way sync, not a mirror. And the cache directory is much smaller than the repository directory, so not everything is on local disk.  
Google Drive App is much faster with uploading than Kopia and I trust this app until it goes wrong 😉 Should I trust Kopia more? I really don’t know. I should test more I guess by damaging the repository on purpose, maybe by deleting a file.

My images are all on separate disks.

---

<div class="post-metadata">

**Author:** ![gogolathome](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@gogolathome](https://kopia.discourse.group/u/gogolathome)\
**Post date:** [May 18, 2022, 11:24pm UTC](https://kopia.discourse.group/t/has-anyone-performed-a-restore-from-storj/1135/10 "2022-05-18T23:24:21Z")

</div>

> [@mattzab](#):
>
> Did you parallelize your upload? Do any benchmarks? I would think you could easily saturate your uplink with Kopia…

No, but Kopia doesn’t saturate my upload.

> [@mattzab](#):
>
> I don’t understand this at all. If you’re using Kopia to take snapshots but don’t trust it, why would the destination or upload method matter? If you’re using Kopia to snapshot something, plus the added layer of google stream, but you don’t trust Kopia, then why are you using Kopia as part of the process at all? How does the extra layer add any reliability to your solution if kopia is the untrustworthy component?
> 
> _“Fragility increases with complexity.”_

In my opinion I take the best of both worlds and there is no added complexity. Google Drive app is already running on my systems, Kopia is good at taking snapshots.  
For the upload Kopia uses Google API and I guess, not know, Google Drive App is a little more advanced. It is faster in my tests!  
But then again it is just my theory and could be proven wrong in the future or my opinion may change 🫢
