You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ashim Kapoor <as...@gmail.com> on 2022/03/31 06:40:49 UTC

Transaction support for svnadmin dump command in Subversion / user as which to back an SVN repository

Dear SVN experts,

I am on a Debian linux system.

My fs-type is fsfs.

My svn version is 1.10.4

I am using a project management tool called Redmine which is the front
end for SVN projects and which in turn is relying on Apache as a web
server.

1. I wish to use :

svnadmin dump my-repository > my-repository-backup.dump

on a daily basis at the same time to backup my-repository.

Then I think  that I do *** not *** need to turn off Apache while
doing the above.

Suppose a commit is in process while I am running the above command. I
think SVN supports concurrency as far as commits go. But does SVN
support concurrency while using svnadmin dump? I do not mind losing
out information on that ONE commit since the next day that ONE
particular commit will get dumped into my-repository-backup.dump.
Is there any disadvantage to doing an svndump on a LIVE system ? Will
we experience transaction anomalies if we do this? Is there a way to
setup isolation levels for transactions in Subversion like in
databases?

I do not wish to use svnadmin hotcopy since it's output is not as
portable as svnadmin dump's output. I would need the same filesystem
to restore the svnadmin hotcopy output.

2. Suppose the www-data user is writing to the SVN repositories. My
query is : Should I put the backup cron job into the www-data user's
crontab or the root user's crontab?

My repository is owned by user : www-data and group : root

Many thanks,
Ashim

PS: I am not subscribed to this list so please CC me while responding
to this email.

Re: Transaction support for svnadmin dump command in Subversion / user as which to back an SVN repository

Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Apr 1, 2022 at 3:08 AM Ashim Kapoor <as...@gmail.com> wrote:
>
> Dear Mark,
>
> Could you please answer my query about the isolation level for
> transactions in Subversion?
> Is it always the highest which does not allow for any transaction
> anomalies ? Is there a switch which lowers the isolation level in
> Subversion transactions (at the risk of introducing transaction
> anomalies)?

Subversion does not use those terms so I cannot answer. From the very
first release of Subversion commits have been atomic. They are
completely applied or not at all. You just do not have to worry about
this when performing a dump. The end result may not include commits
that happened during the process but you will get a complete and valid
repository up to the final revision included in your dump.

Mark

Re: Transaction support for svnadmin dump command in Subversion / user as which to back an SVN repository

Posted by Ashim Kapoor <as...@gmail.com>.
Dear Mark,

Could you please answer my query about the isolation level for
transactions in Subversion?
Is it always the highest which does not allow for any transaction
anomalies ? Is there a switch which lowers the isolation level in
Subversion transactions (at the risk of introducing transaction
anomalies)?

Many thanks,
Ashim

On Thu, Mar 31, 2022 at 4:54 PM Ashim Kapoor <as...@gmail.com> wrote:
>
> Dear Mark,
>
> Many thanks for the explanation.
>
> Best Regards,
> Ashim
>
> On Thu, Mar 31, 2022 at 4:45 PM Mark Phippard <ma...@gmail.com> wrote:
> >
> > On Thu, Mar 31, 2022 at 5:47 AM Ashim Kapoor <as...@gmail.com> wrote:
> >
> > > My fs-type is fsfs.
> > >
> > > My svn version is 1.10.4
> > >
> > > I am using a project management tool called Redmine which is the front
> > > end for SVN projects and which in turn is relying on Apache as a web
> > > server.
> > >
> > > 1. I wish to use :
> > >
> > > svnadmin dump my-repository > my-repository-backup.dump
> > >
> > > on a daily basis at the same time to backup my-repository.
> > >
> > > Then I think  that I do *** not *** need to turn off Apache while
> > > doing the above.
> >
> > Correct.
> >
> > Subversion is transactional. The dump file might not include commits
> > that happen after the process begins but it will be a complete
> > representation of your repository up until whatever the final revision
> > it records.
> >
> > > I do not wish to use svnadmin hotcopy since it's output is not as
> > > portable as svnadmin dump's output. I would need the same filesystem
> > > to restore the svnadmin hotcopy output.
> >
> > This is not really true. The fsfs format is portable across all known
> > versions of SVN. 15+ years ago I even used to use it to transport
> > repositories between an EBCDIC-based IBM AS/400 and Windows.
> >
> > The nice thing about hotcopy is that you can now run it against an
> > existing hotcopy and it will just "catch up". The other nice thing is
> > that it copies the hook scripts. The restore process is also
> > significantly faster and easier than a dump file.
> >
> > What is not nice is that it can copy a partial transaction so you
> > could have to do some manual recovery to use a backup, It is pretty
> > easy to do.
> >
> > The other option to consider is svnsync to a backup, This is harder to
> > implement but gives best of both worlds. It is transactional, but it
> > will only do a catch up sync to an existing backup so it is fast. Your
> > backup is a live repository that you could easily switch to.
> >
> >
> > > 2. Suppose the www-data user is writing to the SVN repositories. My
> > > query is : Should I put the backup cron job into the www-data user's
> > > crontab or the root user's crontab?
> > >
> > > My repository is owned by user : www-data and group : root
> >
> > I would use www-data. No point in using root if you do not need to.
> > That said, I think you could also use root.
> >
> > What you should not do is use root to restore the repository. If you
> > do, then all of the repository files will be owned by root and
> > unreadable by your server until you run chown.
> >
> > Mark

