cd-burning/tapeing rdiff-backups?

Gregor Zattler texmex@uni.de
Mon, 2 Sep 2002 22:16:42 +0200


Hi Ben,
* Ben Escoto <bescoto@stanford.edu> [01. Sep. 2002]:
> >>>>> "GZ" == Gregor Zattler <texmex@uni.de>
> >>>>> wrote the following on Fri, 30 Aug 2002 22:00:16 +0200

GZ>> As in the questions about mergin rdiff-backups my point is
GZ>> how to manage this backups (back them up, move, copy, merge,
GZ>> split them).
 
> Are you talking about tapes now or just normal rdiff-backup
> archives?  

I thought about tapes.  But it doesnt matter.  Backups are data
as other data and there is a need to manage them one way or the
other.  This is especially true since rdiff-backups are on hard
drives.  Perhaps you want a bakup on tape and move it to a
safe.  Or you want to free same space on the hd but you don't
want to do it --remove-older-than but remove a part of a backup.
Or you want to backup a greater part of your hd but don't want to
handle two backups but to merge them or.  Or you want to splitt
them and move one part to another hd or...


 
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.
  
So i could do a backup on two tapes: 
- one tape with the mirror, another tape with the increments.

- next time i make a new mirror on tape one and copy new increments
  to tape two.
...
- later i make a mirror on tape one and copy newer increments on
  tape three because tape two is full?
...
- even later i make a mirror on tape one and recycle tape two for
  newer increments

this would be o.k.?


How do i achive the copying of the incremets? Would 
cp -a /backup/*2002.07.* /backbackup 
catch all necessary files?


Ciao, Gregor
-- 
"The future is here. It's just not widely distributed yet."
-- William Gibson