[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Backups with svnadmin dump using -r ?

From: <Ullrich.Jans_at_elektrobit.com>
Date: Thu, 15 Oct 2009 11:06:11 +0200

Ryan Schmidt wrote:
> On Oct 14, 2009, at 13:54, Adam Funk wrote:

[SNIP]

>> svnadmin dump -q -r 600:HEAD ${REPOS} >${DUMP_NAME}
>>
>> and I need to restore the repository from the back-up, does that mean
>> I could do all of "svn up -r 600", "svn up -r 601", ..., "svn up"
>> successfully from it? For example, would it keep files that had been
>> checked in at r300 and not modified since then?

[SNIP]

> I strongly recommend you continue to back up your entire repository,
> and not attempt to cut out revisions to save space. Cutting out
> revisions does not always save space; sometimes it increases
> your disk
> space requirement.
>
> In addition, if you were to restore this partial dump into a new
> repository, it would be a totally different repository than before.
> You would have to give it a new UUID, and would therefore have to
> delete and re-checkout any working copies you had and manually move
> over any uncommitted changes you still had in them. It would
> not be a
> seamless operation. I'm sure that, if you're in a situation where
> you've just had to restore your repository, due to hard drive
> malfunction or whatever, you'll already have enough to deal with
> without also having to deal with recreating all your working copies.
>
> Old revisions never change. (Though old revision properties might
> change, if you allow it with a pre-revprop-change hook.) So consider
> creating a dumpfile of the first 600 revisions and burning them to a
> CD or DVD. Then your regular backup routine can still just back up
> revision 600 through HEAD, and you can still restore the entire
> history by first loading the first 600 revisions from the CD or DVD,
> then loading the current backup. You may or may not want to create
> your 600-through-HEAD dump using the --incremental switch.

You might want to compress the output of svnadmin dump as well - I've
seen 5 GB repositories inflating into 22 GB dumps, that then were
shrunk by gzip to something like 1.6 GB...

Cheers,

Ulli

-- 
Ullrich Jans, Application Support, IM
Phone: +49 9131 7701-6627, mailto:ullrich.jans_at_elektrobit.com 
Fax: +49 9131 7701-6333, www.elektrobit.com
Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors: Otto Fößel, Jarkko Sairanen
Register Court Fürth HRB 4886 
----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407826
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-15 11:38:49 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.