You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dirk Schenkewitz <sc...@docomolab-euro.com> on 2005/06/21 15:59:01 UTC
dump vs. hotcopy
Hi,
I just tried something (SVN-1.2.0, FSFS)
---------------------------------
# svnadmin hotcopy AN AN.backup
# svnadmin dump AN.backup > AN.backup.dump
# tar -cvf AN.backup.tar AN.backup
# bzip2 -k AN.backup.dump AN.backup.tar
# ll
...
drwxr-xr-x 7 root root 1024 Jun 21 10:52 AN.backup
-rw-r--r-- 1 root root 4941453 Jun 21 11:49 AN.backup.dump
-rw-r--r-- 1 root root 891698 Jun 21 11:49 AN.backup.dump.bz2
-rw-r--r-- 1 root root 1669120 Jun 21 11:49 AN.backup.tar
-rw-r--r-- 1 root root 840067 Jun 21 11:49 AN.backup.tar.bz2
...
# du -sb AN.backup
1558671 AN.backup
----------------------------------
I'm astonished that the dump is about 3 times the size of the tar-file.
And from what Ulrich Eckhardt wrote:
> 1. Use the hotcopy script to make a duplicate of your repository.
> 2. 'svnadmin dump' the copy and backup that data - it's the repository's
> content.
> 3. If you're really paranoid, backup the configuration data from (the copy of)
> your repository. Which configuration data you have depends on your access
> method, but the contents of the 'conf' subdir are a candidate. You should
> know which those are, you modified them by hand when setting up the
> repository.
I get the impression that 'svnadmin hotcopy' is safer that 'svnadmin dump'
and more complete. For pure backups, it seems to be the better solution.
E.g., do an 'svnadmin hotcopy REPO REPO.bak' from a post_commit-hook if
REPO.bak does not exist, then make a compressed tarfile from REPO.bak and
delete REPO.bak.
Maybe keep the last 5 tar-files and delete the older ones. Maybe send the
tar-files via scp or rsync to some other machine and/or burn them to CD/DVD
if you are paranoid enough (like me).
Ok, this can be done only for repositories that are not too big. For very
big repositories it might be better to create incremental dumps, but the
disadvantage is that you need to keep all of them to be able to fully
restore a repository, and they seem to take a little more space than one
dump of the whole repository.
Are there any special advantages of "dump" compared to "hotcopy", other than
the ability to make incremental dumps?
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: dump vs. hotcopy
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
William Nagel wrote:
> On Jun 21, 2005, at 4:19 PM, Dirk Schenkewitz wrote:
>
>> (Sorry, I forgot again *slaps self resends to the list*)
>
>
> Heh. I did the same thing. :-)
:-)
> On Jun 21, 2005, at 4:12 PM, Dirk Schenkewitz wrote:
>
>>
>>> My backup process actually uses both. I use a hotcopy to create a
>>> backup of the entire repository to an onsite backup server, and use
>>> an incremental dump to send all of the changes made since the last
>>> backup to an offsite backup server.
>>>
>>
>> Hmm, why incremental? That means you must keep all previous incremental
>> dumps. Why not full dumps every time and replace/overwrite the previous
>> ones? (Except you burn them on CD every time you have enough data.)
>>
>
> You'll notice that I said it goes to an offsite backup server. Maybe I
> wasn't clear that the data is sent to the offsite server over a
> network. Sending the entire repository every night would be
> prohibitive, but sending only the day's changes is very reasonable
> (given the average daily changes on our repository).
Yes it is - I could have thought of that myself.
> Since n
> incremental dumps aren't appreciatively larger in totality than a
> single all-encompassing dump it really isn't a big deal to keep all of
> the incremental dumps around.
>
> If you really see keeping the incremental dumps around as a problem,
> though, one solution would be to have the backup server automatically
> load the dumps into a local repository as it gets them. Then that
> reconstructed repository could be backed up (or dumped to one big dump
> file).
Maybe transferring the big file via rsync could spare some bandwidth...
> -Bill
Thanks Again
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: dump vs. hotcopy
Posted by William Nagel <bi...@stagelogic.com>.
On Jun 21, 2005, at 4:19 PM, Dirk Schenkewitz wrote:
> (Sorry, I forgot again *slaps self resends to the list*)
Heh. I did the same thing. :-)
On Jun 21, 2005, at 4:12 PM, Dirk Schenkewitz wrote:
>
>
>> My backup process actually uses both. I use a hotcopy to create
>> a backup of the entire repository to an onsite backup server, and
>> use an incremental dump to send all of the changes made since the
>> last backup to an offsite backup server.
>>
>>
>
> Hmm, why incremental? That means you must keep all previous
> incremental
> dumps. Why not full dumps every time and replace/overwrite the
> previous
> ones? (Except you burn them on CD every time you have enough data.)
>
You'll notice that I said it goes to an offsite backup server. Maybe
I wasn't clear that the data is sent to the offsite server over a
network. Sending the entire repository every night would be
prohibitive, but sending only the day's changes is very reasonable
(given the average daily changes on our repository). Since n
incremental dumps aren't appreciatively larger in totality than a
single all-encompassing dump it really isn't a big deal to keep all
of the incremental dumps around.
If you really see keeping the incremental dumps around as a problem,
though, one solution would be to have the backup server automatically
load the dumps into a local repository as it gets them. Then that
reconstructed repository could be backed up (or dumped to one big
dump file).
-Bill
>
> Thanks!
> Dirk
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: dump vs. hotcopy
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
(Sorry, I forgot again *slaps self resends to the list*)
William Nagel wrote:
> On Jun 21, 2005, at 12:10 PM, Mark Parker wrote:
>
>>
>> Dirk Schenkewitz wrote:
>>
>>> Are there any special advantages of "dump" compared to "hotcopy",
>>> other than
>>> the ability to make incremental dumps?
>>>
>>
>> The dump could (theoretically) be loaded by any future version of
>> Subversion. The hotcopy (theoretically) needs the correct machine
>> architecture, version of bdb (if it's a bdb repo) and version of
>> Subversion to work.
>>
>> Mark
I see. So for archiving, dump is better, because future versions of
svn should be able to read it and rebuild the repository in their new
"native" format, whatever it might be. Thank you!
> My backup process actually uses both. I use a hotcopy to create a
> backup of the entire repository to an onsite backup server, and use an
> incremental dump to send all of the changes made since the last backup
> to an offsite backup server.
Hmm, why incremental? That means you must keep all previous incremental
dumps. Why not full dumps every time and replace/overwrite the previous
ones? (Except you burn them on CD every time you have enough data.)
Thanks!
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: dump vs. hotcopy
Posted by William Nagel <bi...@stagelogic.com>.
On Jun 21, 2005, at 12:10 PM, Mark Parker wrote:
>
> Dirk Schenkewitz wrote:
>
>> Are there any special advantages of "dump" compared to "hotcopy",
>> other than
>> the ability to make incremental dumps?
>>
>
> The dump could (theoretically) be loaded by any future version of
> Subversion. The hotcopy (theoretically) needs the correct machine
> architecture, version of bdb (if it's a bdb repo) and version of
> Subversion to work.
>
> Mark
My backup process actually uses both. I use a hotcopy to create a
backup of the entire repository to an onsite backup server, and use
an incremental dump to send all of the changes made since the last
backup to an offsite backup server.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: dump vs. hotcopy
Posted by Mark Parker <ma...@msdhub.com>.
Dirk Schenkewitz wrote:
> Are there any special advantages of "dump" compared to "hotcopy", other
> than
> the ability to make incremental dumps?
The dump could (theoretically) be loaded by any future version of
Subversion. The hotcopy (theoretically) needs the correct machine
architecture, version of bdb (if it's a bdb repo) and version of
Subversion to work.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org