Just wanted to get an idea how often people are backing up their file store for Subversion and justification for frequency for your team.
feedback
|
migrated from stackoverflow.com Aug 5 '09 at 23:13
This question came from our site for professional and enthusiast programmers.
|
Daily. A cron job does all the work. | |||||||||||
feedback
|
|
Daily to another physical computer, and weekly off-site, just incase this building burns down, or some how gets destroyed. And just to boot, we mirror raid the drives. Nothings more important than the source code! | ||||
|
feedback
|
|
Daily, both to a separate disk on the svn server and to a remote server. It's easy and cheap to do backups. Why not do them frequently? | ||||
|
feedback
|
|
Daily backup and mirror synchronization. | ||||
feedback
|
|
After each check-in. For larger repositories, this may not be as practical. As a few others have pointed out, it's not enough to just daily backups. It's important to have regular offsite backups and read-only backups (offline is probably safest). The last thing you need is for a levee to break flooding your office and the "offsite" location down the street, and then have your online backup at the international office to be infected by a virus. Yeah, I know, I'm paranoid... but that doesn't mean they're not out to get me. | ||||
|
feedback
|
|
Personally, I back up my Git repositories plus my working copies daily. Backups are sent to a separate physical location from my server. At work, we make backup copies to different media on the same server daily (it's got RAID), and burn a DVD weekly which is stored in a separate physical location from the server. | ||||
feedback
|
|
Nightly via an svnadmindump command... and then backing up that dumpfile to Amazon S3 using s3cmd | ||||
|
feedback
|
|
Daily using a cron job, it creates a tar.gz backup file which gets deleted after a week. However, that gets burned to DVD every day and offsite via rsync once a week. | ||||
|
feedback
|
|
I don't use subversion, but it seems odd to make this question tool-specific (svn) rather than tool-class-specific (source control). I back up me personal Vault db at least weekly (automated), more often if I do more work on those projects. My recommendation would be that as for any backup: ask yourself how much risk you're willing to take. If something happened, would it be horrible to lose a week's work or not so bad? | ||||
|
feedback
|
|
Daily backups of the central server (so they tell me). Every five minutes via svnsync to a read-only mirror on our build server, which is in a different building than the central server. (You may think me paranoid, but this has performance advantages for the build as well.) | ||||
|
feedback
|
|
I use code.google.com for svn so I have no idea. I hope they back them up often. :-) | ||||
|
feedback
|
|
We do daily backups + incremental backups at least 4 times a day. I'm not sure what our policy is about moving backups offsite, though. | ||||
|
feedback
|
|
I make that backup after every commit. My post-commit hook calls svnsync to replicate the new revisions to the backup repo. See the whynotwiki for some details. SVN is good enough to have svnsync, use it to its fullest! I also make a svnsync to a second backup hourly. It takes seconds to keep that up to date. | ||||
|
feedback
|
