EDIT: For those unclear, we almost had to pull our backup of Source out of Glacier because someone deleted our local repository. We weren't expecting to need to set up permissions for things that should be assumed out of the box.
I am aghast at hearing you say this. Yes, of course you have to run backups. Like with everything else important on your systems.
Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source?
You don't have to spend 'hours' backing up a git repository. We typically use a bare git repo for the central point that is pushed to / pulled from by the individual developers. It is just a bunch of files, and so can be backed up easily.
You really don't sound like you know what you are doing.
I suggest you hire an experience system administrator (not just another devops) that understands the importance of backups.
- You have picked a new piece of technology
- You have no single person who understands it
- You expect it to work the same way the existing tech worked
- You don't have a backup system in place
- You imagine what the security settings should be for your specific use-case and then assume they are already in effect
- You switched to the new system before understanding it
I don't think software is the issue here.
[Edit: formatting]
It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.
What you must be talking about (well, I hope anyway) is the capability of a revision control system to be backed up on the fly, similar to the tools used to backup a live subversion repo without causing corruption. Git has such functionality; simply do a fetch from a remote repo, then backup the result.
If you're expecting revision control systems to include some sort of "backup suite", sorry, this is *NIX, not Microsoft. The tools do a particular job and it's up to you to plug that into your infrastructure, including your pre-existing backup infrastructure, which i'm sure your company must have. It would be laughable if they didn't have backup infrastructure already.
Well, you do have to give it a new disk first, right? Or do you expect the RAID-5 array to automate the process of purchasing and installing a replacement disk?
Git is distributed. The "backup"† is another dev doing a git push -f. Also, git reflog. The argument just does not hold water. (Also, do backup your VCS server anyway.)
If you want to keep rogue devs in check, set up a Gitlab instance, and use protected branches and merge requests.
† Read me correctly, it's not a backup, it's just part of the resiliency of git. Proper backups should be made il all cases.
[1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?
You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.
I've seen people attempt that before; without fail people who are deeply in centralized version control land and do not bother to understand git before attempting to switch to it (because it is trendy, or because people under them won't stop complaining about using svn in 2014).