<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
That looks an interesting solution to the problem Alan. Thanks for
that, and also for spelling it out in such detail. Much appreciated.<br>
Yesterday I managed to follow the advice from another in the group
who suggested mounting the remote backup directory in my user
directory and then copying each directory selected for backup to it.
That worked and I was thinking of typing that out to a script today.
That sort of thing is quite an adventure for me so I'll probably try
that first.<br>
Such nice folk in this group. Many thanks to all.<br>
MikeR <br>
<br>
<br>
On 15/12/11 17:40, Alan Buchel wrote:
<blockquote cite="mid:4EEA30F7.8020701@communitytechnology.org.uk"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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:<br>
<br>
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:<br>
<br>
/dev<br>
/media<br>
/mnt<br>
/home/dummyuser_that_dont_need_backup<br>
/home/phileas/.Trash<br>
<br>
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:<br>
( achieve this using "sudo su -")<br>
<br>
rsync -azv / <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:root@192.168.1.2:/backupsdirectory">root@192.168.1.2:/backupsdirectory</a>
--exclude-from=/file.exceptions<br>
<br>
-a maintains subdirs, ownership & permissions<br>
-z compresses over network<br>
-v verbose<br>
<br>
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:<br>
<br>
rsync -azv -e "ssh -i /root/private.key" /
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:root@192.168.1.2:/backupsdirectory">root@192.168.1.2:/backupsdirectory</a>
--exclude-from=/file.exceptions
--log-file /var/log/backup.log<br>
<br>
Alan<br>
<br>
On 15/12/11 12:29, Michael E. Rentell wrote:
<blockquote cite="mid:4EE9E834.6030009@ntlworld.com" type="cite">On
15/12/11
11:41, Mike Evans wrote: <br>
<blockquote type="cite">Sorry to come to this late. <br>
<br>
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. <br>
<br>
MikeE <br>
<br>
</blockquote>
I suspect that I am using samba because the cli line I use to
connect
is: <br>
<br>
mount -t cifs //192.168.2.4/Backups /mnt/backups -o
username=mick,password=mick <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
So I have no backup facility now. <br>
<br>
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. <br>
<br>
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. <br>
MikeR <br>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Kent mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kent@mailman.lug.org.uk">Kent@mailman.lug.org.uk</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mailman.lug.org.uk/mailman/listinfo/kent">https://mailman.lug.org.uk/mailman/listinfo/kent</a></pre>
</blockquote>
</blockquote>
<br>
</body>
</html>