On Tue, Jul 26, 2011 at 01:33:09PM +0700, Andy Canfield wrote: > For your information, this is my backup script. It produces a zip > file that can be tranported to another computer. The zip file > unpacks into a repository collection, giving, for each repository, a > hotcopy of the repository and a dump of the repository. The hotcopy > can be reloaded on a computer with the same characteristics as the > original server; the dumps can be loaded onto a different computer. > Comments are welcome.
Please also make a backup of every individual revision from the post-commit hook, like this: [[[ #!/bin/sh REPOS="$1" REV="$2" svnadmin dump "${REPOS}" -q --incremental --deltas -r "${REV}" > /backup/${REV}.dmp ]]] And make /backup a separate filesystem, preferably on a different host or some disk storage that runs independently from the host. You will thank me one day when your server's disks die at the wrong moment e.g. because of power failure or overheating. In such cases it is possible that not all data has been flushed to disk yet. The only good data is in the OS buffer cache which the above svnadmin dump command will get to see. However, even revisions committed several *minutes* before such a crash can appear corrupted on disk when you reboot. I've seen this happening (on Windows, with NTFS -- lots of damage; but other operating systems aren't immune to this either). We could tell that the buffer cache data was good because there were multiple corrupted revision files (one repository had more than 20 broken revisions), each with random junk in some parts, and all broken parts were 512 byte blocks, i.e. disk sectors. But in the parts that were not broken they referred to each other in ways that made perfect sense. So before the crash they were all OK. There were no backups so we had to manually repair the revisions (this requires intricate knowledge about the revision file format and takes time...) When this happens you have an unusable repository. Anything referring to the broken revisions will fail (commit, diff, update, ...). Assuming the incremental dumps weren't destroyed in the catastrophe you can load the incremental dumps on top of your last full backup and get to a good state that is very close to the point in time when the crash happened. Without the incremental dumps you'll have the last full backup. But anything committed since could be lost forever.