On Tue, Aug 2, 2011 at 2:26 AM, Venkata Badipatla
> Svnadmin dump utility is a correct strategy to be followed. As you are
> telling many repos, you can write simple perl script which can create the
> dump files for all the repos.
OK, *now* I'm going to waggle my finger at you. I find this typical
of some ancient and simplistic perl "solutions" I've seen lately where
a "simple matter of programming" turned into a "simple matter of
ignoring the realities".
Writing a "simple perl script" to chew through 100,000 repositories,
all approaching 1 Gig in size, is approaching 100 TB of fata. Even
with fast local disk, it's a very significant hardware load on the
server. 100 TB, at 80 MB/second for reasonably fast modern disk
is..... 2 weeks. And it would easily take that long to restore, and
it is going to *CHURN* the backups, so identical backups still get
overwritten rather than checked and left alone. And it is *begging*
for "split-brain" problems, where changes that occur in the 2 weeks
are in people's working copies but not in the failover or slave
repository and chaos ensues when their working copy has changes
committed, with the same revision, that the new master server does not
It will also entirely neglect all configuration files, such as
pre-commit and post-commit scripts.
One *could* do something with svnadmin dump of incremental changes:
some sort of flag to register where previous successful transfers left
off could be used to begin dumps with only the updates, and preserve
those. It gets tricky to maintain. But that's all builit right into
svnsync, anyway, so one might as well use that to strart with rather
than this simplistic approach. If you need to stay this simple for
whatever reason, an svnsync push from the primary server might serve.
> From: zhiwei chen [mailto:zhiweik_at_gmail.com]
> Sent: Tuesday, August 02, 2011 11:38 AM
> To: users_at_subversion.apache.org
> Subject: how to back svn repositories
> We have many svn repositories,more than 100,000 , but every repository has
> less than 1024M.
> So,which svn backup strategies should I use ?
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
Received on 2011-08-02 13:50:56 CEST