The problem is that the snapshot is in an inconsistent state, as if the
machine had crashed at that moment. You will need to fsck the snapshot
to make sure the filesystem is ok before mounting it. Then once
mounted, if you are worried about the subversion repository stored
there, you will want to svnadmin verify/recover/whatever to fix any
inconsistencies in the repository. I suppose this part can be done
after restoring rather than before backing up, I just hope that the
inconsistent state is recoverable.
In short, it is safer to svn hotcopy, because this guarantees that the
saved information is consistent; i.e. does not contain half of a commit
that was in progress.
On the other hand, if you are using a filesystem that is tolerant to
crashes, like ext3 or reiserfs, and AFAIK, a subversion repository is
also very resistant to corruption from a crash, then this method might
work alright.
Phil Endecott wrote:
> Dear List,
>
> Has anyone investigated the relative merits of "svn hotcopy" and LVM snapshots?
>
> If you haven't heard of LVM snapshots - which I hadn't until yesterday - they provide a machanism to take an atomic snapshot of a filesystem at the block-level, e.g. something like
>
> lvcreate --snapshot --name snap /path/to/device
> mount snap /mnt/snap
>
> /mnt/snap will now be a read-only snapshot of the state of the filesystem when the snapshot was taken, which you can backup without worrying about things changing simultaneously. You can back up using tar on the mounted snapshot or dump on the unmounted snapshot device.
>
> To some extent the use of snapshots makes things like svn hotcopy, database dump programs, and so on, redundant. From the administrator's point of view it means that they no longer need to worry about the "magic runes" needed for each type of data being backed up.
>
> On the other hand it does rely on a point-in-time snapshot of the filesystem being something from which you can recover. I believe that this is true of Subversion; am I right? Has anyone else already looked into this?
>
> Regards,
>
> --Phil.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 22 17:45:14 2005