On 31/10/2012 14:49, Gary Rickert wrote:|
Thank you so much for the reply Dominic. I have
added comments where applicable below.
On Wed, Oct 31, 2012 at 12:52 AM, Dominic
From what I can tell this doesn't seem to be a problem
with rdiff-backup but some sort of issue with ssh?
both root and clientrdiff returns
ssh: connect to host server.server.com
port 22: Connection refused
If I add -pXXXX or use the Host from config I get:
/usr/bin/ssh-copy-id: ERROR: No identities found
I am not familiar with ssh-copy-id but checking on man
page it looks as if it does not support the -p option and
I guess you are using a non-standard ssh port? So don't
use ssh-copy-id, just add the public key manually; you
only have to do it once for each remote user (root and
clientrdiff). Do you know how to do this?
After trying to use ssh-copy-id, I did manually add the
key.pub. I only added this info because it was different
than the results I had seen previously from using the
command, successfully and had hoped it may be a clue I was
to dumb to understand. I can ssh to the
server with no password from both root and the clientrdiff
ok so there is no problem here
fuse user,noauto,ro 0 0
returns: mount: can't find
in /etc/fstab or /etc/mtab
Your second problem seems to be with sshfs, your syntax
looks strange to me. To mount the remote directory
'ToBeBackedUp' at say /home/clientrdiff/remotebackup I
think it should be like this:
$ mkdir -p /home/clientrdiff/mnt/remotebackup
$ sshfs address@hidden:/home/serverrdiff/ToBeBackedUp
/home/clientrdiff/mnt/remotebackup -o workaround=rename
But why are you using sshfs at all? You don't need this
for rdiff-backup, unless rdiff-backup cannot be installed
on either client and server. Using sshfs will make backups
slower and use more bandwidth.
I am just trying to follow whatever info I can pull from
all of the tutorials. If I don't need sshfs, and surely if
it will slow down the process, I won't use it.
good, no problem here either!
Here is an example of rdiff-backup doing a push backup
(i.e. run on client) using a non-standard ssh port 9222:
$ rdiff-backup --remote-schema "ssh -C -p9222 %s
rdiff-backup --server" /home/clientrdiff/ToBeBackedUp address@hidden::/home/serverrdiff/ToBeBackedUp
BTW both your machines are using a very old version of
rdiff-backup (1.0.5), you should use 1.2.8 (the last
stable version) or 1.3.3 (the last unstable, but seems to
I did a yum install rdiff-backup, and it is "yum" up to
date. I will look at upgrading it in a bit.
Very strange, but I would upgrade if you can. Lots of bugfixes since
1.0.5. Obviously you should upgrade both sides. I am not sure if
rdiff-backup repositories created with 1.0.5 are compatible with
repositories created with the latest-and-greatest - another reason
to upgrade asap. What distro are you using?
I did get the rdiff-backup to run, bth a my created backup
user and as root, with your help. Thanks much.
Now a few questions if I may.
The --remote-schema switch does what? Man says:
Specify an alternate method of connecting to
a remote computer. This is necessary to get rdiff-backup not
to use ssh for remote backups, or if, for instance,
rdiff-backup is not in the PATH on the remote
and then we use ssh. rdiff-backup is in usr/bin,
which is in the path. I tried without this and it does not
work, so what am I actually telling it?
You only need the --remote-schema because you are connecting to a
non-standard port, the normal connection assumes tcp port 22;
rdiff-backup does not have a -p option but using remote-schema in
this way achieves the same thing. I don't know why it doesn't work
unless you specify /usr/bin. If you do 'echo $PATH' this should show
/usr/bin among other directories (colon separated).
The --server switch does what? Is this saying to run the
rdiff-backup code on the system being backed up rather than
on the system pulling to data? I would prefer to have the
majority of the work load on the pulling server.
This is the instruction passed to the server - it tells the server
to run rdiff-backup in 'receive' mode ('server' mode) and wait to
receive data from the client. So then both machines run rdiff-backup
and the client tells the server what to do; the workload is shared
Again, I greatly appreciate your assistance.
My pleasure. I suggest that you reply to the newsgroup then the
information can benefit others (and you may get better advice too)
TimeDicer - Windows Backup and File Recovery