rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maarten Bezemer
Subject: Re: [rdiff-backup-users] stupid, stupid question, but necessary to know answer
Date: Sun, 6 Aug 2006 21:56:05 +0200 (CEST)

Hi Chris,

On Sun, 6 Aug 2006, Chris Wilson wrote:

> I think there is a misunderstanding here. If you back up directory /foo to 
> directory /bar using rdiff-backup, then the rdiff-backup-data directory is 
> created under /bar, not /foo.
> 
> So if the ISP is backing up someone's home directory using rdiff-backup, 
> the user will not see any rdiff-backup-data directory inside their home 
> directory.
[cut]
> I don't know what happens if you try to back up an rdiff-backup 
> destination directory (including rdiff-backup-data) using rdiff-backup, 
> but I suspect that it would be unwise to try. In any case, I don't see how 
> it would give you any benefit over backing up that directory using rsync.

I meant this: The user (with no knowledge of the ISP's backup strategies)
can backup e.g. some private stuff to his account at an ISP, using
rdiff-backup. The ISP doesn't know -and shouldn't care!- about what files
the user has in his account, and decides to use rdiff-backup to backup all
their customer's files to some ISP-backup-server machine that is not
accessible for any user.

As long as no restores need to be done, all is well. Only if a restore
needs to be done for some files below the user's rdiff-backup tree, weird
things may happen.

I agree that using rdiff-backup to back up an rdiff-backup destination
directory may not be wise, but it can not always be avoided.

I admit that the situation described above -especially the very specific
restore action- isn't too likely to happen, but that doesn't mean there's
no need to address this kind of issues.

BUT:
I have still no clue on what would happen (or: what should happen, since
these two may not be equal :-) ) if the SOURCE dir (/foo in your example)
already contains something named "rdiff-backup-data". So, that would be
/foo/rdiff-backup-data. This can obviously not be backed up to
/bar/rdiff-backup-data, since that is reserved for rdiff-backup meta
files and increments. Browsing through the source, I couldn't find code
that would address this situation. (But that could be just me, my
knowledge of Python is close to non-existent...)

When I have some more time to dig into this (which is not going to be 
before the end of this week), I might even setup some test set and see
what happens. In the mean time, feel free to save me some time :-)


> I'm beginning to feel that this mirroring feature, while nice at first 
> sight, actually presents a danger of users making unwarranted and 
> unjustified assumptions that the mirror will be an exact mirror, and 
> modifiable. I would be somewhat more comfortable if it was less obviously 
> similar, for example if every filename was preceded with a special 
> character such as "." or "_".

I agree on the feeling, not on the way to solve it :-)
As I'm using rdiff-backup to back up to a non-root account, the mirroring
isn't even exact and not usable. It's _nice_ to have file permissions
preserved, but I wouldn't care if they were not: the metadata should take
care of that.
As far as I'm concerned, it would be fine to just have the actual
destination tree in a subdirectory parallel to the rdiff-backup-data
directory, like this: /bar/foo/stuff and /bar/rdiff-backup-data. That
would at least prevent the use of /bar as a replacement for /foo.

Regards,
 Maarten





reply via email to

[Prev in Thread] Current Thread [Next in Thread]