subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From K F <cmkfo...@yahoo.com>
Subject Re: New Server because of Crash
Date Tue, 06 Dec 2011 20:09:37 GMT
--- On Tue, 12/6/11, kmradke@rockwellcollins.com <kmradke@rockwellcollins.com> wrote:

From: kmradke@rockwellcollins.com <kmradke@rockwellcollins.com>
Subject: Re: New Server because of Crash
To: users@subversion.apache.org
Date: Tuesday, December 6, 2011, 7:30 PM

> Stefan Sperling <stsp@elego.de> wrote on 12/06/2011
12:45:36 PM:

> > > How would I get the uuid's. We have the dump, but I believe
that 

> > is it. Can the uuids be obtained from them, would it be simpler
to 

> > just have everyone do a new checkout?

> > 

> > The UUID is somewhere near the top of the dump file in a line
that

> > starts with "UUID:".

> > 

> > If you load into a repository which was freshly created with

> > 'svnadmin create' the 'svnadmin load' process will change the
UUID 

> > of this repository to match the one found in the dump.

> 

> You may however want to force new uuids if there were any committed


> changes that were not in the last dump.  This would force users


> to create new working copies, because their old ones may be "newer"


> than the last dump that you restored from causing problems. 

> 

> My process (assuming changes were commited to the repository 

> after the dumpfile was created and you do not have incremental 

> dump files): 

> 

> 1) Rebuild server 

> 2) Create new empty repository 

> 3) Load dumpfile with a *new* UUID 

> 4) Find the most up-to-date working copy and compare with a 

>    checkout of the new repository 

> 5) Manually apply any changes identified in step #4 and 

>    commit them to the new repository 

> 

> And to ensure steps #4-5 are not needed in the future: 

> 

> 6) Implement incremental dumpfiles of each transaction as they 

>    occur to secondary storage area 

> and/or 

> 7) Replicate repository to secondary storage/server 

> 

> Unless you have other backups, hooks scripts and file 

> locks will not be restored in the svndump file so 

> they will need to be manually re-created. 



Forgot to add that ALL users will need to re-create
their

working copies if the UUID changes.  In my opinion
this

is probably best if you know transactions occurred

since the last svn dumpfile was generated.



Kevin R.


--------

Thank you all for the help. It appears we lucked out though. Since this was built using flat
files and dumps taken, we just had to migrate in the dumps (words of the person doing the
restore). No commits were made between the time of the crash and the last backup so no data
was lost doing it that way. Once the DNS was changed on the new server to match what it was
on the old server, everything started working like nothing was different.

Mime
View raw message