I decided to split my ClearOS server into two:
1) the Gateway/LAN system, running ClearOS 6.9, named ClearOS.lan
2) a new storage server w/o firewall, also running BackupPC, on ClearOS7, named ClearOS.san.
Most of this is running fine. I only have a problem with BackupPC, which I did not have before when anything was still on one system.
For my Windows clients I use rsyncd and they are all being backed up fine.
Backing up my gateway system ClearOS.lan is as of yet not possible as XFER is causing a problem, generating a "Unable to read 4 bytes" message.
This means XFER is returning an empty set of directory names. It seems to be a persistent problem and on various sites where this is consistently attributed to SSH-problems or flaws in /etc/hosts. In my case I can joyfully tunnel from ClearOS.san to ClearOS.lan and back, so it is not a SSH-problem and my hosts files are OK.
I decided to manually run the XFER command from the XFER ErrorLog XferLOG.bad.z, directly as root on the ClearOS.lan side. With empty options deleted it shows:
So, the problem is the current directory. Running the command again without the " --ignore-times ." part returns correct info for BackupPC to handle, but obviously starts with the "." part for the current directory.
I decided to bring up the problem on this forum as it seems very persistent on various sites and always - wrongly in my case - is attributed to SSH. Still, I haven't found a solution for this problem, although that doesn't seem too difficult to think of. So, if anybody has a good idea to fake XFER a little bit, I think we might be helpful to many people having the same problem and looking in the wrong direction.
1) the Gateway/LAN system, running ClearOS 6.9, named ClearOS.lan
2) a new storage server w/o firewall, also running BackupPC, on ClearOS7, named ClearOS.san.
Most of this is running fine. I only have a problem with BackupPC, which I did not have before when anything was still on one system.
For my Windows clients I use rsyncd and they are all being backed up fine.
Backing up my gateway system ClearOS.lan is as of yet not possible as XFER is causing a problem, generating a "Unable to read 4 bytes" message.
This means XFER is returning an empty set of directory names. It seems to be a persistent problem and on various sites where this is consistently attributed to SSH-problems or flaws in /etc/hosts. In my case I can joyfully tunnel from ClearOS.san to ClearOS.lan and back, so it is not a SSH-problem and my hosts files are OK.
I decided to manually run the XFER command from the XFER ErrorLog XferLOG.bad.z, directly as root on the ClearOS.lan side. With empty options deleted it shows:
/usr/bin/rsync --group -D --block-size=2048 --ignore-times . /
skipping directory .
So, the problem is the current directory. Running the command again without the " --ignore-times ." part returns correct info for BackupPC to handle, but obviously starts with the "." part for the current directory.
I decided to bring up the problem on this forum as it seems very persistent on various sites and always - wrongly in my case - is attributed to SSH. Still, I haven't found a solution for this problem, although that doesn't seem too difficult to think of. So, if anybody has a good idea to fake XFER a little bit, I think we might be helpful to many people having the same problem and looking in the wrong direction.
In BackupPC
Share this post:
Responses (4)
-
Accepted Answer
That's correct, Nick. I more or less solved the problem. I was caused by a symlink that was interpreted as "irregular file" thus causing BackupPC not to know what to do about it. Leaving out the symlink made a good start of BackupPC. The more definitive solution can probably be achieved through RsyncArgsExtra but I'm still working on it. I will eventually find that out.Thanks for the help. I certainly got my first ClearOS7 experience, that's the good part of it. -
Accepted Answer
-
Accepted Answer
Thanks, Nick. BackupPC is an interesting program. In the background it composes various rsync commands to be run by a local user on a different machine. This is achieved through a SSH tunnel. If this process fails BackupPC will just report there was a transfer problem. Regularly this is caused by wrong configuration of the SSH tunnel. In my case the problem is with the rsync command. The command is fine, but the result is unacceptable by BackupPC. As the rsync commands are composed within the program, outside of user influence, there is little yoy can do about it. We need to think of different measures to generate rsync output that is acceptable by BackupPC.
Roel -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »