I seem to have an rsync versioning problem.
The sender is an old ClearOS6 server with rsynv 3.0.6 The receiver is a brand new Centos7-armv7 server with rsync 3.1.2
I am running rsync over ssh
Got the error:
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
And researching this it comes down to a versioning issue. But all I have found was to upgrade the 3.0.6 system! That will happen when I migrate to ClearOS7!
Is there some option to specify to get this to work?
rsync -ah --stats --delete -e "ssh" /var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
On Aug 3, 2018, at 8:57 AM, Robert Moskowitz rgm@htt-consult.com wrote:
I seem to have an rsync versioning problem.
Have you ruled out the other causes of that error? For instance:
https://askubuntu.com/a/716911
And researching this it comes down to a versioning issue.
That seems rather unlikely for such an old and stable tool as rsync, and especially for two versions with the same major version number. If you’d said rsync 2 and 3 or we were talking about a tool that still hadn’t hit 1.0 yet, I’d believe the protocol was still in flux, but rsync is 22 years old now.
On the other hand, 3.0.6 is nine years old now, so maybe.
rsync -ah --stats --delete -e “ssh"
You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default. It was released in 2004.
/var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
Rsync won’t create multiple levels of directories on the target. It will only create up to one level of missing directories. Try this:
$ ssh x.htt-consult.com 'mkdir -p /media/backup/homebase/var/flexshare/shares/'
Then retry the rsync.
On 08/03/2018 11:07 AM, Warren Young wrote:
On Aug 3, 2018, at 8:57 AM, Robert Moskowitz rgm@htt-consult.com wrote:
I seem to have an rsync versioning problem.
Have you ruled out the other causes of that error? For instance:
https://askubuntu.com/a/716911
yeah. It is backups, not backup. Oops.
And researching this it comes down to a versioning issue.
That seems rather unlikely for such an old and stable tool as rsync, and especially for two versions with the same major version number. If you’d said rsync 2 and 3 or we were talking about a tool that still hadn’t hit 1.0 yet, I’d believe the protocol was still in flux, but rsync is 22 years old now.
On the other hand, 3.0.6 is nine years old now, so maybe.
rsync -ah --stats --delete -e “ssh"
You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default. It was released in 2004.
How do I specify -p and -l that I cut out of my example?
"ssh -pnnn -luserid"
/var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
Rsync won’t create multiple levels of directories on the target. It will only create up to one level of missing directories. Try this:
$ ssh x.htt-consult.com 'mkdir -p /media/backup/homebase/var/flexshare/shares/'
Oh? I have been doing this in one shape or form for a long time. It is running right now, copying all the sub dirs and creating any new needed with:
rsync -ah --stats --delete -e "ssh -pnnnn -l user" /var/flexshare/shares/ nevia.htt-consult.com:/media/WD3TB01/backups/homebase/var/flexshare/shares
Note the source ending with /
That is needed. Without it, it creates a shares directory under the target directory.
Then retry the rsync. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Aug 3, 2018, at 9:59 AM, Robert Moskowitz rgm@htt-consult.com wrote:
You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default. It was released in 2004.
How do I specify -p and -l that I cut out of my example?
Add it to ~/.ssh/config:
Host nevia.htt-consult.com Port 2222 User rmoskowitz
You might not think of rsync as paying attention to this file, which is correct, because it doesn’t. But since it is executing ssh under the hood, and ssh *does* pay attention to that file, it takes effect.
If you’re creating that file for the first time, be sure to chmod 600 it. Ssh will ignore it if it’s not locked-down. RTFM for details.
/var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
Rsync won’t create multiple levels of directories on the target. It will only create up to one level of missing directories. Try this:
$ ssh x.htt-consult.com 'mkdir -p /media/backup/homebase/var/flexshare/shares/'Oh? I have been doing this in one shape or form for a long time.
Let me clarify:
If only /media/backup exists on the remote machine, I believe you’ll end up with /media/backup/shares with that command.
If at least /media/backup/homebase/var/flexshare exists, rsync will always create “shares” under “flexshare" on the remote host.
Anything below that level will also be created, regardless of depth. I’m speaking only of the target path given as the last argument to rsync here, not of the source machine’s directories discovered during the sync process.
It’s possible this behavior changed since I last looked at it. I ran into this issue many years ago and now ensure that the target path passed to the rsync command exists on the remote host before starting the sync.
Warren, Thanks!
On 08/03/2018 12:17 PM, Warren Young wrote:
On Aug 3, 2018, at 9:59 AM, Robert Moskowitz rgm@htt-consult.com wrote:
You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default. It was released in 2004.
How do I specify -p and -l that I cut out of my example?
Add it to ~/.ssh/config:
Host nevia.htt-consult.com Port 2222 User rmoskowitz
I will look into this and rtfm :)
I have been doing this for so long, I never paid attention to the change. The man pages I originally used said to use -e ssh
You might not think of rsync as paying attention to this file, which is correct, because it doesn’t. But since it is executing ssh under the hood, and ssh *does* pay attention to that file, it takes effect.
If you’re creating that file for the first time, be sure to chmod 600 it. Ssh will ignore it if it’s not locked-down. RTFM for details.
And then still ask Dr. Google. Page's father WAS one of my profs at MSU.
/var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
Rsync won’t create multiple levels of directories on the target. It will only create up to one level of missing directories. Try this:
$ ssh x.htt-consult.com 'mkdir -p /media/backup/homebase/var/flexshare/shares/'Oh? I have been doing this in one shape or form for a long time.
Let me clarify:
If only /media/backup exists on the remote machine, I believe you’ll end up with /media/backup/shares with that command.
If at least /media/backup/homebase/var/flexshare exists, rsync will always create “shares” under “flexshare" on the remote host.
Anything below that level will also be created, regardless of depth. I’m speaking only of the target path given as the last argument to rsync here, not of the source machine’s directories discovered during the sync process.
It’s possible this behavior changed since I last looked at it. I ran into this issue many years ago and now ensure that the target path passed to the rsync command exists on the remote host before starting the sync.
Always a challenge to get this right and get the right behavior. I use rsync for backing up my data from my notebook to a USB drive. Also when I was active in IEEE 802, at the meetings I could rsync all the documents off the local server. The public server does not support rsync. Plus I rsync all the IETF RFCs and drafts every night.
So I have a lot of old habits.
On Aug 3, 2018, at 10:17 AM, Warren Young warren@etr-usa.com wrote:
It’s possible this behavior changed since I last looked at it.
It looks like the rsync version shipping with CentOS 7 will actually complain if multiple target directory levels are missing. With only ~/tmp existing on the target machine, this command:
$ rsync -a path/to/stuff remote-host:tmp/foo/bar
gives:
rsync: mkdir "/home/USER/tmp/foo/bar" failed: No such file or directory (2) rsync error: error in file IO (code 11) at main.c(657) [Receiver=3.1.2]
I recall a confusing, softer failure mode, so perhaps they decided this would be better handled with a hard failure to avoid some end user confusion. (And probably some support email traffic!)
The trailing slash on the source path affects the remote result once you get past this issue, but adding a slash doesn’t prevent the error in this condition.
Warren,
Just want to say thanks. I have my automated backups going now. Good old cronie.
Since I have a cat6 line to my neighbor (as a favor for their net access), I only have to move the backup box to his house and I have off-site backups for $150 outlay (arm SOC and 4 TB drive) and <$50/yr electric (our rate is ~$0.21/KWH). You can't buy cloud storage for that price.
On 08/03/2018 12:17 PM, Warren Young wrote:
On Aug 3, 2018, at 9:59 AM, Robert Moskowitz rgm@htt-consult.com wrote:
You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default. It was released in 2004.
How do I specify -p and -l that I cut out of my example?
Add it to ~/.ssh/config:
Host nevia.htt-consult.com Port 2222 User rmoskowitzYou might not think of rsync as paying attention to this file, which is correct, because it doesn’t. But since it is executing ssh under the hood, and ssh *does* pay attention to that file, it takes effect.
If you’re creating that file for the first time, be sure to chmod 600 it. Ssh will ignore it if it’s not locked-down. RTFM for details.
/var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
Rsync won’t create multiple levels of directories on the target. It will only create up to one level of missing directories. Try this:
$ ssh x.htt-consult.com 'mkdir -p /media/backup/homebase/var/flexshare/shares/'Oh? I have been doing this in one shape or form for a long time.
Let me clarify:
If only /media/backup exists on the remote machine, I believe you’ll end up with /media/backup/shares with that command.
If at least /media/backup/homebase/var/flexshare exists, rsync will always create “shares” under “flexshare" on the remote host.
Anything below that level will also be created, regardless of depth. I’m speaking only of the target path given as the last argument to rsync here, not of the source machine’s directories discovered during the sync process.
It’s possible this behavior changed since I last looked at it. I ran into this issue many years ago and now ensure that the target path passed to the rsync command exists on the remote host before starting the sync. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Robert Moskowitz -
Warren Young