Danke Stefan for your very helpful response. I apologize for the delay in my response.
> > 2) If yes, would rw,nodev,nosuid,softdep,sync be appropriate fstab > > options to mount /var/svn? > > Don't use softdep! It risks repository corruption during a system crash. > > Use the same mount flags as the defaults for /var. I went back to the man page for mount(8) [1] to try to understand why I might have chosen softdep as a mount option. The explanation for softdep includes the following line: " Instead of metadata being written immediately, it is written in an ordered fashion to keep the on-disk state of the file system consistent. " I am a relative newcomer, so I inferred softdep as better because it helped "keep the on-disk state of the file system consistent". Clearly, I parsed it incorrectly if softdep can cause repository corruption during a crash. > > 3) What is a good svn repository backup routine? Any gotchas that should > > be kept in mind? > > The biggest concern is that backups should be created immediately after > a change has been committed, and that your backup should preferrably go to > a different physical machine. Use the post-commit hook to trigger a backup > (and the post-revprop-change hook, too, if your repository is configured > to allow revprop changes). > > As for getting a copy of repository data, there are a number of options. > > The fastest and smallest backup is provided by: > svnadmin hotcopy --incremental /var/svn/repo /data/backup/repo > It is safe to run this command in a post-commit hook. > But a local mount point for the destination is required. Incremental hotcopy > relies on file sizes and last-modified timestamps recorded in the filesystems > of source and destination. > If the destination is a network drive, make sure clocks between machine stay > in sync. No harm will be done when the clocks are out of sync, but it can > take a lot more time if timestamps don't match since data might be copied > redundantly. > > If you need to backup a repository across a network connection, then > take a look at 'svnsync' (requires a second SVN server) and 'svnrdump' > (backup requires read-access over network, backup can be restored > locally with 'svnadmin load'). > > There is also 'svnadmin freeze' but that is intended for use with an > underlying filesystem which supports snapshots, and OpenBSD does not > support any such filesystem. Danke for the exhaustive backup advice. Reading the useful SVN Redbook [2] highlighted some more distinctions between these approaches. Regards, ab [1] - https://man.openbsd.org/man8/mount.8 [2] - http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication ---------|---------|---------|---------|---------|---------|---------|--