Re: Transaction support for svnadmin dump command in Subversion / user as which to back an SVN repository

Posted by Ashim Kapoor <as...@gmail.com>.
Dear Mark,

Many thanks for the explanation.

Best Regards,
Ashim

On Thu, Mar 31, 2022 at 4:45 PM Mark Phippard <ma...@gmail.com> wrote:
>
> On Thu, Mar 31, 2022 at 5:47 AM Ashim Kapoor <as...@gmail.com> wrote:
>
> > My fs-type is fsfs.
> >
> > My svn version is 1.10.4
> >
> > I am using a project management tool called Redmine which is the front
> > end for SVN projects and which in turn is relying on Apache as a web
> > server.
> >
> > 1. I wish to use :
> >
> > svnadmin dump my-repository > my-repository-backup.dump
> >
> > on a daily basis at the same time to backup my-repository.
> >
> > Then I think  that I do *** not *** need to turn off Apache while
> > doing the above.
>
> Correct.
>
> Subversion is transactional. The dump file might not include commits
> that happen after the process begins but it will be a complete
> representation of your repository up until whatever the final revision
> it records.
>
> > I do not wish to use svnadmin hotcopy since it's output is not as
> > portable as svnadmin dump's output. I would need the same filesystem
> > to restore the svnadmin hotcopy output.
>
> This is not really true. The fsfs format is portable across all known
> versions of SVN. 15+ years ago I even used to use it to transport
> repositories between an EBCDIC-based IBM AS/400 and Windows.
>
> The nice thing about hotcopy is that you can now run it against an
> existing hotcopy and it will just "catch up". The other nice thing is
> that it copies the hook scripts. The restore process is also
> significantly faster and easier than a dump file.
>
> What is not nice is that it can copy a partial transaction so you
> could have to do some manual recovery to use a backup, It is pretty
> easy to do.
>
> The other option to consider is svnsync to a backup, This is harder to
> implement but gives best of both worlds. It is transactional, but it
> will only do a catch up sync to an existing backup so it is fast. Your
> backup is a live repository that you could easily switch to.
>
>
> > 2. Suppose the www-data user is writing to the SVN repositories. My
> > query is : Should I put the backup cron job into the www-data user's
> > crontab or the root user's crontab?
> >
> > My repository is owned by user : www-data and group : root
>
> I would use www-data. No point in using root if you do not need to.
> That said, I think you could also use root.
>
> What you should not do is use root to restore the repository. If you
> do, then all of the repository files will be owned by root and
> unreadable by your server until you run chown.
>
> Mark

Re: Transaction support for svnadmin dump command in Subversion / user as which to back an SVN repository

Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Mar 31, 2022 at 5:47 AM Ashim Kapoor <as...@gmail.com> wrote:

> My fs-type is fsfs.
>
> My svn version is 1.10.4
>
> I am using a project management tool called Redmine which is the front
> end for SVN projects and which in turn is relying on Apache as a web
> server.
>
> 1. I wish to use :
>
> svnadmin dump my-repository > my-repository-backup.dump
>
> on a daily basis at the same time to backup my-repository.
>
> Then I think  that I do *** not *** need to turn off Apache while
> doing the above.

Correct.

Subversion is transactional. The dump file might not include commits
that happen after the process begins but it will be a complete
representation of your repository up until whatever the final revision
it records.

> I do not wish to use svnadmin hotcopy since it's output is not as
> portable as svnadmin dump's output. I would need the same filesystem
> to restore the svnadmin hotcopy output.

This is not really true. The fsfs format is portable across all known
versions of SVN. 15+ years ago I even used to use it to transport
repositories between an EBCDIC-based IBM AS/400 and Windows.

The nice thing about hotcopy is that you can now run it against an
existing hotcopy and it will just "catch up". The other nice thing is
that it copies the hook scripts. The restore process is also
significantly faster and easier than a dump file.

What is not nice is that it can copy a partial transaction so you
could have to do some manual recovery to use a backup, It is pretty
easy to do.

The other option to consider is svnsync to a backup, This is harder to
implement but gives best of both worlds. It is transactional, but it
will only do a catch up sync to an existing backup so it is fast. Your
backup is a live repository that you could easily switch to.


> 2. Suppose the www-data user is writing to the SVN repositories. My
> query is : Should I put the backup cron job into the www-data user's
> crontab or the root user's crontab?
>
> My repository is owned by user : www-data and group : root

I would use www-data. No point in using root if you do not need to.
That said, I think you could also use root.

What you should not do is use root to restore the repository. If you
do, then all of the repository files will be owned by root and
unreadable by your server until you run chown.

Mark