3 ms·
With something as simple as serving git for your own organisation, when you do get downtime it's going to be a case of restoring from backup and changing DNS. N
by ghusto 5y ago
With something as simple as serving git for your own organisation, when you do get downtime it's going to be a case of restoring from backup and changing DNS. No need for complicated infrastructure, so bringing it back really is that simple.
Worst case is losing commits between going down and backups, but even then it'll be minimal if you set your backup to simply push to a another origin.
I pay for someone else to worry about most services, but git doesn't have to be one of them.
- munificent 5y agoThe worst case is discovering the hard way that your backup system isn't working and you haven't been diligent about spending the time to periodically test restores.
- ghusto 5y agoPushing to multiple origins is not a hard thing.
- munificent 5y agoThe risk is less about losing commits, since those tend to live on every devs machines too. It's about losing all of the other data like the issue tracker, comments, etc.
- dspillett 5y agoThat's why testing of backups should be at least partially automated. Though you will always find a point where the automation, and automated tests to make sure that is working, and so on, get to the point where making a human responsible for sanity checking is most resource effective.
- thefreeman 5y agoIf you think "serving git" is the only role github is serving for organizations you are probably not the target audience.
- ghusto 5y agoI don't. Which is why I was explicit in the problem I'm targeting.