Moving the entire SVN instance to a newer Windows server

[Morin, Michael]

We need to move Subversion off of a Windows 2012 server and onto a Windows 2019 server. Is there a simpler way to do this other than moving each repository one by one? I have over 170 repositories that I need to migrate to the new server. Can the entire SVN instance be backed up and restored….or copied over by some similar method?

 

Mike Morin

Senior Programmer Analyst

MaineIT, Department of Administrative and Financial Services

(207)592-6134

 

[Mark Phippard]

On Wed, May 18, 2022 at 9:46 AM Morin, Michael <Michae...@maine.gov> wrote:
>
> We need to move Subversion off of a Windows 2012 server and onto a Windows 2019 server. Is there a simpler way to do this other than moving each repository one by one? I have over 170 repositories that I need to migrate to the new server. Can the entire SVN instance be backed up and restored….or copied over by some similar method?

Build the new server, install SVN, make sure it is working and
configured the way you want, then just stop both servers, copy the
entire repositories folder over to the new server and start it up.

If you can use the same DNS hostname for the new server there will be
no impact on your clients but if you change the name they will need to
use svn relocate to change the URL.

Only other thing to look out for is hook scripts that may exist in
your repositories and any dependencies those scripts rely on that
needs to be installed on the server.

Mark

[Andreas Stieger]

Hi,

On 5/18/22 16:54, Mark Phippard wrote:
> If you can use the same DNS hostname for the new server there will be
> no impact on your clients

Except for possibly a change server-side certificate which may have
changed (and not properly verified before). Can be addressed with
testing, and it helps to use a service name instead of a host name.

If you are looking to make this seamless, you can set up replication and
write-through proxying as you move the configuration and scripts first.


Andreas

[Nico Kadel-Garcia]

Why would you want to move a Subversion server to a Windows system?
There are real performance tuning issues for either httpd or svn+ssh
based access which are more easily handled in a Linux or UNIX
environment, and high reliability and backup setups far more difficult
to resolve in a Windows environment.

Definitely activate an svnsync to allow the new service to run in
parallel for a while, and to avoid any split-brain issues.

[Bo Berglund]

On Sun, 22 May 2022 08:40:55 -0400, Nico Kadel-Garcia <nka...@gmail.com> wrote:

>On Sun, May 22, 2022 at 4:24 AM Andreas Stieger <Andreas...@gmx.de> wrote:
>>
>> Hi,
>>
>> On 5/18/22 16:54, Mark Phippard wrote:
>> > If you can use the same DNS hostname for the new server there will be
>> > no impact on your clients
>>
>>
>> Except for possibly a change server-side certificate which may have
>> changed (and not properly verified before). Can be addressed with
>> testing, and it helps to use a service name instead of a host name.
>>
>> If you are looking to make this seamless, you can set up replication and
>> write-through proxying as you move the configuration and scripts first.
>
>Why would you want to move a Subversion server to a Windows system?

I think that he said:
>>>We need to move Subversion off of a Windows 2012 server and onto a Windows 2019 server.

So the relevant question for him is what kind of server they are running...
If it is VisualSVN then they should go to that maintainer and ask for help.

>There are real performance tuning issues for either httpd or svn+ssh
>based access which are more easily handled in a Linux or UNIX
>environment, and high reliability and backup setups far more difficult
>to resolve in a Windows environment.
>
>Definitely activate an svnsync to allow the new service to run in
>parallel for a while, and to avoid any split-brain issues.

I have a similar problem where I have installed VisualSVN back in 2017 on a
Windows 2016 Server and now I face problems keeping it updated.

It is still on VisualSVN 3.7.0 and since I am remote to the server by 8,500 km I
do not really dare experimenting with the updates....

This server runs SVN version as follows:
H:\>svn --version
svn, version 1.9.7 (r1800392)
compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601

It is still working but should be upgaded, only I don't know how to do it
safely.


The server is svn synced nightly over the Internet to a server I host in my
premises, which is an Ubuntu Server 20.04.4 LTS and this runs:
~$ svn --version
svn, version 1.13.0 (r1867053)
compiled Apr 8 2022, 09:43:33 on x86_64-pc-linux-gnu

On Linux the subversion upgrade is seamless with the apt program used to
update/upgrade the whoile computer.

So the OP (and myself) really need to create a Linux server to host the
Subversion service going forward...

What would be the proper way to migrate to a Linux based server and keeping the
repository structure the same and allow user seamless access to these?


--
Bo Berglund
Developer in Sweden

[Andreas Stieger]

On 5/22/22 14:40, Nico Kadel-Garcia wrote:
> Why would you want to move a Subversion server to a Windows system?

Because that is what poster said they were migrating from. In existing
deployments keeping the current authentication, logging and
administration experience is probably more important than tweaks. So
let's assume that this is on purpose.

> Definitely activate an svnsync to allow the new service to run in
> parallel for a while, and to avoid any split-brain issues.

Only if they cannot deal with a short migration read-only or down time.


Andreas

