You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/06/17 16:10:14 UTC
Feature request: a real backup/restore system for svn.
After fighting with issue 1817 for a few days, Karl and I have come to
the conclusion that 'svnadmin hotcopy' is a mess, and we should
deprecate it.... that is, remove it altogether in 2.0. Here's why:
* it has a race condition with db logfile autoremoval, which is
something that people have really come to depend on. In theory,
the worst thing that can happen in the race condition is that the
user sees an error and just tries 'hotcopy' again. In practice,
who knows? We've not done any real stress-testing.
* it's completely specific to BDB. fsfs needs no such thing, and a
future SQL backend will already have its own tools for backup.
* people currently view it as "the correct way" to make a full backup.
We think that Subversion should provide admins with a single, robust
backup/restore solution which "just works" (won't throw random retry
errors), and is independent of repository back-end. We're probably
talking about a smart script which
* utilizes 'svnadmin dump/load' as the main mechanism for backup
and restore,
* knows when to use --incremental or not,
* uses the 1.1 --deltas switch for dumping,
* remembers what it's done before, and manages a collection of full
and incremental dumpfiles,
* can intelligently restore from the collection of dumpfiles.
I'd like to file this as a feature request, but I thought it made
sense to run it by the list for opinions first.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>> * it's completely specific to BDB. fsfs needs no such thing, and a
>>> future SQL backend will already have its own tools for backup.
>>>
>>>
>>>
>>>
>>So what? Face it: real-life backup strategies, at least those that are
>>efficient, will _always_ be backend-specific. For example, nobody in
>>their right mind would use some Subversion tool to back up their SQL
>>database -- they'll use the database's own backup tools. "svnadmin
>>hotcopy" simply happens to be a BDB-specific backup tool.
>>
>>
>
>Nobody in their right mind would use some Subversion tool to back up
>their Berkeley DB database -- they'll use the database's own back
>tool. Like, say, db_chkpoint, db_recover and db_archive. :-)
>
>
Exactly. That's essentially what "svnadmin hotcopy" does. Used to be we
had hot-backup.py do this instead. So if you want to remove "svnadmin
hotcopy" and resintate that functionality into hot-backup.py, that's
fine -- if you can avoid the race conditions that hotcopy solves, but
hot-backup.py didn't.
But dreaming about a single sloution for everybody is just that --
dreaming. As I said, we should instead list all possible (O.K.,
reasonable) backup strategies and figure out how Subversion can be
integrated into each of them, then talk about solutions. Database dumps,
incremental or otherwise, cover perhaps 20% of the problem space.
Getting too caught up with those 20% without even investigating the
remaining 80% is a waste of time, IMHO.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> > * it's completely specific to BDB. fsfs needs no such thing, and a
> > future SQL backend will already have its own tools for backup.
> >
> >
> So what? Face it: real-life backup strategies, at least those that are
> efficient, will _always_ be backend-specific. For example, nobody in
> their right mind would use some Subversion tool to back up their SQL
> database -- they'll use the database's own backup tools. "svnadmin
> hotcopy" simply happens to be a BDB-specific backup tool.
Nobody in their right mind would use some Subversion tool to back up
their Berkeley DB database -- they'll use the database's own back
tool. Like, say, db_chkpoint, db_recover and db_archive. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>After fighting with issue 1817 for a few days, Karl and I have come to
>the conclusion that 'svnadmin hotcopy' is a mess, and we should
>deprecate it.... that is, remove it altogether in 2.0. Here's why:
>
> * it has a race condition with db logfile autoremoval, which is
> something that people have really come to depend on. In theory,
> the worst thing that can happen in the race condition is that the
> user sees an error and just tries 'hotcopy' again. In practice,
> who knows? We've not done any real stress-testing.
>
>
That's not a ptoblem. At worst, we can detect if automatic log file
removal is in force (DB_ENV->get_flags() & DB_LOG_AUTOREMOVE) and fail
unconditionally if it is.
> * it's completely specific to BDB. fsfs needs no such thing, and a
> future SQL backend will already have its own tools for backup.
>
>
So what? Face it: real-life backup strategies, at least those that are
efficient, will _always_ be backend-specific. For example, nobody in
their right mind would use some Subversion tool to back up their SQL
database -- they'll use the database's own backup tools. "svnadmin
hotcopy" simply happens to be a BDB-specific backup tool.
> * people currently view it as "the correct way" to make a full backup.
>
>
Well, it is, given the right circumstances.
The only problem that I do see with it is that it mixes repository
backups and filesystem backups. The FS backup is backend-specific. The
repository backup probably doesn't need any special tools, anyway
(except possibly for the DAV activity database, which we don't handle
correctly and is transient anyway).
>We think that Subversion should provide admins with a single, robust
>backup/restore solution which "just works"
>
A single solution will never "just work" in all circumstances. For
example, there's a huge difference between "hot" (zero-downtime) backups
and "ordinary" backups. Not everyone needs hot backups, but those who do
won't be happy if they have to live with dumps instead.
>(won't throw random retry errors),
>
Like I said, we can simply declare that hotcopy and automatic log file
removal don't work together, and leave it at that. That's quite acceptable.
>and is independent of repository back-end. We're probably
>talking about a smart script which
>
> * utilizes 'svnadmin dump/load' as the main mechanism for backup
> and restore,
>
> * knows when to use --incremental or not,
>
> * uses the 1.1 --deltas switch for dumping,
>
> * remembers what it's done before, and manages a collection of full
> and incremental dumpfiles,
>
> * can intelligently restore from the collection of dumpfiles.
>
>
You do realise that, in order to do this right, you're not looking at a
"smart script" but at a project the size (if not complexity) of cvs2svn?
Because managing such dumpfiles isn't going to be trivial.
Not to mention that this scheme has to take revprop changes into account.
>I'd like to file this as a feature request, but I thought it made
>sense to run it by the list for opinions first.
>
>
A comprehensive backup system will have some mix of the following features:
* Full and incremental backups
* Both offline and online (hot) backups
* Backend-specific and backend-agnostic solutions
Just as an example of what I'm talking about: some databases allow you
to make incremental hot backups. These are very popular with users of
these databases. Your single solution won't provide them. So instead,
I'd suggest thinking about how to integrate Subversion backups with
existing backup tools. It can be as simple as "shut down svnserve before
starting a backup", or as complicated as "Install tool so-and-so to get
Oracle zero-downtime backup integration". Or anything in between. But
it's not a Subversion feature.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-06-21 at 11:57, kfogel@collab.net wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > Well, that's a good argument for having a backup script based on dump
> > files. (I don't think it has to be a huge project, contrary to what
> > Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
> > shouldn't consider it as a replacement for svnadmin hotcopy.
>
> How is it not hot?
Er, sorry. I read Branko use the phrase '"hot" (zero-downtime)' and was
thinking about the time it takes to get the backup operational again.
At work, people use the phrase "hot spare" to refer to a spare server
which is kept running and monitored.
So, sure, a dumpfile backup is a hot backup, but it's sufficiently slow
to restore with that it isn't really a replacement for a backup of the
back end.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FirebirdSQL as backend database
Posted by Erik Huelsmann <e....@gmx.net>.
<Text from the original post deleted by my mail agent because it was HTML
mail>
I'm sorry if I offended you. I didn't intend to. It was exactly the reason I
didn't respond the first time I saw your mail. I'm in need of some holidays
and not in the best of my doing lately. Again, I did not mean to offend you
and I'm sorry I did.
bye,
Erik.
--
+++ Jetzt WLAN-Router f�r alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
Re: FirebirdSQL as backend database
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-07-01 at 12:35, Doru Constantin wrote:
> Erik Huelsmann wrote:
> > To answer your question: Subversion supports pluggable backends which does
> > not mean the project intends to do the development of one any time soon. You
> > are welcome however to organise the effort required; all contributions are
> > very welcome.
We do not support pluggable databases backends yet. That's the real
issue here. A level of abstraction was done to divide between
"database" versus "no database" backends. But a whole separate level of
abstraction still needs to be done to allow *different* databases.J
Once that happens, yes, we'll theoretically be able to support different
SQL databases: postgres, mysql, firebird, etc.
> >
> Ok, I can take a hint. If I'm not welcome I will not bother you
> anymore
You're perfectly welcome here. Didn't mean to scare you away.
> but take a look at
> http://www.firebirdsql.org/ff/foundation/FBFactsheet.html
> The Berkeley db is not match for Firebrid, not even closer, and the
> best part is yet to come.
The main point here is not whether firebird is "good" or "bad" or
"better" than anything else; the main point is that you're many steps
ahead in the conversation, placing the cart before the horse, as they
say. We're nowhere near able to use SQL databases yet, so it makes no
sense to argue merits of specific SQL implementations. We have a long
way to go before we can use SQL at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FirebirdSQL as backend database
Posted by Doru Constantin <do...@home.ro>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Erik Huelsmann wrote:
<blockquote cite="mid8820.1088691934@www29.gmx.net" type="cite">
<blockquote type="cite">
<pre wrap="">Can you consider to implement FirebirdSQL server/embeded as backend
database (<a class="moz-txt-link-abbreviated" href="http://www.firebirdsql.org">www.firebirdsql.org</a>).
Firebird is also opensource.
</doru>
</pre>
</blockquote>
<pre wrap=""><!---->Several days ago, you posted the same question, if I recall correctly.
To answer your question: Subversion supports pluggable backends which does
not mean the project intends to do the development of one any time soon. You
are welcome however to organise the effort required; all contributions are
very welcome.
bye,
Erik.
</pre>
</blockquote>
Ok, I can take a hint. If I'm not welcome I will not bother you anymore
<blockquote cite="mid8820.1088691934@www29.gmx.net" type="cite">
<pre wrap="">BTW: Not all open source has the same license; which makes some open source
very different from others...
</pre>
</blockquote>
but take a look at
<a class="moz-txt-link-freetext" href="http://www.firebirdsql.org/ff/foundation/FBFactsheet.html">http://www.firebirdsql.org/ff/foundation/FBFactsheet.html</a><br>
The <b>Berkeley </b>db is not match for Firebrid, not even closer,
and the best part is yet to come.<br>
The real one handicap is that FirebirdSQL is not installed by default
on any OS.<br>
And, yes, FirebirdSQL is as free as a "bird".<br>
Have a good day sir.<br>
Doru.<br>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FirebirdSQL as backend database
Posted by Erik Huelsmann <e....@gmx.net>.
Hi,
> Can you consider to implement FirebirdSQL server/embeded as backend
> database (www.firebirdsql.org).
> Firebird is also opensource.
> </doru>
Several days ago, you posted the same question, if I recall correctly.
To answer your question: Subversion supports pluggable backends which does
not mean the project intends to do the development of one any time soon. You
are welcome however to organise the effort required; all contributions are
very welcome.
bye,
Erik.
BTW: Not all open source has the same license; which makes some open source
very different from others...
--
+++ Jetzt WLAN-Router f�r alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
FirebirdSQL as backend database
Posted by Doru Constantin <do...@home.ro>.
Can you consider to implement FirebirdSQL server/embeded as backend
database (www.firebirdsql.org).
Firebird is also opensource.
</doru>
Re: Feature request: a real backup/restore system for svn.
Posted by Branko Čibej <br...@xbc.nu>.
Matthew Rich wrote:
>On Mon, 2004-06-21 at 13:57, Branko Čibej wrote:
>
>
>>kfogel@collab.net wrote:
>>
>>
>>
>>>Greg Hudson <gh...@MIT.EDU> writes:
>>>
>>>
>>>
>>>
>>>>Well, that's a good argument for having a backup script based on dump
>>>>files. (I don't think it has to be a huge project, contrary to what
>>>>Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
>>>>shouldn't consider it as a replacement for svnadmin hotcopy.
>>>>
>>>>
>>>>
>>>>
>>>How is it not hot? I thought "hot" just meant that the backup is
>>>performed while the repository is live, and does not affect the
>>>repository's availability for normal use. Dumpfile generation meets
>>>these criteria.
>>>
>>>
>>>
>>>
>>Yes, it does. It's not the most /efficient/ kind of hot backup, but it
>>does meet the criteria.
>>
>>
>
>Hmm, I was under the impression that with svnadmin dump you weren't guaranteed a
>valid backup if there was perchance a write in progess (so you had to pull down
>httpd/svnserve). I always wondered about that, it being transactional and all.
>Was that ever the case, or was it just my imagination?
>
>
Your imagination. :-)
As far as the repository is concerned, "svnadmin dump" behaves as if it
were just another client, checking out revisions one by one. If commits
affected the result of a checkout of an unrelated revision, we'd be in
deep trouble indeed.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Matthew Rich <mr...@tigris.org>.
On Mon, 2004-06-21 at 13:57, Branko Čibej wrote:
> kfogel@collab.net wrote:
>
> >Greg Hudson <gh...@MIT.EDU> writes:
> >
> >
> >>Well, that's a good argument for having a backup script based on dump
> >>files. (I don't think it has to be a huge project, contrary to what
> >>Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
> >>shouldn't consider it as a replacement for svnadmin hotcopy.
> >>
> >>
> >
> >How is it not hot? I thought "hot" just meant that the backup is
> >performed while the repository is live, and does not affect the
> >repository's availability for normal use. Dumpfile generation meets
> >these criteria.
> >
> >
> Yes, it does. It's not the most /efficient/ kind of hot backup, but it
> does meet the criteria.
Hmm, I was under the impression that with svnadmin dump you weren't guaranteed a
valid backup if there was perchance a write in progess (so you had to pull down
httpd/svnserve). I always wondered about that, it being transactional and all.
Was that ever the case, or was it just my imagination?
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Greg Hudson <gh...@MIT.EDU> writes:
>
>
>>Well, that's a good argument for having a backup script based on dump
>>files. (I don't think it has to be a huge project, contrary to what
>>Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
>>shouldn't consider it as a replacement for svnadmin hotcopy.
>>
>>
>
>How is it not hot? I thought "hot" just meant that the backup is
>performed while the repository is live, and does not affect the
>repository's availability for normal use. Dumpfile generation meets
>these criteria.
>
>
Yes, it does. It's not the most /efficient/ kind of hot backup, but it
does meet the criteria.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Well, that's a good argument for having a backup script based on dump
> files. (I don't think it has to be a huge project, contrary to what
> Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
> shouldn't consider it as a replacement for svnadmin hotcopy.
How is it not hot? I thought "hot" just meant that the backup is
performed while the repository is live, and does not affect the
repository's availability for normal use. Dumpfile generation meets
these criteria.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-06-18 at 19:24, Vincent Lefevre wrote:
> In case of hardware failure for instance, one may need to change
> the server, and perhaps use a different backend. If backup tools
> are backend-specific, how could this work?
Well, that's a good argument for having a backup script based on dump
files. (I don't think it has to be a huge project, contrary to what
Branko said.) But such a thing doesn't qualify as a "hot" backup, so we
shouldn't consider it as a replacement for svnadmin hotcopy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2004-06-18 09:41:01 -0500, kfogel@collab.net wrote:
> I'm very glad for this thread. The point that backup tools are always
> backend-specific makes me think we don't need an 'svnadmin dump'
> solution. Rather, something based on today's hotcopy might work fine,
> as long as we doc its limitation carefully, make it warn if logfile
> autoremoval is turned on, and it does its best to detect problems when
> the backup actually happens.
In case of hardware failure for instance, one may need to change
the server, and perhaps use a different backend. If backup tools
are backend-specific, how could this work?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> I think the hotcopy race is probably more of a theoretical issue than a
> practical one, unless you have a very high rate of commits (and in that
> case, maybe you have the resources to learn about turning off logfile
> removal and only remove logfiles at such a time as you're not doing a
> hotcopy). Especially since in 1.1, read-only operations don't frob the
> database so much.
It may be theoretical for most uses of Subversion, but note at least
that Mike and I have been able to stimulate the problem fairly easily.
In fact, if you apply this patch
Index: contrib/server-side/backup-recipe.sh
===================================================================
--- contrib/server-side/backup-recipe.sh (revision 10025)
+++ contrib/server-side/backup-recipe.sh (working copy)
@@ -78,7 +78,7 @@
cd ${SANDBOX}
-${SVNADMIN} create --bdb-log-keep ${REPOS}
+${SVNADMIN} create ${REPOS}
${SVN} co file://${SANDBOX}/${REPOS} wc
cd wc
to contrib/server-side/backup-recipe.sh, that script can demonstrate
the problem.
A high rate of commits makes it more likely things will go wrong; a
low rate merely makes it less likely, but not impossible.
I'm very glad for this thread. The point that backup tools are always
backend-specific makes me think we don't need an 'svnadmin dump'
solution. Rather, something based on today's hotcopy might work fine,
as long as we doc its limitation carefully, make it warn if logfile
autoremoval is turned on, and it does its best to detect problems when
the backup actually happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Greg Hudson <gh...@MIT.EDU>.
I'd be concerned that restore time will take too long if the backup is a
collection of dumps. Ideally, you should be able to move the backup
into place and be up and running again in minutes, even if you have a
big repository.
I think the hotcopy race is probably more of a theoretical issue than a
practical one, unless you have a very high rate of commits (and in that
case, maybe you have the resources to learn about turning off logfile
removal and only remove logfiles at such a time as you're not doing a
hotcopy). Especially since in 1.1, read-only operations don't frob the
database so much.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Vladimir Berezniker <vm...@hitechman.com>.
<quote who="Ben Collins-Sussman">
> After fighting with issue 1817 for a few days, Karl and I have come to
> the conclusion that 'svnadmin hotcopy' is a mess, and we should
> deprecate it.... that is, remove it altogether in 2.0. Here's why:
>
> * it has a race condition with db logfile autoremoval, which is
> something that people have really come to depend on. In theory,
> the worst thing that can happen in the race condition is that the
> user sees an error and just tries 'hotcopy' again. In practice,
> who knows? We've not done any real stress-testing.
>
> * it's completely specific to BDB. fsfs needs no such thing, and a
> future SQL backend will already have its own tools for backup.
I am a little puzzled by this comment. I read it to say that BDB specific back
tools are a bad idea, but SQL backend tools are okay. Or did you mean to say
that both of them could be replaced by the proposed generic subversion backup
system?
>
> * people currently view it as "the correct way" to make a full backup.
>
>
<snip>
Sincerely,
Vladimir Berezniker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Vladimir Berezniker <vm...@hitechman.com>.
<quote who="Bruce Elrick">
> Ben Collins-Sussman wrote:
>> We think that Subversion should provide admins with a single, robust
>> backup/restore solution which "just works" (won't throw random retry
>> errors), and is independent of repository back-end. We're probably
>> talking about a smart script which
>>
>> * utilizes 'svnadmin dump/load' as the main mechanism for backup
>> and restore,
>>
>> * knows when to use --incremental or not,
>>
>> * uses the 1.1 --deltas switch for dumping,
>>
>> * remembers what it's done before, and manages a collection of full
>> and incremental dumpfiles,
>>
>> * can intelligently restore from the collection of dumpfiles.
>
> As a systems administrator, may I suggest one other attribute to this
> proposed tool? That its abilility to manage a collection be designed to
> manage more than one collection of dumpfiles? This would suggest that
> the meta-data for tracking "what it has done" be stored along with the
> dump files themselves such that if you have two locations for dump files
> each is managed independently.
>
> Cheers...
> Bruce
>
I see the need for this too, as often there might be independent backups done
for added redundancy.
Also for paranoid people like me, it would be nice to have the ability to run
the backup command from post commit hook in incremental mode such as to be able
to tell which new files were created. So that those file can be immediately sent
to the backup server.
Sincerely,
Vladimir Berezniker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: a real backup/restore system for svn.
Posted by Bruce Elrick <br...@elrick.ca>.
Ben Collins-Sussman wrote:
> We think that Subversion should provide admins with a single, robust
> backup/restore solution which "just works" (won't throw random retry
> errors), and is independent of repository back-end. We're probably
> talking about a smart script which
>
> * utilizes 'svnadmin dump/load' as the main mechanism for backup
> and restore,
>
> * knows when to use --incremental or not,
>
> * uses the 1.1 --deltas switch for dumping,
>
> * remembers what it's done before, and manages a collection of full
> and incremental dumpfiles,
>
> * can intelligently restore from the collection of dumpfiles.
As a systems administrator, may I suggest one other attribute to this
proposed tool? That its abilility to manage a collection be designed to
manage more than one collection of dumpfiles? This would suggest that
the meta-data for tracking "what it has done" be stored along with the
dump files themselves such that if you have two locations for dump files
each is managed independently.
Cheers...
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org