subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From K F <cmkfo...@yahoo.com>
Subject New Server because of Crash
Date Wed, 07 Dec 2011 14:59:22 GMT


Our Subversion server crashed because of a disk fail. We are
in the process of setting up a new server to move the repos to. What is the
consensus to do the restore from a backup? Is it straight forward? What
problems if any would there be for users using TortoiseSVN in connecting to the
new server?



Rich

 

-----------------

 

> What is the consensus to do the restore from a backup?
Is it straight forward?



Doesn't this mainly depend on how your backup looks like? :-)



> would there be for users using TortoiseSVN in connecting to the new
server?



This depends on how you set up the new server and how the working copies were
checked out. If your users checked out using IPs and it changed, they have to
svn switch --relocate, same for changed DNS names etc.

 

Thorsten Schöning

 

-----------------

 

The backups were done using svn dump. The new server is
planned to be named the same. Does that mean the switch wouldn't need to be
done?

 

Rich

 

-----------------

 

> The backups were done using svn dump.



This means you have to manually create each repository and copy all hooks,
configurations etc. from the old server. On svnadmin load you have to take
special care on using the old uuids for the new repositories or all working
copies need to get checked out, I think, not even switch --relocate works
anymore.



> Does that mean the switch wouldn't need to be done?





I think so, if you use the same uuids for your newly created
repository as the old ones used. 

 

Thorsten Schöning

 

-----------------

 

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?

 

Rich

 

-----------------

 

Check this link out: http://msmvps.com/blogs/rexiology/archive/2006/05/03/93203.aspx

It has some useful information.  



When you load the SVN dump file into the new repo, you can pass the
--force-uuid  parameter 

It should load the uuid from the other repository.



Mark

 

-----------------

 

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.

 

Stefan Sperling

 

-----------------

 

> 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 committed 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.






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.

 

Rich

 

-----------------

 

 



Our Subversion server crashed because of a disk fail. We are
in the process of setting up a new server to move the repos to. What is the
consensus to do the restore from a backup? Is it straight forward? What
problems if any would there be for users using TortoiseSVN in connecting to the
new server?



Rich

 

-----------------

 

> What is the consensus to do the restore from a backup?
Is it straight forward?



Doesn't this mainly depend on how your backup looks like? :-)



> would there be for users using TortoiseSVN in connecting to the new
server?



This depends on how you set up the new server and how the working copies were
checked out. If your users checked out using IPs and it changed, they have to
svn switch --relocate, same for changed DNS names etc.

 

Thorsten Schöning

 

-----------------

 

The backups were done using svn dump. The new server is
planned to be named the same. Does that mean the switch wouldn't need to be
done?

 

Rich

 

-----------------

 

> The backups were done using svn dump.



This means you have to manually create each repository and copy all hooks,
configurations etc. from the old server. On svnadmin load you have to take
special care on using the old uuids for the new repositories or all working
copies need to get checked out, I think, not even switch --relocate works
anymore.



> Does that mean the switch wouldn't need to be done?





I think so, if you use the same uuids for your newly created
repository as the old ones used. 

 

Thorsten Schöning

 

-----------------

 

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?

 

Rich

 

-----------------

 

Check this link out: http://msmvps.com/blogs/rexiology/archive/2006/05/03/93203.aspx

It has some useful information.  



When you load the SVN dump file into the new repo, you can pass the
--force-uuid  parameter 

It should load the uuid from the other repository.



Mark

 

-----------------

 

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.

 

Stefan Sperling

 

-----------------

 

> 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 committed 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.






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.

 

Rich

 

-----------------

 

 


Mime
View raw message