You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by K F <cm...@yahoo.com> on 2011/12/06 16:22:10 UTC
New Server because of Crash
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?
Thanks,
Rich
Re: New Server because of Crash
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Dec 6, 2011 at 10:22 AM, K F <cm...@yahoo.com> wrote:
> 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?
Depends on how you do backups. If there is any significant chance that
your dead host has revisions that are not in your backup, you are in
danger of a "split-brain" scenario, and should change the UUID of the
restored copy and force people to reset their checkouts.
RE: New Server because of Crash
Posted by "Eramo, Mark" <me...@hbs.edu>.
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
-----Original Message-----
From: K F [mailto:cmkforce@yahoo.com]
Sent: Tuesday, December 06, 2011 1:34 PM
To: users@subversion.apache.org; Thorsten Schöning
Subject: Re: New Server because of Crash
--- On Tue, 12/6/11, Thorsten Schöning <ts...@am-soft.de> wrote:
> From: Thorsten Schöning <ts...@am-soft.de>
> Subject: Re: New Server because of Crash
> To: users@subversion.apache.org
> Date: Tuesday, December 6, 2011, 4:19 PM Guten Tag K F, am Dienstag,
> 6. Dezember 2011 um 16:58 schrieben Sie:
>
> > 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.
>
> > The new server is planned to
> > be named the same. 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.
>
> Mit freundlichen Grüßen,
>
> 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?
New Server because of Crash
Posted by K F <cm...@yahoo.com>.
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
-----------------
Re: New Server because of Crash
Posted by K F <cm...@yahoo.com>.
--- On Tue, 12/6/11, kmradke@rockwellcollins.com <km...@rockwellcollins.com> wrote:
From: kmradke@rockwellcollins.com <km...@rockwellcollins.com>
Subject: Re: New Server because of Crash
To: users@subversion.apache.org
Date: Tuesday, December 6, 2011, 7:30 PM
> Stefan Sperling <st...@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.
Re: New Server because of Crash
Posted by km...@rockwellcollins.com.
> Stefan Sperling <st...@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.
Re: New Server because of Crash
Posted by km...@rockwellcollins.com.
Stefan Sperling <st...@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.
Kevin R.
Re: New Server because of Crash
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 06, 2011 at 10:34:11AM -0800, K F wrote:
> 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.
Re: New Server because of Crash
Posted by K F <cm...@yahoo.com>.
--- On Tue, 12/6/11, Thorsten Schöning <ts...@am-soft.de> wrote:
> From: Thorsten Schöning <ts...@am-soft.de>
> Subject: Re: New Server because of Crash
> To: users@subversion.apache.org
> Date: Tuesday, December 6, 2011, 4:19 PM
> Guten Tag K F,
> am Dienstag, 6. Dezember 2011 um 16:58 schrieben Sie:
>
> > 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.
>
> > The new server is planned to
> > be named the same. 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.
>
> Mit freundlichen Grüßen,
>
> 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?
Re: New Server because of Crash
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag K F,
am Dienstag, 6. Dezember 2011 um 16:58 schrieben Sie:
> 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.
> The new server is planned to
> be named the same. 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.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: New Server because of Crash
Posted by K F <cm...@yahoo.com>.
--- On Tue, 12/6/11, Thorsten Schöning <ts...@am-soft.de> wrote:
> From: Thorsten Schöning <ts...@am-soft.de>
> Subject: Re: New Server because of Crash
> To: users@subversion.apache.org
> Date: Tuesday, December 6, 2011, 3:46 PM
> Guten Tag K F,
> am Dienstag, 6. Dezember 2011 um 16:22 schrieben Sie:
>
> > 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?
> :-)
>
> > What problems if any 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.
>
> Mit freundlichen Grüßen,
>
> 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?
Re: New Server because of Crash
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag K F,
am Dienstag, 6. Dezember 2011 um 16:22 schrieben Sie:
> 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? :-)
> What problems if any 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.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow