For the common-case risk model in the post body (SaaS user), the easy option is to set up a secondary git remote over SSH on a cheap cloud VPS. Then you can simply run git push backup-server or the like. Bonus points for setting up a cronjob to push to your backup box periodically, or to take periodic tarball snapshots of the repos on the server.

Personally though: I self-host forgejo with registration disabled, and take automated snapshots with ZFS occasionally in case I truly bork things.

I switched off of GitHub to my own Forgejo instance. It’s been great. I still mirror to GitHub just in case, but my Forgejo instance has had much better uptime than GitHub. xD

If you have a repo cloned locally and hosted on the remote, then you have the repo saved to two different places (although possibly without all the refs locally but you likely have your main/dev/etc branch at least).

What I've been wanting to do once I get my NAS working again is host the repos on that instead. You can make a mirror of a repository very easily, so if you want to mirror a GitHub repo onto another service or a NAS or something (or the other way around, NAS -> GH for example), it's really only a couple commands to fully back it up, and you could just put that in a cron job or hook.

Ok, hold on. How to "back up an organization's source control?" Are you saying the organization in question has a source control hosting solution of some sort and needs to implement a backup strategy for the contents of said source control solution?

Or are you saying the organization doesn't have a source control solution and they need a source control solution.

The former question is an entirely reasonable sort of question to ask. (Not one I have much expertise on, but still a legitimate question.) If your question is the latter, let me say: source control is not a backup solution and conflating the two is a mistake.

I once talked to the guy in charge of another team at a company where I was working. We'll call him Nick (because that was his name). I found out that Nick had instituted a policy wherein each developer on the team under him had their own dedicated branch in Git to which they were required to commit/push at the end of every day no matter what state their code was in. main was to be merged into these developer branches regularly (the only sane part of the whole scheme) and the developer branches would be merged into main with PRs which had to be reviewed personally by him. Then, if something went wrong and they lost work, they couldn't lose more than a day's worth of work (because at the end of the day yesterday, they'd pushed their code) -- or so the "logic" went. Nick was a terrible person. Don't be like Nick. (His whole mindset was "we have to protect the codebase from these 'junior devs' so they don't ruin it! And we have to protect them from their own incompetence as well!" Weird guy. Definitely had a power-trip sort of complex.)

Commits are not a box you unceremoniously dump your code in so you can ship it off to put it in cold storage on the central Git repo backup server. They're something to be curated. Push only atomic commits. (That is, don't put multiple unrelated changes in a single commit. Also make sure that your commit covers the whole of a single, deliverable change.) Never knowingly push commits which put the code in a broken state or commits with half-completed changes. Strive for an ideal world in which any single commit in the central repo can be safely reverted without breaking other commits. When something is broken, your organization will thank you for not leaving a mess of interrelated and interdependent commits. And when one thing needs undone, they'll thank you for making sure that reverting a single commit will accomplish it. The structure and content of your Git history is an important part of the product just like comments and documentation. (And that segues nicely in to another point: Write good commit messages while you're at it.) There's nothing more satisfying than a clean commit graph with good commit messages.

(One qualifier here. What you do on your own dev machine is your own business. Make sure that what you push is well formed. How you get there, who cares. If your coding style involves "oh, while I'm here, I'll fix this unrelated thing", that's perfectly fine so long as when you push the unrelated things are in separate commit. Get familiar with git add -i and/or git add -p. And of course your team likely has requirements about things being committed under the correct topic branch and stuff. Those are good rules to follow as well.)

Hopefully you're getting what I mean by "source control is not a backup solution" at this point. Source control is for collaboration.

Personally, if I'm working on code that nobody but me is expected to touch anytime soon, I don't put it in Git. The source control I use is called "a directory". If I need to keep previous versions of the codebase, I copy the whole codebase into another directory. To protect against hard drive failure, I back it up to off-site storage.

I put it in Git when I publish it. Whether that be publishing to the world under a FOSS license or publishing it to my dev team at work in the central Git hosting solution we have where I work.

“Back up” is the verb and “backup” is the noun. I only bring this up because I’m constantly finding this problem in software written where I work too.

Personal Forgejo instance with "Github2Forgejo" running daily to automatically mirror repos. Then daily restic snapshot of Forgejo with off-site backup to Backblaze B2.

I’m wondering about corporate level without having on-premise resources.

You're necessarily, then, talking about paying for some other party to host resources at some other location(s). So the corporation needs to shop around for a deal for hosting web services.

Assuming the matter of hosting is taken care of, then, which service to run? In order to not be locked in to some proprietary provider, I would strongly recommend free-software community-maintained forge software. Something like Forgejo or Sourcehut.

I use local Gitea hosted on a pi cluster. I only push open source stuff I want to share to github. Most of my code does not push there anymore. No reason to give them training data without compensation.

My local gitea has its database and files on a NAS storage device, which encrypts and backs up to an AWS S3 bucket in another continent.

I am very interested in Lore source control because my projects are typically a mix of assets, not just code. I haven't switched to it yet though.