You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Adam Funk <a2...@ducksburg.com> on 2009/10/14 18:54:21 UTC
Backups with svnadmin dump using -r ?
At the moment I back up my repository using this script from a cron
job:
#v+
DSTR=`date +%Y%m%d-%H%M` # e.g. 20011230-0305
REPOS='/usr/local/svn/repository'
DUMP_NAME="bunsen-svn-${DSTR}.dump"
pushd /var/scratch/backups
svnadmin dump -q ${REPOS} >${DUMP_NAME}
popd
#v-
and I later copy the back-up file somewhere safe. The repository is
almost at version 700 now, and I never need to look back more than a
couple of revisions, so I'd be willing to lose a lot of history in
order to reduce the size of the back-up file, but I want to check that
I understand the -r option correctly. If I change the dump command to
svnadmin dump -q -r 600:HEAD ${REPOS} >${DUMP_NAME}
and I need to restore the repository from the back-up, does that mean
I could do all of "svn up -r 600", "svn up -r 601", ..., "svn up"
successfully from it? For example, would it keep files that had been
checked in at r300 and not modified since then?
Thanks,
Adam
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407700
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Backups with svnadmin dump using -r ?
Posted by Stein Somers <ss...@opnet.com>.
I back up using:
svnadmin dump --incremental -r 600:HEAD ${REPOS} >${DUMP_NAME}
and keep a backup of revisions 1:599 separately. You only need to dump those
old revisions once, provided the 600 cutoff point is old enough so that there
is no desire to change revision properties like the log (if you allow that at
all).
When recreating the repository, just load each dump file in sequence or cat
them. It actually saves time, because you can start restoring the first wave
of revisions while you're still downloading the dump file with the later
revisions.
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407840
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Backups with svnadmin dump using -r ?
Posted by Ul...@elektrobit.com.
Ryan Schmidt wrote:
> On Oct 14, 2009, at 13:54, Adam Funk wrote:
[SNIP]
>> svnadmin dump -q -r 600:HEAD ${REPOS} >${DUMP_NAME}
>>
>> and I need to restore the repository from the back-up, does that mean
>> I could do all of "svn up -r 600", "svn up -r 601", ..., "svn up"
>> successfully from it? For example, would it keep files that had been
>> checked in at r300 and not modified since then?
[SNIP]
> I strongly recommend you continue to back up your entire repository,
> and not attempt to cut out revisions to save space. Cutting out
> revisions does not always save space; sometimes it increases
> your disk
> space requirement.
>
> In addition, if you were to restore this partial dump into a new
> repository, it would be a totally different repository than before.
> You would have to give it a new UUID, and would therefore have to
> delete and re-checkout any working copies you had and manually move
> over any uncommitted changes you still had in them. It would
> not be a
> seamless operation. I'm sure that, if you're in a situation where
> you've just had to restore your repository, due to hard drive
> malfunction or whatever, you'll already have enough to deal with
> without also having to deal with recreating all your working copies.
>
> Old revisions never change. (Though old revision properties might
> change, if you allow it with a pre-revprop-change hook.) So consider
> creating a dumpfile of the first 600 revisions and burning them to a
> CD or DVD. Then your regular backup routine can still just back up
> revision 600 through HEAD, and you can still restore the entire
> history by first loading the first 600 revisions from the CD or DVD,
> then loading the current backup. You may or may not want to create
> your 600-through-HEAD dump using the --incremental switch.
You might want to compress the output of svnadmin dump as well - I've
seen 5 GB repositories inflating into 22 GB dumps, that then were
shrunk by gzip to something like 1.6 GB...
Cheers,
Ulli
--
Ullrich Jans, Application Support, IM
Phone: +49 9131 7701-6627, mailto:ullrich.jans@elektrobit.com
Fax: +49 9131 7701-6333, www.elektrobit.com
Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors: Otto Fößel, Jarkko Sairanen
Register Court Fürth HRB 4886
----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407826
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Backups with svnadmin dump using -r ?
Posted by Adam Funk <a2...@ducksburg.com>.
On 2009-10-15, Ryan Schmidt wrote:
> Yes, the backup will preserve anything that exists between revisions
> 600 and HEAD, regardless when those items were initially created. But
> it will not keep the history of any changes (the diffs, or the log
> messages) of events that occurred before 600.
>
> I strongly recommend you continue to back up your entire repository,
> and not attempt to cut out revisions to save space. Cutting out
> revisions does not always save space; sometimes it increases your disk
> space requirement.
>
> In addition, if you were to restore this partial dump into a new
> repository, it would be a totally different repository than before.
> You would have to give it a new UUID, and would therefore have to
> delete and re-checkout any working copies you had and manually move
> over any uncommitted changes you still had in them. It would not be a
> seamless operation. I'm sure that, if you're in a situation where
> you've just had to restore your repository, due to hard drive
> malfunction or whatever, you'll already have enough to deal with
> without also having to deal with recreating all your working copies.
I don't have any uncommitted changes in working copies. I'm the only
user and I keep them tidy. ;-)
> Old revisions never change. (Though old revision properties might
> change, if you allow it with a pre-revprop-change hook.) So consider
> creating a dumpfile of the first 600 revisions and burning them to a
> CD or DVD. Then your regular backup routine can still just back up
> revision 600 through HEAD, and you can still restore the entire
> history by first loading the first 600 revisions from the CD or DVD,
> then loading the current backup. You may or may not want to create
> your 600-through-HEAD dump using the --incremental switch.
OK, that sounds sensible. Thanks.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2408927
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Backups with svnadmin dump using -r ?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 14, 2009, at 13:54, Adam Funk wrote:
> At the moment I back up my repository using this script from a cron
> job:
>
> #v+
> DSTR=`date +%Y%m%d-%H%M` # e.g. 20011230-0305
> REPOS='/usr/local/svn/repository'
> DUMP_NAME="bunsen-svn-${DSTR}.dump"
>
> pushd /var/scratch/backups
> svnadmin dump -q ${REPOS} >${DUMP_NAME}
> popd
> #v-
>
> and I later copy the back-up file somewhere safe. The repository is
> almost at version 700 now, and I never need to look back more than a
> couple of revisions, so I'd be willing to lose a lot of history in
> order to reduce the size of the back-up file, but I want to check that
> I understand the -r option correctly. If I change the dump command to
>
> svnadmin dump -q -r 600:HEAD ${REPOS} >${DUMP_NAME}
>
> and I need to restore the repository from the back-up, does that mean
> I could do all of "svn up -r 600", "svn up -r 601", ..., "svn up"
> successfully from it? For example, would it keep files that had been
> checked in at r300 and not modified since then?
Yes, the backup will preserve anything that exists between revisions
600 and HEAD, regardless when those items were initially created. But
it will not keep the history of any changes (the diffs, or the log
messages) of events that occurred before 600.
I strongly recommend you continue to back up your entire repository,
and not attempt to cut out revisions to save space. Cutting out
revisions does not always save space; sometimes it increases your disk
space requirement.
In addition, if you were to restore this partial dump into a new
repository, it would be a totally different repository than before.
You would have to give it a new UUID, and would therefore have to
delete and re-checkout any working copies you had and manually move
over any uncommitted changes you still had in them. It would not be a
seamless operation. I'm sure that, if you're in a situation where
you've just had to restore your repository, due to hard drive
malfunction or whatever, you'll already have enough to deal with
without also having to deal with recreating all your working copies.
Old revisions never change. (Though old revision properties might
change, if you allow it with a pre-revprop-change hook.) So consider
creating a dumpfile of the first 600 revisions and burning them to a
CD or DVD. Then your regular backup routine can still just back up
revision 600 through HEAD, and you can still restore the entire
history by first loading the first 600 revisions from the CD or DVD,
then loading the current backup. You may or may not want to create
your 600-through-HEAD dump using the --incremental switch.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407775
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].