'Best practices' question for a backup

[Lennart Sorensen]

On Thu, Sep 22, 2005 at 01:59:18PM -0400, Madison Kelly wrote:
> Hi all,
> 
>   I've run into an ethical/best practices question that I wanted input 
> from as many people as I could get on. I have a backup program that is 
> aimed to be generally available to the public. That said, I need to be 
> careful how I tell the program to work. In this case though, either 
> decision I think could upset someone. So....
> 
>   The problem is; when a file or directory has the permissions set to 
> not be world/group readable the backup program (well, 'rsync' 
> specifically) will fail to backup that file.
> 
>   I have two options (as I see it, is there a third?):
> 
>   1. Leave the file behind and assume that the user knew what s/he was 
> doing.
> 
> -OR-
> 
>   2. Have my program temporarily raise the permissions to allow for the 
> file to be backed up and then reset them after words.
> 
>   If I choose number 2 I will be compromising the user's settings but I 
> will also be getting their data off (presumably) to a safe place. The 
> biggest risk is the program dieing or being killed before it can restore 
> the permissions on the modified files (which would have to wait until 
> after 'rsync' finishes which could be a big window).
> 
>   If I choose 1 then I need to educate the user (or just assume the 
> user knows what s/he is doing) and risk missing potentially important 
> files in a backup.
> 
>   So what is better? Risk missing files in a backup job or risk messing 
> up a user's permissions? It's a tough one...

Probably the real solution is the backup system has to run as root, but
have some very well though out interface to the user that very carefully
checks permissions and such.

Although really on normal systems the administrator decides what to
backup and schedules it.  The user might be able to request a file be
restored, but have no direct say in what is backed up, other than
bothering the admin to add something to the list.

Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml