Thu, 29 Aug 2002 02:24:33 -0700
Content-Type: text/plain; charset=us-ascii
>>>>> "TP" == Tobias Polzin <firstname.lastname@example.org>
>>>>> wrote the following on Thu, 29 Aug 2002 09:40:06 +0200
>> You may be able to speed your scheme up, maybe by a factor of two
>> or so, by not copying the backup/rdiff-backup directory to begin
>> with (instead of copying it and then deleting it). Not sure what
>> the easiest way of doing this would be (maybe a few lines of
>> shell code).
TP> Perhaps mv backup/rdiff-backup-data tmp/ cp -al backup/ mirror/
TP> mv tmp/rdiff-backup-data backup
Ah yes, that looks like a simple way of doing it.. (I was thinking a
for loop would be required.)
TP> The best way would be, if rdiff-backup supported the "cp -l" way
TP> of copying: Create hard-links instead of copying. Do you think
TP> this would be possible to implement. I assume, that I just have
TP> to add another switch and update Robust.copy and
TP> Robust.copy_with_attributes. What do you thing?
Do you mean that when you run something like "rdiff-backup indir
outdir" that the stuff in indir gets linked inside outdir? I think
you are right about it maybe not being difficult to implement, but I
don't see the utility of a switch. Most of the time indir and outdir
would not be on the same filesystem so hard linking isn't an option.
Also it makes it easy for users to corrupt their backup archive - if
indir is hardlinked to outdir and someone edits a file in indir it
will cause outdir to change too, and the archive gets corrupted.
TP> In both cases that increment files where only some percent of
TP> the mirror size. So I do not quiet understand, why changing
TP> from 45 to 100+ days makes such a problem... Hm, I will find out
Shouldn't be too much of a problem - I just always seem to end up with
97% of the space used...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001
-----END PGP SIGNATURE-----