[Daniel Sahlberg]

Den sön 22 maj 2022 kl 14:41 skrev Nico Kadel-Garcia <nka...@gmail.com>:

On Sun, May 22, 2022 at 4:24 AM Andreas Stieger <Andreas...@gmx.de> wrote:
>
> Hi,
>
> On 5/18/22 16:54, Mark Phippard wrote:
> > If you can use the same DNS hostname for the new server there will be
> > no impact on your clients
>
>
> Except for possibly a change server-side certificate which may have
> changed (and not properly verified before). Can be addressed with
> testing, and it helps to use a service name instead of a host name.
>
> If you are looking to make this seamless, you can set up replication and
> write-through proxying as you move the configuration and scripts first.

Why would you want to move a Subversion server to a Windows system?

Why not, if it suits the needs of the users? In our case (I'm not OP), we are a Windows shop with plenty of Windows servers but no pre-existing Linux/Unix/BSD servers. We selected one of the commercial offerings on Windows: For the commercial support; To support their work with Subversion; For the additional nice-to-haves features (one-click Active Directory authentication, replication, backup). We could have added a new Linux server and configured everything by hand but to us it made more sense to install it next to our other applications where all our admins feel confident.

There are real performance tuning issues for either httpd or svn+ssh
based access which are more easily handled in a Linux or UNIX
environment, and high reliability and backup setups far more difficult
to resolve in a Windows environment.

Why would it be more difficult to setup a HA and backup solution on Windows? (I'm not counting commercial add-ons here).

Kind regards,

Daniel

[Daniel Sahlberg]

Den sön 22 maj 2022 kl 17:59 skrev Bo Berglund <bo.be...@gmail.com>:

[...]

So the relevant question for him is what kind of server they are running...
If it is VisualSVN then they should go to that maintainer and ask for help.


>There are real performance tuning issues for either httpd or svn+ssh
>based access which are more easily handled in a Linux or UNIX
>environment, and high reliability and backup setups far more difficult
>to resolve in a Windows environment.
>
>Definitely activate an svnsync to allow the new service to run in
>parallel for a while, and to avoid any split-brain issues.


I have a similar problem where I have installed VisualSVN back in 2017 on a
Windows 2016 Server and now I face problems keeping it updated.

It is still on VisualSVN 3.7.0 and since I am remote to the server by 8,500 km I
do not really dare experimenting with the updates....

I would be more worried about doing Windows updates remote (even seen a server not coming online after an update?) than updating VisualSVN.

The few updates I have done on VisualSVN have been seemless and, as you said yourself previously, as long as you have a valid support contract, I'm sure VisualSVN will be more than happy to help you resolve any problems.

This server runs SVN version as follows:
H:\>svn --version
svn, version 1.9.7 (r1800392)
   compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601

It is still working but should be upgaded, only I don't know how to do it
safely.


The server is svn synced nightly over the Internet to a server I host in my
premises, which is an Ubuntu Server 20.04.4 LTS and this runs:
~$ svn --version
svn, version 1.13.0 (r1867053)
   compiled Apr  8 2022, 09:43:33 on x86_64-pc-linux-gnu

On Linux the subversion upgrade is seamless with the apt program used to
update/upgrade the whoile computer.

So the OP (and myself) really need to create a Linux server to host the
Subversion service going forward...

What would be the proper way to migrate to a Linux based server and keeping the
repository structure the same and allow user seamless access to these?

If you have not used any of the advanced features in VisualSVN (ie, only using regular FSFS repositories and only Subversion authentication) you should be able to follow the same advise already given in the thread: Stop the service, copy the repository folders to the new server, configure the new server to use the existing authn/authz files, point the existing DNS names to the new server. As already pointed out you should check for any dependencies in existing hook scripts (in particular, if you have any binary hook scripts or using BATCH language).

Kind regards,

Daniel

[Nico Kadel-Garcia]

On Sun, May 22, 2022 at 12:02 PM Andreas Stieger <Andreas...@gmx.de> wrote:
>
>
> On 5/22/22 14:40, Nico Kadel-Garcia wrote:
> > Why would you want to move a Subversion server to a Windows system?
>
>
> Because that is what poster said they were migrating from. In existing
> deployments keeping the current authentication, logging and
> administration experience is probably more important than tweaks. So
> let's assume that this is on purpose.

From a considerable amount of painful experience with multiple
platforms, I suggest that the Windows backups and scripting would be
better discarded and re-implemented for the Linux based environment.
Many of them may require no tweaking, depending on the Windows server
environment. System stability and security are likelier to be much
better, as is system performance. Been there, done that, have the scar
tissue.

> > Definitely activate an svnsync to allow the new service to run in
> > parallel for a while, and to avoid any split-brain issues.
>
> Only if they cannot deal with a short migration read-only or down time.

I've made that "this will be only for a moment" prediction before.
I'll leave out the rude metaphors, but the claim is usually about as
reliable as a debtor saying "the check is in the mail". Especially for
a bulky server, with bulky commits the "out of service" time can tke
hours. Never schedule a system upgrade to occur with backup and
transfer in a tight time window if you can avoid it gracefully, and
"svnsync" allows pre-synchronization with a top-up of the last few
commots at switchover time. It's normally much, much cleaner,
especially with repos that have bulky binaries among old commits.

>
> Andreas
>

[Andreas Stieger]

Hi,

> If you have not used any of the advanced features in VisualSVN [...]

FWIF... The free VistualSVN version can* be set up to do full write-through proxying and async replication. It ships all the modules. (* last confirmed in ~2015)

Andreas

[Morin, Michael]

In my case, I have no choice in the matter of what server and OS to move to. We don’t use VisualSVN. We just use Tortoise with Subversion. When we last did a migration from one Windows server to another, it was a tedious process of contacting the users of the repository, asking them if the repo should be migrated or archived, setting a date for the migration, telling the users to make any outstanding commits, locking down the repository, migrating the repository, informing users of the new URL of the repository, and asking the users to confirm their ability to access the repo and verifying everything works as expected. This was done for each repository. This process took us about 4 ½ months. I’d like to avoid taking that long this time around.

[Nico Kadel-Garcia]

On Mon, May 23, 2022 at 6:16 AM Morin, Michael <Michae...@maine.gov> wrote:
>
> In my case, I have no choice in the matter of what server and OS to move to. We don’t use VisualSVN. We just use Tortoise with Subversion. When we last did a migration from one Windows server to another, it was a tedious process of contacting the users of the repository, asking them if the repo should be migrated or archived, setting a date for the migration, telling the users to make any outstanding commits, locking down the repository, migrating the repository, informing users of the new URL of the repository, and asking the users to confirm their ability to access the repo and verifying everything works as expected. This was done for each repository. This process took us about 4 ½ months. I’d like to avoid taking that long this time around.

*Ouch*. Been there, done that. I'm assuming that each repo is, indeed,
an entirely distinct Subversion repo rather than all being distributed
under one master repo? That makes migration much, much safer.

[Morin, Michael]

Yes, each repository is a distinct Subversion repository. We have about 300 Subversion users located in different departments and 171 repositories.

-----Original Message-----
From: Nico Kadel-Garcia <nka...@gmail.com>
Sent: Monday, May 23, 2022 6:58 AM
To: Morin, Michael <Michae...@maine.gov>
Cc: us...@subversion.apache.org
Subject: Re: Moving the entire SVN instance to a newer Windows server

EXTERNAL: This email originated from outside of the State of Maine Mail System. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[Andreas Stieger]

Hi,

> We just use Tortoise with Subversion.

You mean just plain file:// access? (no mod_dav_svn or svn)? Then there is not even a Subversion server involved. Is there any way you can re-use the hostname?

Andreas

[Bo Berglund]

On Mon, 23 May 2022 11:03:32 +0000, "Morin, Michael" <Michae...@maine.gov>
wrote:

>>On Mon, May 23, 2022 at 6:16 AM Morin, Michael <Michae...@maine.gov> wrote:
>>>
>>> In my case, I have no choice in the matter of what server and OS to move to. We don’t use VisualSVN.
>>>We just use Tortoise with Subversion. When we last >did a migration from one Windows server to another,
>>>it was a tedious process of contacting the users of the repository, asking them if the repo should be
>>>migrated or archived, setting a date for the migration, telling the users to make any outstanding commits,
>>>locking down the repository, migrating the >repository, informing users of the new URL of the repository,
>>>and asking the users to confirm their ability to access the repo and verifying everything >works as expected.
>>>This was done for each repository. This process took us about 4 ½ months. I’d like to avoid taking that
>>>long this time around.
>>
>>*Ouch*. Been there, done that. I'm assuming that each repo is, indeed, an entirely distinct Subversion
>>repo rather than all being distributed under one >master repo? That makes migration much, much safer.
>>

>Yes, each repository is a distinct Subversion repository. We have about 300 Subversion users located in
>different departments and 171 repositories.
>

Just to clarify for my understanding:
Are you saying that the users are accessing the repositories via file sharing in
Windows using Tortoise-Svn? I.e. do they point the client (Tortoise-SVN) to a
drive letter location where they operate on the repository?

In that case you do not even have a *server* running so migrating the *server*
is a non-issue.

And the whole setup is pretty vulnerable to rogue users with write permissions
on the repository side...

PS:
Please do not top-post, it makes it so much harder to follow the discussion.
DS

[Morin, Michael]

-----Original Message-----
From: Bo Berglund <bo.be...@gmail.com>
Sent: Monday, May 23, 2022 8:09 AM
To: us...@subversion.apache.org
Subject: Re: Moving the entire SVN instance to a newer Windows server

EXTERNAL: This email originated from outside of the State of Maine Mail System. Do not click links or open attachments unless you recognize the sender and know the content is safe.

> The server is running two services: CollabNet Subversion Edge and CollabNet Subversion Server. Users interact with the repositories by typing the URL of the repository into Tortoise.