Re: [rdiff-backup-users] stupid, stupid question, but necessary to know answer

[Ty! Boyack]

Maarten Bezemer wrote:

> On Fri, 4 Aug 2006, J. Norment wrote:
>
>  
>
> > I think I did a bone-headed thing.  I excluded the rdiff-backup-data 
> > path in the backup.  I probably want that path in order to do 
> > incremental restores... is that correct?
> >    
>
> Hmm.. never tried that. You mean you have an --exclude rdiff-backup-data
> on your command line?
>
> This made me think about something related: what happens if the tree
> you're backup up contains an rdiff-backup-data directory? Will it be
> escaped? Will it be ignored? Will it be used and screw up the whole thing?
>
> Maybe there's a difference between having an rdiff-backup-data directory
> at the top-level of the backed-up tree or having it somewhere down the
> tree. The latter case might give other problems when trying to restore
> parts of the tree below that point?
>
> Could someone familiar to the sources and the ideas please shed some light
> on this?
>
> Regards,
> Maarten
>  

Along the same lines, I'd really like to see a way to send the 
rdiff-backup-data directory to another location.  Right now I use 2 
volumes for backed up data repositories - a source volume and a backup 
volume, which is an identical copy plus the rdiff-backup-data directory 
(the normal ridff-backup scenario).  If the source volume fails, I bring 
up the backup volume as a primary volume.  But of course, this contains 
an rdiff-backup-data directory, which confuses users, etc.  I'd really 
like to use 3 volumes - a source, a backup-copy, and an increment 
volume.  This would allow a more exact copy to exist, and would also 
take care of the problem of having an rdiff-backup-data directory in 
your source.  Since the increments would be "out-of-band" with respect 
to the file structure on the disks, it would eleminate the possiblity of 
collision.

Naturally, I don't think this option if for everyone, but I'm wondering 
how hard it would be to implement.  Are we just talking about replacing 
all instances of rdiff-backup-data with 
"IncrementLocation/rdiff-backup-data"?  Or are there other stronger 
restrictions that I'm not seeing? 

I'm not trying to side-track this thread from the original topic, just 
throwing out a suggestion that I'm greedily looking for, and that may 
solve this issue at the same time.  If anyone is familiar with the 
source, I'd appreciate any insight.  (Of course with my appologies for 
not having delved into the source myself.)

-Ty!

--
-===========================-
 Ty! Boyack
 NREL Unix Network Manager
 address@hidden
 (970) 491-1186
-===========================-