Another idea

[Ben Escoto]

--==_Exmh_-1562979648P
Content-Type: text/plain; charset=us-ascii

>>>>> "TP" == Tobias Polzin <polzin_spamprotect_@gmx.de>
>>>>> 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
  TP> myself...

Shouldn't be too much of a problem - I just always seem to end up with
97% of the space used...


-- 
Ben Escoto

--==_Exmh_-1562979648P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001

iD8DBQE9behQ+owuOvknOnURApzdAJ9CgRXgH/Ou5RhQniykBFJ2llhffACfS9f0
eeZ9v+C+Auis7AtmkSmkjKY=
=QcG0
-----END PGP SIGNATURE-----

--==_Exmh_-1562979648P--