You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Александр Козлов <Ko...@avionica.spb.ru> on 2016/12/01 15:47:28 UTC

True repository backup

Hello!

I use the Subversion a couple of years. I initiated to deploy the 
Subversion to our work server, because its installation and usage are 
quite simple. And I sometimes help users and administrator to work with 
svn.

Everything was very good, and Yours program realy helps us in our work. 
But the moment of server failure always comes, when anyone wait them :) 
And now we have a problem to restore the Subversion repositories from a 
backup. I read many posts in www about repository backup saving, but 
practically there are no information about real backup restoration 
experience. The our problem is:

- data is backed-up every night, it's ok, but
- many (50) users do they commits couple of times every day, and
- users' working copies are out of sync (they are later!) with server 
after backup restoration.

Unfortunately, the Subersion client programs don't know what to do, when 
working copy base revision is later then head one. I tried to do a dummy 
commits to increase repository head revision number, and then tried to 
coomit the latest version - but this wasn't help to synchronize working 
copies with server.

Of cause, every user can do a virgin repository checkout and then commit 
his/her latest data. Many users have some local unversioned data inside 
ours working copy directories, so they would also synchronize this data. 
But the main problem - working copies have different base revisions. And 
even files and directories are different. It is difficult to find the 
latest working copy of each file.

Latest data and even file revisions are in clients svn databases. So, my 
question: is there some "magic" instrument, that helps users or admins 
to resynchronize working copies and commit latest data into the server?

The Red Book says that making backups every hour is a form of paranoia. 
But after some moments every admin tends to be the real paranoic:) I 
will try to use a repository mirror or some distributed version control. 
But I would teach all users to use the new instruments.

-- 
Best regards!

Alexander Kozlov
Senior hardware developer
Saint-Petersburg, Russia
+7(929)116-45-28
mailto:Kozlov@avionica.spb.ru

Re: True repository backup

Posted by Jörg Heßdörfer <Jo...@sea-gmbh.com>.
Hi,

On 02.12.2016 10:06, Stefan Hett wrote:
> Hi,
> On 12/1/2016 4:47 PM, \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u041a\u043e\u0437\u043b\u043e\u0432 wrote:
>> Hello!
>>
>> I use the Subversion a couple of years. I initiated to deploy the 
>> Subversion to our work server, because its installation and usage are 
>> quite simple. And I sometimes help users and administrator to work 
>> with svn.
>>
>> Everything was very good, and Yours program realy helps us in our 
>> work. But the moment of server failure always comes, when anyone wait 
>> them :) And now we have a problem to restore the Subversion 
>> repositories from a backup. I read many posts in www about repository 
>> backup saving, but practically there are no information about real 
>> backup restoration experience. The our problem is:
>>
>> - data is backed-up every night, it's ok, but
>> - many (50) users do they commits couple of times every day, and
>> - users' working copies are out of sync (they are later!) with server 
>> after backup restoration.
>>
[...]

what we do here is using post-commit hook scripts on the server to dump 
the commit data to a queue folder and transfer these files periodically 
(every 5 mins) to our backup system. Additionally, all changed repos are 
dumped nightly. Thus, we have near realtime recovery possibility 
whenever desaster strikes (which it never did in over 10 years now, 
probably because of our backup/recovery strategy ;-)).

Best regards,
     J�rg
-- 

J�rg He�d�rfer
S.E.A. Datentechnik GmbH
M�lheimer Stra�e 7
53840 Troisdorf
Tel.: +49 2241 12737-19
Fax.: +49 2241 12737-14
E-Mail: Joerg.Hessdoerfer@sea-gmbh.com
Web   : http://www.sea-gmbh.com

Informationen nach 37aHGB, 35a GmbH-Gesetz:
S.E.A.
Science&  Engineering Applications
Datentechnik GmbH
Sitz der Gesellschaft K�ln
Handelsregister K�ln HRB 27016
Gesch�ftsf�hrer: Dr. Gerd Schmitz, Wolfram Koerver


Re: True repository backup

