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.
Received on 2011-07-26 11:21:59 CEST