rsync causing disk sleeps and loss of apps

[Martin (KDE)]

Am 03.02.2011 09:39, schrieb Anne Wilson:
> On Thursday 03 February 2011 06:44:26 Martin (KDE) wrote:
>> Hm, this occur if you try to run a copy to a nfs share as root. Usually
>> the user root is mapped to nobody:nobody. root has only limmited access
>> to the nfs server. Do you use nfs for the test or did you used this in
>> the past?
>>
> Yes, this is a nfs share.  I expect I could set it up to directly address the
> IP of the box, if you think that may be the answer?  I frequently ssh into the
> box, but I've not done anything like this through a script before, so if I
> need to know anything particular about syntax, please enlighten me :-)

So do you run the script as user anne or as user root? For backup stuff 
root is better (as you can change user and permission). Problem is to 
make it secure. NFS is not realy an option for backup.

Next question: do you run the rsyn command like

rsync -e ssh /local/dir/to/backup remote-host:/dest/dir

With this, the NFS will not be used, but the rsync tunnelled via ssh to 
the remote host. If you use

rsync -e ssh /local/dir/to/backup /nfs/dest/dir

you can safely omit the ssh part as it will be pure local. then you can 
use you user crontab with same result. just check if the nfs server is 
available and run rsync.

>
>> otherwise It is possible that the destination filesystem does not
>> support user management (FAT).
>>
> N/A
>
>> May be, it is a good idea to try the rsync on a clean destination folder?
>
> I'll see what I can do later today, but the whole point is to get the backup
> onto that particular box.  I know I can do similar backups within the local
> environment.  The server box does just that, backing up to a separate disk.

I think the first step will be to run the rsync command locally, without 
ssh and use the NFS share as destination with an ordinary user (i.e. 
anne). If this is working you can try to invoke ssh (if necessary).

Martin

>
> Anne
>