On Tue, Jan 22, 2013 at 7:18 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Jan 22, 2013 at 12:27:39PM +0530, ana kish wrote:
>> Is it ok to go with VM?
>
> If you go with a VM, I would advise not to put the repositories onto
> a virtual disk image, but on an iscsi disk or SAN that is connected
> to the VM via network.
>
> I've seen a bad case of repository corruption where the repositories
> on a virtual disk were broken after the host system of the VM had
> unexpectedly lost power. Upon reboot revision files in the VM were there
> but they contained corrupt 512 byte blocks (disk sector size). So the
> virtual disk could not properly save data to the physical disk in this
> case. Network disks are better designed to handle failure cases like this.
The same risk is true of any storage, to one degree or another. I've
found iSCSI to be really underwhelming under load.
Backup is *critical* for a production server. Seriously consider
setting up an svnsynced offsite repository and backing up from *that*,
to help ensure that the backups occur between the necessarily atomic
operations of any database.
> If you must use a virtual disk in the VM to host the repositories,
> make sure you have a backup procedure in place that copies revision
> data off the virtual disk as soon as possible (e.g. run 'svnadmin dump
> --incremental' from the post-commit hook and copy the resulting dump
> file to another machine).
I've had good success with svnsync. Neither svnsync nor svnadmin dump
replicate other Subverson configurations, such as Subversion file
ownership or post-commit or authentication or Apache access
configurations, so review how those are replicated for failover as
well.
Received on 2013-01-22 13:55:24 CET