cd-burning/tapeing rdiff-backups?

Ben Escoto bescoto@stanford.edu
Sun, 01 Sep 2002 11:16:33 -0700


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

>>>>> "GZ" == Gregor Zattler <texmex@uni.de>
>>>>> wrote the following on Fri, 30 Aug 2002 22:00:16 +0200

  GZ> If a make two such full backups first at t1 and later on t2 then
  GZ> i could recreate a file which is older than t1 from the first
  GZ> full backup and a file which was modified between t1 and t2 from
  GZ> the second backup.

  GZ> Is there a way of only using one mirror (say on one tape) and
  GZ> collect the increments on other tapes so all recreationof files
  GZ> is done from one huge backup?

Most backup systems (including duplicity) have this structure to their
archive:

1.  Full backup of time 1
2.  Delta (time 1 -> time 2)
3.  Delta (time 2 -> time 3)
    etc

where the deltas above may just be complete copies of changed files
for most backup schemes.  rdiff-backup archives have this structure at
time 3:

1.  Deltas (time 3 -> time 2)
2.  Deltas (time 2 -> time 1)
3.  Mirror of data at time 3 (e.g. full backup time of time 3)

So every time rdiff-backup is run, in addition to writing a delta, it
modifies the mirror.  You can't run rdiff-backup unless you have
access to the mirror data.  So if I understand the question correctly,
what you suggest can't be done by rdiff-backup because it wouldn't
have access to the mirror while writing the increments.
 
  GZ> As in the questions about mergin rdiff-backups my point is how
  GZ> to manage this backups (back them up, move, copy, merge, split
  GZ> them).

Are you talking about tapes now or just normal rdiff-backup archives?
The questions about merging and splitting backups raise an interesting
issue...  A couple of people have asked me about merging them as you
did, and I have always given ad hoc answers.  Perhaps there should be
some built-in framework to merge and split archives.  But the
interface would probably be complicated, and might make it easy for
users to shoot themselves in the foot, even if there were no bugs (for
instance, you'd lose data if you split an archive and re-merged them).


-- 
Ben Escoto

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

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

iD8DBQE9cll++owuOvknOnURAjNZAJwLYriRdCjvxWhK76LPcWZX8Q/V6wCgj37N
kVZN0gbC4EU6X+z07sFgO14=
=fzBV
-----END PGP SIGNATURE-----

--==_Exmh_-871146896P--