# Architecting a Decentralized GitHub Backup

**URL:** <https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279>\
**Category:** Developer Discussions\
**Created:** [October 18, 2019, 10:50pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279 "2019-10-18T22:50:30Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [October 18, 2019, 10:50pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/1 "2019-10-18T22:50:30Z")

</div>

> **[Architecting a Decentralized GitHub Backup](https://storj.io/blog/2019/10/architecting-a-decentralized-github-backup/)**
>
> GitBackup is a tool that backs up and archives GitHub repositories. The tool is in the process of backing up the entirety of GitHub onto the Storj network, which currently stands at 1-2 PB of data. As of today, October 18, 2019, the tool has...

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [October 18, 2019, 10:50pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/2 "2019-10-18T22:50:56Z")

</div>



---

<div class="post-metadata">

**Author:** ![peem](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/peem/32/6323_2.png) [@peem](https://forum.storj.io/u/peem)\
**Post date:** [October 19, 2019, 3:27am UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/3 "2019-10-19T03:27:46Z")

</div>

Great idea, congratulations

the next one should be “[registry-1.docker.io](http://registry-1.docker.io)”, because often “timeout”

---

<div class="post-metadata">

**Author:** ![kevink](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kevink/32/6077_2.png) [@kevink](https://forum.storj.io/u/kevink)\
**Post date:** [October 19, 2019, 5:33am UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/4 "2019-10-19T05:33:08Z")

</div>

It’s a great idea but storj is not a truly decentralized and independent platform either. If the operators of a satellite decides to shut it down, all data stored using that satellite is lost. Therefore storing data on STORJ also has a single point of failure (the operator of a satellite), who is also either an individual or an agenda/profit driven organisation, just like github itself.  
So while the idea is nice, it is not like the github backup will be available on the network forever without any possibility to shut the backup down, since you only need to shut down the satellite operator.

If I got that wrong, please correct me.

---

<div class="post-metadata">

**Author:** ![peem](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/peem/32/6323_2.png) [@peem](https://forum.storj.io/u/peem)\
**Post date:** [October 19, 2019, 12:25pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/5 "2019-10-19T12:25:27Z")

</div>

na razie jest tak jak opisujesz, ale wszystko jest jeszcze w budowie i może kiedyś doczekamy prawdziwej decentralizacji…

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [October 19, 2019, 12:27pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/6 "2019-10-19T12:27:56Z")

</div>

You will be able to use an own satellite to store files on the network after the launch to the production.

---

<div class="post-metadata">

**Author:** ![kevink](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kevink/32/6077_2.png) [@kevink](https://forum.storj.io/u/kevink)\
**Post date:** [October 19, 2019, 12:38pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/7 "2019-10-19T12:38:11Z")

</div>

I understand that but it still makes me the single point of failure. If I decide to shut it down, the data will be lost for everyone. It is basically the same as one person/organization running multiple datacenters hosting their data. One person/organization is in complete control of the data.  
So if the goal is to make the github backup available to everyone “forever”, then the risk is high that this single point of failure (the satellite operator) might decide (or be forced) to shut down his satellite, making all data unavailable.  
But that is only looking at one technical aspect because no matter how it is implemented, someone will have to pay for the data being stored and therefore there’s a probably even bigger point of failure. As soon as nobody pays for the data anymore, it will get deleted anyway.

---

<div class="post-metadata">

**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\
**Post date:** [October 19, 2019, 7:25pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/8 "2019-10-19T19:25:12Z")

</div>

> [@Alexey](#):
>
> You will be able to use an own satellite

Sure, but that’s not really within reach for everyone. And it would also create another copy on the network, which is not really necessary with the protections already in place.  
This would be a very good use case for some federation system between satellites, so that the data could be accessible through multiple satellites.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [October 20, 2019, 7:59pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/9 "2019-10-20T19:59:11Z")

</div>

Is there separate payments for satelite providers, what are requaerments?

---

<div class="post-metadata">

**Author:** ![kevink](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kevink/32/6077_2.png) [@kevink](https://forum.storj.io/u/kevink)\
**Post date:** [October 20, 2019, 8:01pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/10 "2019-10-20T20:01:03Z")

</div>

Off-topic, please create a new thread

---

<div class="post-metadata">

**Author:** ![Knowledge](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/knowledge/32/10681_2.png) [@Knowledge](https://forum.storj.io/u/Knowledge)\
**Post date:** [October 28, 2019, 6:48pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/11 "2019-10-28T18:48:00Z")

</div>

There is risk. Is the risk high? Probably not higher than the technology design being new and prone to undiscovered weaknesses. That being said, if you are able to operate your own satellite and thus, satellites, you will have the ability to create needed redundancy as you see fit. Is that ideal? Perhaps not, and commercial entities may also exist to make the process easier, as things continue.

You also have to remember, we’re early days here, and not everything we want is going to be ready at launch. For a small company, the milestones achieved are significant. And these problems will eventually be solved.

---

<div class="post-metadata">

**Author:** ![kevink](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kevink/32/6077_2.png) [@kevink](https://forum.storj.io/u/kevink)\
**Post date:** [October 28, 2019, 6:55pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/12 "2019-10-28T18:55:10Z")

</div>

Don’t get me wrong, STORJ is great and it is designed as a different approach to datacenters. And in that way having a company run a satellite is just fine.

Only when it comes to the goal of storing data decentralized to preserve it “for eternity” so that it will always be accssible for everyone, then the concept of STORJ is unsuitable because you have the single point of failure which is the satellite operator. Nobody can say if the organization or individual behind/in control of a satellite will still run that satellite in 20 years while a truly decentralized network could easily survive 100 years if enough participants stay.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [October 28, 2019, 6:56pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/13 "2019-10-28T18:56:45Z")

</div>

Does satelits stor only own information or they sync all databases?  
Beause if Satelite hold only own information this is botle neck, and if satelite die, all data will die with it, as will be no access to it.

---

<div class="post-metadata">

**Author:** ![Knowledge](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/knowledge/32/10681_2.png) [@Knowledge](https://forum.storj.io/u/Knowledge)\
**Post date:** [October 28, 2019, 7:47pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/14 "2019-10-28T19:47:58Z")

</div>

It depends on how you view it. Let’s say I am using Microsoft Azure. If I want to store data on their servers with local redundancy, I pay a low fee. If I want to store data with zone or geographic redundancy, I pay larger fees. Storj can do this as well. You can store your data on one or more satellites. It just depends on your cost factors and your need to have data be redundant.

This, of course, would require tools to make this kind of redundancy happen, otherwise you would have to upload the files multiple times to different satellites. Ideally, businesses that leverage Storj will create such tools.

---

<div class="post-metadata">

**Author:** ![kevink](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kevink/32/6077_2.png) [@kevink](https://forum.storj.io/u/kevink)\
**Post date:** [October 28, 2019, 9:26pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/15 "2019-10-28T21:26:30Z")

</div>

That’s true. There are possibilities to store data even more redundant so it doesn’t depend on one satellite. A little besides the point of having a decentralized network that is already storing all the data safely and redundantly but the possibility is there.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [October 29, 2019, 10:32pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/16 "2019-10-29T22:32:44Z")

</div>

StorJ have redundensy on data, but do you have redundensy on Satelite?  
if satelite server raid go creasy it will wipe out all data include operation system, i seen that hapened.  
Backup will save situation but not fuly as backups are once a day or twice, bud data between are lot of gigabytes.

---

<div class="post-metadata">

**Author:** ![keleffew](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/keleffew/32/7149_2.png) [@keleffew](https://forum.storj.io/u/keleffew)\
**Post date:** [October 29, 2019, 11:53pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/17 "2019-10-29T23:53:28Z")

</div>

The satellite peer class is designed to perform more intensive operations (like audit, data repair, node reputation, and billing & payments. The peer class is designed to be run over a cluster of high availability servers and distributed across many regions. The only single point of failure is that you have to trust the entity who runs them (however you are always open to run one yourself).

As mentioned, anyone can run a Satellite on the Storj network. Providers might want to operate Satellite as a service, or a company may want to run their own Satellite to build their own decentralized cloud storage network.There are likely many other reasons someone may choose to operate their own Satellite. Due to this, we expect there to be a large variation in quality.

Over time, the idea is to offload these functions into the network itself, or to decentralized compute networks over time as such solutions emerge. We are working on releasing a roadmap that details the pathway to decentralizing the core functions of the satellite.

As defined in whitepaper, the Satellite instance is made up of these components:  
• A full node discovery cache (section 4.6)  
• A per-object metadata database indexed by encrypted path (section 4.9)  
• An account management and authorization system (section 4.12)  
• A storage node reputation, statistics, and auditing system (section 4.13)  
• A data repair service (section 4.14)  
• A storage node payment service (section 4.16)

Our primary focus is building a permissionless, decentralized network that competes with Amazon S3 on Price, Performance, and Security.

The satellite trust boundary enables the network to achieve millisecond response time amongst a globally distributed network of untrusted storage nodes. Storage nodes may connect to multiple satellites and must trust their operators for gathering paid demand, and performing billing and payment function

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [October 30, 2019, 8:00am UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/18 "2019-10-30T08:00:27Z")

</div>

If satellite operator uses the cloud services to run a satellite, (s)he can configure satellite services as a docker containers and run them in the Kubernetes or docker Swarm.

The DB service usually rented from the cloud provider as well. In the last case you have snapshots as for a whole service and for the database. So, you can recover the DB almost on the same time as time of failure. But usually the DB service is configured with at least a standby replica, so there is no downtime at all and no data lost. Probability to get down both replica in a different access zones is very low.

This is just a best practice to operate a high load production services. I doubt that Storj Labs could not follow it.

---

<div class="post-metadata">

**Author:** ![jocelyn](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jocelyn/32/31_2.png) [@jocelyn](https://forum.storj.io/u/jocelyn)\
**Post date:** [February 24, 2020, 8:52pm UTC](https://forum.storj.io/t/architecting-a-decentralized-github-backup/2279/19 "2020-02-24T20:52:19Z")

</div>

its alive!

> [@Check out GitBackup to sync your GitHub account!](https://forum.storj.io/t/check-out-gitbackup-to-sync-your-github-account/4872):
>
> Received a message for our own amazing @monty in engineering and has to share: hey Jocelyn! nothing crazy yet, but if you give users this link https://gitbackup.org/?login-enabled=true, then they can login to gitbackup through github and their accounts will be synced every morning! Im going to drop this link in as a cross post on some previous discussions around GitBack, but I also thought it deserves its own thread. If you do try it out, please report back and letus know what you think. Th…
