SVN backups..is hotcopy enough or should I worry about full and incremental dumps?

Question

OS: Windows.

For my personal stuff I just use hotcopy once a week but for a more mission critical repo(s), that includes many developers, is that enough? Or should I spend the time to put together a more rigorous backup strategy that includes full dumps and incremental dumps?

edit: I guess I should have been a little more clear. Hotcopy seems like the easiest way to go but I want to be able to restore a repo if, for some reason, it becomes corrupted. Will just doing a hotcopy allow me to do this?

Thanks,

Answer 1

I have bad luck in the past with hotcopies alone. If it's code that is updated and committed many times throughout the day, it might be worth a more in depth backup strategy.

Answer 2

I implemented a backup plan for an enterprise's SVN 1.4.x repository (hosted on Windows at the time), making use of the python script svn-backup-dumps.py

I invoke svn-backup-dump.py from a post-commit hook to trigger incremental backups for a specific revision. I used schtasks to schedule a weekly "full" backup using the same script.

Recovery (which we've had to do twice due to fat-fingered deletion of a directory in the repository) is relatively simple: grab the most recent full backup, restore it. Apply incrementals up through the last revision.

I haven't looked into improvements/changes for 1.5 in this area, but I believe a similar plan would work well for you.

Answer 3

Another good strategy is keeping a second SVN repository and syncing it with the main one with svnsync, usually with a post-commit hook.

The main advantage is that if the first repository goes down for whatever reason, you can immediatly switch to the backup one, and keep working with it without any downtime.

Answer 4

Are you worried about hotcopy or are you worried about backing up only once a week?

Hotcopy will produce a safe and complete backup of your repository, even if other processes (your developers, for example) access the repository at the same time. If you still don't trust it, shut down all access to the repository and backup it by copying it off somewhere with the usual file system tools. (The developers are not going to work around the clock, are they?)

If you are worried about the once-a-week part: just think about what happens if the repo disappears on the day before the next backup is scheduled. Does it matter? If yes, make backups more often. It's that simple.

Is your repository too big to keep several days or weeks worth of full backups? Implement a rotating backup scheme that uses full and incremental backups. Do you have plenty of space for backups? Save yourself the trouble and just make full backups.

Answer 5

If you hotcopy a corrupted repo over the top of your previously uncorrupted backup, then yes, you'll lose your uncorrupted backup.

If you're concerned about this, then as others have said, you need to rotate your backups.

You could also arrange to run 'svnadmin verify' automatically as well.

Answer 6

Call me old school, but what about sub-versioning to a partition and then ghosting on a schedule?

The svnsync option suggested by Davide Gualano sounds good too. I'm leaning towards this option to prevent unnecessary partitioning of my drives (this may also rub other admins the wrong way and not make sense on some of my VPS environments).

Addition

I have been using the svnadmin 'dump' command a lot lately. This works a lot like the mysql dump command, in that it exports your repository out into bak create commands. This command could be implemented as a crontab / scheduled task and then copied to an external drive as a file. Example commands:

svnadmin dump c:\svn\project > c:\dumps\project.bak

svnadmin load c:\svn\project < c:\dumps\project.bak

Then use robocopy / you copying tool of choice to move the file to another location. This is useful if you want to move the files completely off the repo server but there is no external access to subverion.

I still haven't got this down to a fine art. When I move these files between machines, I occassionally get something like 'UUID mismatch'. I have been resolving this by deleting / under-scoring the project folder, then using:

svnadmin create c:\svn\project

svnadmin load c:\svn\project < c:\dumps\project.bak

This should remove the error. You may need to re-create or restore links with Eclipse or other projects. If the UUID is broken, it may affect other people using the project too, so this should be a consideration.

You could use this method as a fall-back for Hotcopy. Between them you should be able to retore the repo.

P.S. Ken, it looks like svn-backup-dumps.py has been moved here: http://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svn-backup-dumps.py