Posted by Stefan Hett <st...@egosoft.com>.
Hi,
On 12/1/2016 4:47 PM, \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u041a\u043e\u0437\u043b\u043e\u0432 wrote:
> Hello!
>
> I use the Subversion a couple of years. I initiated to deploy the 
> Subversion to our work server, because its installation and usage are 
> quite simple. And I sometimes help users and administrator to work 
> with svn.
>
> Everything was very good, and Yours program realy helps us in our 
> work. But the moment of server failure always comes, when anyone wait 
> them :) And now we have a problem to restore the Subversion 
> repositories from a backup. I read many posts in www about repository 
> backup saving, but practically there are no information about real 
> backup restoration experience. The our problem is:
>
> - data is backed-up every night, it's ok, but
> - many (50) users do they commits couple of times every day, and
> - users' working copies are out of sync (they are later!) with server 
> after backup restoration.
>
> Unfortunately, the Subersion client programs don't know what to do, 
> when working copy base revision is later then head one. I tried to do 
> a dummy commits to increase repository head revision number, and then 
> tried to coomit the latest version - but this wasn't help to 
> synchronize working copies with server.
>
> Of cause, every user can do a virgin repository checkout and then 
> commit his/her latest data. Many users have some local unversioned 
> data inside ours working copy directories, so they would also 
> synchronize this data. But the main problem - working copies have 
> different base revisions. And even files and directories are 
> different. It is difficult to find the latest working copy of each file.
>
> Latest data and even file revisions are in clients svn databases. So, 
> my question: is there some "magic" instrument, that helps users or 
> admins to resynchronize working copies and commit latest data into the 
> server?
>
> The Red Book says that making backups every hour is a form of 
> paranoia. But after some moments every admin tends to be the real 
> paranoic:) I will try to use a repository mirror or some distributed 
> version control. But I would teach all users to use the new instruments.
>
An idea to restore the missing data for your users would be to:
1. Restore the existing backup on a repository.
2. Have your users do a fresh checkout of the repository.
3. Copy over all files from their previous working copy to the fresh one.
4. Commit all changes which were missing from the backup.

That way you can reduce the work which was lost to a minimum, I guess.

I won't go into the other areas, since Andreas already answered these.

-- 
Regards,
Stefan Hett


Re: True repository backup

Posted by Александр Козлов <Ko...@avionica.spb.ru>.
Hello, Andreas!

Great thanks for Your fast reply!

02.12.2016 11:43, Andreas Stieger \u043f\u0438\u0448\u0435\u0442:
> \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u041a\u043e\u0437\u043b\u043e\u0432 wrote:
> Many people fail to protect their invested effort properly testing the configuration in a real life drill, a.k.a. test restore.

Yes, I absolutely agree with You. In our case the restore testing was 
not done.

> svnsync mirrors can bridge the gap between interval, archived backups and the intra-day data, but NEVER replace them. As part of a mixed strategy they absolutely make sense for your case. They are not synchronous, neither are dvcs for that matter, and synchronicity is a different consideration.

Ok. We will try svnsync.

-- 
Best regards!

Alexander Kozlov
Senior hardware developer
Saint-Petersburg
mailto:Kozlov@avionica.spb.ru

Re: True repository backup

Posted by Andreas Stieger <An...@gmx.de>.
Александр Козлов wrote:
> The [subversion repository restore] problem is:
> 
> - data is backed-up every night, it's ok, but
> - many (50) users do they commits couple of times every day, and
> - users' working copies are out of sync (they are later!) with server 
> after backup restoration.

Yes, but you knew that when you configured nightly backup.

> Of cause, every user can do a virgin repository checkout and then commit 
> his/her latest data. Many users have some local unversioned data inside 
> ours working copy directories, so they would also synchronize this data.

If you are talking about uncommitted data, that is not even a consideration for svn.
 
> Latest data and even file revisions are in clients svn databases. So, my 
> question: is there some "magic" instrument, that helps users or admins 
> to resynchronize working copies and commit latest data into the server?

Working copies are considered throw-away data. Subversion has no facilities to re-sync working copies to a restored server repositories that may have some revisions removed, in the case where a working copy has newer revisions locally. 

> The Red Book says that making backups every hour is a form of paranoia. 
> But after some moments every admin tends to be the real paranoic:)

That has nothing to do with paranoia, just cost vs. benefits. If nightly backups with archives covers what you need at a price you want to spend for it, then do that. If you need running back-ups and are willing to "pay" for it, implement it. Many people fail to protect their invested effort properly testing the configuration in a real life drill, a.k.a. test restore.

> will try to use a repository mirror or some distributed version control. 
> But I would teach all users to use the new instruments.

I am not sure what you are saying here as these are different concepts.

svnsync mirrors can bridge the gap between interval, archived backups and the intra-day data, but NEVER replace them. As part of a mixed strategy they absolutely make sense for your case. They are not synchronous, neither are dvcs for that matter, and synchronicity is a different consideration.

Andreas