Re: Problem using svnsync on one of 10 repositories
On Sat, Feb 11, 2023 at 2:46 PM Bo Berglund wrote: > Follow-up: > > 1) I did a manual run with the command including --steal-lock and it showed > there was a stale lock that it could take over and perform the update. > So this seems to be the way to do it. Stealing locks should *not* be done by default. > 2) I have now added this into the scheduled task script on the server which > will > run about 12 hours from now, hopefully there will not be any problems then. > I made a dummy change and committed it. It should now work with the scheduled svnsync, unless you've something quite odd breaking your lock setups. > So tomorrow morning I will see if the backup is synced to reflect this. > > > -- > Bo Berglund > Developer in Sweden >
Re: Problem using svnsync on one of 10 repositories
On Sat, 11 Feb 2023 18:56:34 +0100, Bo Berglund wrote: >Thanks Pavel! >I just want to check so that I get it right: > >1. Modify the command to use --steal-lock like this in the script (all on one >line): >E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize >--steal-lock >--sync-username syncuser https://backupservername/svn/pcb >https://agiengineering/svn/pcb > > >2. Should I do this *once* on the command line to remove the lock or should I >change the daily script to always use this? >Note that the remote backup SVN server is never used for anything else, noone >checks in or out anything from it... >It is only a backup safeguard off-site. > Follow-up: 1) I did a manual run with the command including --steal-lock and it showed there was a stale lock that it could take over and perform the update. So this seems to be the way to do it. 2) I have now added this into the scheduled task script on the server which will run about 12 hours from now, hopefully there will not be any problems then. I made a dummy change and committed it. So tomorrow morning I will see if the backup is synced to reflect this. -- Bo Berglund Developer in Sweden
Re: Problem using svnsync on one of 10 repositories
On Sat, 11 Feb 2023 19:50:41 +0400, "Pavel Lyalyakin via users" wrote: >> E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize >> --sync-username syncuser https://backupservername/svn/pcb >> https://agiengineering/svn/pcb >> Failed to get lock on destination repos, currently held by >> 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' >> .. 8 repeats of the same . >> Failed to get lock on destination repos, currently held by >> 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' >> svnsync: E22: Couldn't get lock on destination repos after 10 attempts >> >> >> Notice: All other repos sync as intended. Only pcb acts up. >> >> What can I do to remedy this? > >You can try running `svnsync` with the `--steal-lock` option: >https://www.visualsvn.com/support/svnbook/ref/svnsync/#svn.ref.svnsync.sw.steal_lock > >> It seems to have stopped working about 3 weeks ago for this single >> repository. >> >> Note that the backup server, which is an Ubuntu 20.04.5 LTS Server box on >> another location, is connected using the Internet when doing the backups. >> This Ubuntu server has been rebooted a few times since the last working >> backup >> was synced. >> >> What can cause a failure to obtain a lock on that remote server for this >> specific repo? > >There is already a lock in the repository. Perhaps the Ubuntu server >was rebooted in the middle of the sync operation, so the lock wasn't >released then. There is a note about svnsync locks in SVNBook: >https://www.visualsvn.com/support/svnbook/reposadmin/maint/#Content_Content_Content_ctl12 >(see "svnsync Bookkeeping"). Thanks Pavel! I just want to check so that I get it right: 1. Modify the command to use --steal-lock like this in the script (all on one line): E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize --steal-lock --sync-username syncuser https://backupservername/svn/pcb https://agiengineering/svn/pcb 2. Should I do this *once* on the command line to remove the lock or should I change the daily script to always use this? Note that the remote backup SVN server is never used for anything else, noone checks in or out anything from it... It is only a backup safeguard off-site. -- Bo Berglund Developer in Sweden
Re: Problem using svnsync on one of 10 repositories
On Sat, Feb 11, 2023 at 7:23 PM Bo Berglund wrote: > > I have a backup system set up for our VisualSVN server running on Windows > Server > 2016. It consists of a batch file scheduled to run nightly on the SVN server. > > The batch uses a series of commands, one for each of the backed up > repositories > and has been in place from 2018. > > Now when checking the state of the backup I have found that one single > repository is not up to date on the backup server, so I accesssed the Windows > server to see what was going on. > > Turns out that when I run the backup command manually on the server for this > repository I get the following output: > > > E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize > --sync-username syncuser https://backupservername/svn/pcb > https://agiengineering/svn/pcb > Failed to get lock on destination repos, currently held by > 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' > .. 8 repeats of the same . > Failed to get lock on destination repos, currently held by > 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' > svnsync: E22: Couldn't get lock on destination repos after 10 attempts > > > Notice: All other repos sync as intended. Only pcb acts up. > > What can I do to remedy this? You can try running `svnsync` with the `--steal-lock` option: https://www.visualsvn.com/support/svnbook/ref/svnsync/#svn.ref.svnsync.sw.steal_lock > It seems to have stopped working about 3 weeks ago for this single repository. > > Note that the backup server, which is an Ubuntu 20.04.5 LTS Server box on > another location, is connected using the Internet when doing the backups. > This Ubuntu server has been rebooted a few times since the last working backup > was synced. > > What can cause a failure to obtain a lock on that remote server for this > specific repo? There is already a lock in the repository. Perhaps the Ubuntu server was rebooted in the middle of the sync operation, so the lock wasn't released then. There is a note about svnsync locks in SVNBook: https://www.visualsvn.com/support/svnbook/reposadmin/maint/#Content_Content_Content_ctl12 (see "svnsync Bookkeeping"). > It is only used as a backup for the main SVN server. > > The main Windows server is running svn version 1.9.7 (r1800392) > and the Linux backup server is running svn version 1.13.0 (r1867053) > > Is therte some log on the backup server I can access to see what if anything > is > happening there? > > > -- > Bo Berglund > Developer in Sweden > -- With best regards, Pavel Lyalyakin VisualSVN Team
Problem using svnsync on one of 10 repositories
I have a backup system set up for our VisualSVN server running on Windows Server 2016. It consists of a batch file scheduled to run nightly on the SVN server. The batch uses a series of commands, one for each of the backed up repositories and has been in place from 2018. Now when checking the state of the backup I have found that one single repository is not up to date on the backup server, so I accesssed the Windows server to see what was going on. Turns out that when I run the backup command manually on the server for this repository I get the following output: E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize --sync-username syncuser https://backupservername/svn/pcb https://agiengineering/svn/pcb Failed to get lock on destination repos, currently held by 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' .. 8 repeats of the same . Failed to get lock on destination repos, currently held by 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' svnsync: E22: Couldn't get lock on destination repos after 10 attempts Notice: All other repos sync as intended. Only pcb acts up. What can I do to remedy this? It seems to have stopped working about 3 weeks ago for this single repository. Note that the backup server, which is an Ubuntu 20.04.5 LTS Server box on another location, is connected using the Internet when doing the backups. This Ubuntu server has been rebooted a few times since the last working backup was synced. What can cause a failure to obtain a lock on that remote server for this specific repo? It is only used as a backup for the main SVN server. The main Windows server is running svn version 1.9.7 (r1800392) and the Linux backup server is running svn version 1.13.0 (r1867053) Is therte some log on the backup server I can access to see what if anything is happening there? -- Bo Berglund Developer in Sweden
