[Klug-general] Permissions problem

[Alan Buchel]

Yes, reliably mounting destination storage with correct permission is
always an issue for backups, and full OS recovery can be a mare
therefrom. Instead you can use an ssh destination in rsync and this
bypasses the issue altogether:

1) create a file called /file.exceptions, in there list all the
directories you do NOT want ot include in the backup. An example will be
#file.exceptions.example:

/dev
/media
/mnt
/home/dummyuser_that_dont_need_backup
/home/phileas/.Trash

2) say your machine with backup file storage is on 192.168.1.2 then from
a root cli on source you can run rsync like this:
( achieve this using "sudo su -")

rsync -azv  /  root at 192.168.1.2:/backupsdirectory 
--exclude-from=/file.exceptions

-a maintains subdirs, ownership & permissions
-z compresses over network
-v verbose

If your using some distros you will first need to give root a password.
Or you can use ssh keys, also necessary if you want to cron this job. To
do that, create a password-less keypair (with ssh-keygen), call them for
example private.key and public.key. Put the public.key into
.ssh/authorized_keys on destination machine, the private into /root/ on
source machine and run the rsync as follows:

rsync -azv -e "ssh -i /root/private.key" / 
root at 192.168.1.2:/backupsdirectory  --exclude-from=/file.exceptions
--log-file /var/log/backup.log

Alan

On 15/12/11 12:29, Michael E. Rentell wrote:
> On 15/12/11 11:41, Mike Evans wrote:
>> Sorry to come to this late.
>>
>> If you are using NFS to mount the drive then it will work provided
>> your user ID numbers are the same on each machine as that's what NFS
>> uses. (Hopelessly insecure but hey they assume that you know what
>> you're doing and can secure your network properly.)  However there is
>> an exception to this:  root is protected and the default behaviour is
>> to do what's called 'rootsquash' - which stops root on one machine
>> being root on another.  There is some setting you can change to open
>> that hole too if you really need to.
>>
>> MikeE
>>
> I suspect that I am using samba because the cli line I use to connect is:
>
> mount -t cifs //192.168.2.4/Backups /mnt/backups -o
> username=mick,password=mick
>
> That connects no problem when using sudo from the cli. I can read all
> the files there and copy them back individually to my main machine.
> But if I try to copy to it, I normally use nautilus, stuff from the
> main machine to the mounted directory it is forbidden.
>
> When I sudo grsync (I find rsync too intimidating with all those
> baffling parameters) it whips through all the files to send and about
> a quarter of them are shown in red with permission denied error 13.
> All the rest show up in black and you would think they are going over
> OK. But when I check on the backup machine none have been updated -
> even if I tell nautilus to refresh the list just in case it's missed
> something.
>
> The backup machine uses PCLinuxOS so I can use its very useful admin
> tools to check the samba shares and the backup file has the password
> for mick set and its read/write permissions set. When I cli ls -l that
> backup directory all the directories are drwxrwxrwx and all the files
> in them are rwxrwxrwx.
>
> So I have no backup facility now.
>
> I've looked at other backup solutions but they all seem to produce an
> archive file which can only be restored in full. I need a backup from
> which I can retrieve a single file if needed.
>
> Still baffled - sorry folks. No doubt I'm still a bear of very little
> brain. But I do appreciate all the suggestions I've received over the
> past 24 hours. Everyone seems to be bending their minds to my problem.
> No doubt it is a trivial thing, but it's beyond my minimal
> capabilities at the moment.
> MikeR
>
>
> _______________________________________________
> Kent mailing list
> Kent at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/kent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/kent/attachments/20111215/caaaea3f/attachment-0001.htm>