> > I know that I didn't need to dump/reload for 1.3.x, but i do this as a routine.
> > I was lucky I did this, otherwise a restore from the backup would have shown this error = really bad situation.
[snip]
>
> (Do you use 'svnadmin dump' as a backup? That's awfully slow. You
> might just want to copy the repository.)
I thought using 'svnadmin dump' as a backup was an accepted practice?
I have been using a script like this for a few months now:
nice svnadmin dump /svn/myrepo | gzip | split -b 256m --verbose -
/bak/myrepo.dump.gz.
I use split so that I can burn pieces of the dump to optical disk
sets, for longer term backups. I used 'svnadmin dump' instead of
hot-backup.py because I thought the dump files would be more portable,
in case I wanted to load it onto a different server platform. I use
pg_dumpall on my Postgres SQL server for similar reasons. Also, I
thought, if the problem that lead to the need for a restore was caused
by a particular revision or file commit, I could craft a dumpfilter
before restore, to prevent the problem the next time around. Last, as
others have noted in this thread, I would gain any benefits of having
the whole repo on the latest FSFS storage/delta model, upon any
restore.
Should I give up all these options now, in favor of hot-backup.py? Is
there any way to recover from these dump errors?
I am currently on svn 1.2 on the server, because of problems I had
setting up SVN 1.3 and Trac 0.94 on my SuSE ES9 server (problems not
worth discussing in this thread, I'm just noting my current version
and platform), but I would like to upgrade to 1.4 as soon as it's
deemed stable (with Trac 0.96).
Thanks,
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 17 20:56:15 2006