From: denon <de...@de...> - 2003-12-10 16:46:30
|
Darn .. I guess rsync just isn't meant to be. Has Craig been around lately? Seems like he's usually the first to comment on these types of issues. I guess I may need to bring out backup server back on-site, unless I can figure out how to get it working remotely with a little latency. -d At 07:08 AM 12/10/2003, you wrote: >Well, I've now hit a brick wall and I can't really continue on any >further. I managed to get backuppc to run this command: >rsync -auvroge ssh -z --ignore-times administrator@james-d:/cygdrive/f . > >I had to edit the Rsync.pm library as well as the config.pl file. Also had >to do a few other things for it to get it to do that line. When I run that >on the command line, it works, so I thought if I could put that into >backuppc, then I may have a chance. But, no, I recieve this error: >exiting after signal PIPE > >So I am really out of ideas now. I don't know enough about perl and >backuppc's internals to fix it. I thought I would have trouble finding the >part that is the difference between an incremental and full backup but its >really just one line that determines that, so that was ok. At least if I >do manage to get this working, its not going to effect anything else. Of >course, I have to get the restore working via this method too, but that >won't be hard once the backup part is figured out. > >Anyway, I don't really know what that error means. Something about the >pipe that it's writing to is broken, so how can I find out what pipe it's >writing to and cancel it? I have a feeling that its for the other command >(ssh -l host rsync etc....) that was being run. Anyway I probably >shouldn't be asking these questions. To get it working this way then I >probably have to edit a whole heap of other parts as well and I'm really >not comfortable with that yet. Oh well! I think I will just wait for a >while and see if someone else can come up with another solution. > > >On Wed, 2003-12-10 at 16:54, Ben wrote: >>Yeah thats interesting that you say that, because I also can run rsync >>manually and it works. I'm going to change the way backuppc uses rsync >>and make it run it the exact same way as I run it on the command line. >>I'm going to do all this tonight and I'll let you know what I find. I'm >>going to work on it a lot tonight and will get it going if it's the last >>thing I do! >> >>On Wed, 2003-12-10 at 13:02, Marlin Prowell wrote: >>> >>> >>>At 12:19 PM 12/10/2003 +1100, Ben wrote: >>> >Ahh I see. I don't think this a cygwin problem. I have run the same >>> >command across two linux boxes with the same result; it just hangs there. >>> >>>I am a new adapter of BackupPC. I've been using it about 3 weeks. I use >>>it to back up about 10 Windows boxes and 10 FreeBSD boxes. My backup >>>server is a FreeBSD 4.8 box. >>> >>>I, too, have had problems with rsync and ssh. >>> >>>When I first configured the backups for the FreeBSD boxes, I set them up to >>>use rsyncd. The first full backup would succeed. Afterwards, any >>>incremental backup, unless really small, would hang. Even full backups, if >>>not the very first one, would often fail. >>> >>>So I tried rsync. Same behavior. The first full backup would succeed, but >>>any incremental backup would hang. >>> >>>All along, the Windows boxes (not using rsync) have been working fine. >>> >>>I did some debugging. I found several examples where the list of files >>>sent from the remote was corrupted, either strange characters or >>>missing/changed directory names. Like this: >>> >>>Got file (15936 of 15939): >>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/policies-encumbered.html >>>Got file (15937 of 15939): >>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html >>>Got file (15938 of 15939): >>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/ipc.html >>>Got file (15939 of 16144): sockets-essential-functions.html/signals.html >>>Got file (15940 of 16144): sockets-essential-functions.html/sockets.html >>>Got file (15941 of 16144): >>>sockets-essential-functions.html/sockets-diversity.html >>>Got file (15942 of 16144): >>>sockets-essential-functions.html/sockets-protocols.html >>>Got file (15943 of 16144): >>>sockets-essential-functions.html/sockets-model.html >>>Got file (15944 of 16144): >>>sockets-essential-functions.html/sockets-essential-functions.html >>>Got file (15945 of 16144): >>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/sockets-helper-functions.html >>>Got file (15946 of 16144): >>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/sockets-concurrent-servers.html >>>Got file (15947 of 16144): >>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html >>> >>>Files 15938 - 15944 have their directory path screwed up, and rsync failed >>>(of course) when it tried to download the non-existent files. >>> >>>It also looked like the partial file transfer logic in rsync was not >>>working, so, with a one line change in BackupPC's rsync code, I forced >>>rsync to send entire files when they had changed, not just the changed >>>blocks. >>> >>>After this last change, rsync no longer hung. But I got other errors >>>reporting MD4 checksum errors. >>> >>>So I switched to using tar for backing up the FreeBSD machines. And, for >>>the last 4 days, the backups have been flawless. >>> >>>Now I'm not writing to complain about BackupPC. Nothing could be further >>>from the truth. I think it is an outstanding piece of software. I watched >>>several Windows administrators spend years trying to get tape backups to >>>work with expensive commercial software. They never succeeded. BackupPC >>>does its job and does it well. >>> >>>I suspect that there is some subtle problem with rsync that *some* of us >>>are tripping over. I'm willing to track it down, but I want to make sure >>>my backups are rock-solid first. Then I'll track down the rsync problems. >>> >>>I suspect that some of you have rsync backups working just fine, and are >>>shaking your heads, wondering what we must have screwed up. Believe me, >>>I've tried many different things and have not been successful. I also can >>>run rsync manually, and it will always succeed. Remember, BackupPC's half >>>of the rsync transfer is written in Perl and C, and is not the standard >>>rsync implementation. >>> >>>So, maybe it's something in FreeBSD (I really doubt it), or maybe it's >>>because I'm using perl 5.6.1, or maybe it's OpenSSH 3.5p1, or maybe it's >>>rsync 2.5.6, or maybe it's the C library that BackupPC uses, or some other >>>external piece of the puzzle. (Yes, I know about rsync 2.5.7). >>> >>>If you are using rsync for backups, and it is working just fine for you, >>>what programs and what OS are you using? Let us know for both the backup >>>server, and each of the clients, and please be specific about version >>>numbers. Maybe we can spot a pattern here. It would be nice to track this >>>down and make rsync backups solid for *everyone*. >>> >>> >>>Marlin Prowell >>>Cadalog, Inc. |
From: <cba...@us...> - 2003-12-18 10:57:09
|
"Allen Bolderoff" writes: > I have a filesystem running on debian woody of around 130GB, with several > largish files. (1 up to 15GB). > > Everything worked fine until we put the 15GB windows 2000 Server backup.bbf > file in there, now we too are getting the ALRM error on the incremental > backup > > This is on a direct connected 10/100/1000 ethernet card to Ethernet card > setup. - I consistently get 5MB/s reported by backuppc. > > And no, rsyncd did not work for this file 15GB when hosted by the windows > box, all it did is report the 15GB file as being 15EB Rsyncd using Cygwin 1.3.x has a 2GB file limit. Cygwin 1.5.x supports 64 bit file sizes, and BackupPC's rsyncd should support >4GB files. Although I haven't tested it yet, rsyncd with cygwin 1.5.x on WinXX should support large files. Craig |
From: <cba...@us...> - 2003-12-26 13:13:02
|
"bruno.vernay" writes: > I have been stuck, with the same problem : rsync hanging with SSH. I > found that the solution was to add a "-q" to tell ssh to be quiet. The > documentation provides a test that you can run : > ssh -q -l root target whoami > test.txt > then, test.txt should contain only the word "root". I'm going to make -q -x the default in config.pl. > Also I didn't find any documentation for the "--sender" option > of rsync ??? It's an internal rsync option that is used to tell the other half of the rsync connection that it is the file sender. Craig |
From: <cba...@us...> - 2003-12-26 13:13:10
|
Les Mikesell writes: > On Tue, 2003-12-09 at 16:28, Ben wrote: > > > usr/bin/rsync --server --sender --numeric-ids --perms --owner --group > > --devices --links --times --block-size=2048 --recursive > > --modify-window=3601 --exclude=/cygdrive/c/System\ Volume\ Information > > --exclude=/cygdrive/c/IO.SYS --exclude=/cygdrive/c/NTDETECT.COM > > --exclude=/cygdrive/c/cygwin --exclude=/cygdrive/c/pagefile.sys > > --ignore-times . /cygdrive/c/ > > > > There is nowhere in that command that specifies to backup back to the > > backuppc host. It seems that it's backing up the '.' directory to the > > /cygdrive/c dir which is all local. I didn't get much time after that > > to play around with it. I'm going to have to wait until I get home > > tonight, I might try it with the actual rsync command and use ssh as > > the protocol. I'm fairly certain that's going to work then, I just > > need some time to play with it. > > The --server --sender options tell it that it is going to chat > on stdin/stdout and are the same you'll get running 'rsync -essh' > from another system manually. I update my Cygwin programs frequently > hoping that this will be fixed but so far I have never gotten > it to copy more than a few files before hanging. That's right. --server --sender options are internal and should not be used on the command-line. I have found rsync+ssh+cygwin to be unreliable. I have found rsyncd+cygwin to be reliable. Craig |
From: <cba...@us...> - 2003-12-26 13:13:16
|
Les Mikesell writes: > On Wed, 2003-12-10 at 07:08, Ben wrote: > > Well, I've now hit a brick wall and I can't really continue on any > > further. I managed to get backuppc to run this command: > > rsync -auvroge ssh -z --ignore-times administrator@james-d:/cygdrive/f > > . > > I don't think there is any chance of this working. BackupPC > doesn't use the real rsync on the local side. It emulates > rsync's behaviour in perl code and doesn't understand > the -z option. It does use the local ssh to run the > remote rsync program with the same undocumented options > that the real rsync would use to start it's remote partner. Exactly right! > However, I'd like to know if you can really use that > command line (with or without the -z) to copy a large > drive from a server running Cygwin, leaving backuppc out > of the picture. I've never succeeded in getting more than > a few megs across before it hangs up with both ends waiting > for each other. Eureka! That's the right test to run: use native rsync and eliminate BackupPC. If that doesn't work reliably, then there is no hope that BackupPC's rsync will either. Has anyone tried cygwin 1.5.x? I haven't upgraded from 1.3.x yet. One comment is that the rsync mail list has regular user questions about "broken PIPE", hangs etc. Some are configuration issues or pilot error. Some are specific to cygwin (eg: there is a notorious end-of-transfer hang when rsync/cygwin is the file receiver). One thing I would recommend trying is experimenting with the --blocking-io and --no-blocking-io rsync rsync options (these are ignored for rsyncd). Some ssh versions (in particular solaris) don't work correctly with the rsync default blocking-io type, and you must force the other. If you are running rsync outside BackupPC, just add --blocking-io (or --no-blocking-io) to the rsync command line. For BackupPC, just append it to $Conf{RsyncArgs}. Please tell me if this solves anyone's rsync problems and I will add it to the documentation. Craig |
From: <cba...@us...> - 2003-12-26 13:13:16
|
Marlin Prowell writes: > At 12:37 PM 12/10/2003 -0600, Les Mikesell wrote: > >Platforms other than Cygwin should work with sshd if rsync is > >up to date or you compile current source. > > OK, I'll bite. How do you know? > > I wrote yesterday: > >So, maybe it's something in FreeBSD (I really doubt it), or maybe it's > >because I'm using perl 5.6.1, or maybe it's OpenSSH 3.5p1, or maybe it's > >rsync 2.5.6, or maybe it's the C library that BackupPC uses, or some other > >external piece of the puzzle. (Yes, I know about rsync 2.5.7). > > > >If you are using rsync for backups, and it is working just fine for you, > >what programs and what OS are you using? Let us know for both the backup > >server, and each of the clients, and please be specific about version > >numbers. Maybe we can spot a pattern here. It would be nice to track > >this down and make rsync backups solid for *everyone*. > > Those look like pretty recent versions that I'm using. And no one has > written back saying that they have a rsync configuration that works. So, > how do you know? Rsync works great for me :). Server: perl 5.8.0 on a redhat 7.x machine, BackupPC 2.0.2 and/or CVS, File-RsyncP 0.44. Client #1: WinXP SP1 with rsync 2.5.6 (craigb-perf patch applied) with cygwin 1.3.22. Using rsyncd mode (no ssh). Client #2: RH 7.x machine, rsync 2.5.6 (craigb-perf patch applied). Using rsync with ssh. Not sure of ssh version (standard from RH 7.x). Craig PS: If there was a way to replicate anyone's rsync problems then I would be happy to debug it. PPS: please try the --blocking-io and --no-blocking-io options for rsync with ssh. |
From: Marlin P. <mb...@ca...> - 2003-12-29 17:56:38
|
At 05:13 AM 12/26/2003 -0800, cba...@us... wrote: >Rsync works great for me :). That I am sure about. There is too much work and too much polish to backuppc for me to think otherwise. So, there is some subtle problem somewhere... I have switched to using tar with backuppc and been very successfully and reliably backing up a cluster of twenty or so FreeBSD and Windows machines. Backuppc is a great set of programs. >PS: If there was a way to replicate anyone's rsync problems then I >would be happy to debug it. And I am willing also. I have spent many years hacking with perl and Unix, so I can probably lend some help here. Just as an additional point. I have used rsync a lot to keep a several 350 Gb file servers in sync. These are all FreeBSD machines, so I am used to running rsync outside of backuppc. One thing I have meant to ask. Do you have some test code that exercises File::RsyncP outside of backuppc? Perhaps a perl script or two that runs a simple file transfer by making File::RsyncP calls? I could try running those test scripts in my environment. It looks very simple to use, but if you already had working scripts, then I would not be fighting my misunderstandings of the RsyncP library. If not, then perhaps I'll write some... >PPS: please try the --blocking-io and --no-blocking-io options for >rsync with ssh. I will do that. But also, please note my email of Tue, 09 Dec 2003 18:02:33. I did catch *some* problem with the rsync communication, and it was not a blocking I/O issue, as the rsync exchange continued. It failed later when it tried to *use* the bogus file names. Marlin Prowell Cadalog, Inc. |
From: denon <de...@de...> - 2003-12-11 17:16:29
|
If anyone's interested, RSync did back up quite a few more files when I cranked the timeout, but it still fails on a ALRM error, even when the server is located on a local 100mbit switch. Has anyone actually gotten rsync to work with large files on win32 boxes? I guess I'll move back to SMB ... -d At 10:46 AM 12/10/2003, you wrote: >Darn .. I guess rsync just isn't meant to be. Has Craig been around >lately? Seems like he's usually the first to comment on these types of issues. > >I guess I may need to bring out backup server back on-site, unless I can >figure out how to get it working remotely with a little latency. > >-d > >At 07:08 AM 12/10/2003, you wrote: >>Well, I've now hit a brick wall and I can't really continue on any >>further. I managed to get backuppc to run this command: >>rsync -auvroge ssh -z --ignore-times administrator@james-d:/cygdrive/f . >> >>I had to edit the Rsync.pm library as well as the config.pl file. Also >>had to do a few other things for it to get it to do that line. When I run >>that on the command line, it works, so I thought if I could put that into >>backuppc, then I may have a chance. But, no, I recieve this error: >>exiting after signal PIPE >> >>So I am really out of ideas now. I don't know enough about perl and >>backuppc's internals to fix it. I thought I would have trouble finding >>the part that is the difference between an incremental and full backup >>but its really just one line that determines that, so that was ok. At >>least if I do manage to get this working, its not going to effect >>anything else. Of course, I have to get the restore working via this >>method too, but that won't be hard once the backup part is figured out. >> >>Anyway, I don't really know what that error means. Something about the >>pipe that it's writing to is broken, so how can I find out what pipe it's >>writing to and cancel it? I have a feeling that its for the other command >>(ssh -l host rsync etc....) that was being run. Anyway I probably >>shouldn't be asking these questions. To get it working this way then I >>probably have to edit a whole heap of other parts as well and I'm really >>not comfortable with that yet. Oh well! I think I will just wait for a >>while and see if someone else can come up with another solution. >> >> >>On Wed, 2003-12-10 at 16:54, Ben wrote: >>>Yeah thats interesting that you say that, because I also can run rsync >>>manually and it works. I'm going to change the way backuppc uses rsync >>>and make it run it the exact same way as I run it on the command line. >>>I'm going to do all this tonight and I'll let you know what I find. I'm >>>going to work on it a lot tonight and will get it going if it's the >>>last thing I do! >>> >>>On Wed, 2003-12-10 at 13:02, Marlin Prowell wrote: >>>> >>>> >>>> >>>>At 12:19 PM 12/10/2003 +1100, Ben wrote: >>>> >Ahh I see. I don't think this a cygwin problem. I have run the same >>>> >command across two linux boxes with the same result; it just hangs >>>>there. >>>> >>>>I am a new adapter of BackupPC. I've been using it about 3 >>>>weeks. I use >>>>it to back up about 10 Windows boxes and 10 FreeBSD boxes. My >>>>backup >>>>server is a FreeBSD 4.8 box. >>>> >>>>I, too, have had problems with rsync and ssh. >>>> >>>>When I first configured the backups for the FreeBSD boxes, I set them up >>>>to >>>>use rsyncd. The first full backup would succeed. Afterwards, >>>>any >>>>incremental backup, unless really small, would hang. Even full >>>>backups, if >>>>not the very first one, would often fail. >>>> >>>>So I tried rsync. Same behavior. The first full backup would >>>>succeed, but >>>>any incremental backup would hang. >>>> >>>>All along, the Windows boxes (not using rsync) have been working fine. >>>> >>>>I did some debugging. I found several examples where the list of >>>>files >>>>sent from the remote was corrupted, either strange characters or >>>>missing/changed directory names. Like this: >>>> >>>>Got file (15936 of 15939): >>>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/policies-encumbered.html >>>>Got file (15937 of 15939): >>>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html >>>>Got file (15938 of 15939): >>>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/ipc.html >>>>Got file (15939 of 16144): >>>>sockets-essential-functions.html/signals.html >>>>Got file (15940 of 16144): >>>>sockets-essential-functions.html/sockets.html >>>>Got file (15941 of 16144): >>>>sockets-essential-functions.html/sockets-diversity.html >>>>Got file (15942 of 16144): >>>>sockets-essential-functions.html/sockets-protocols.html >>>>Got file (15943 of 16144): >>>>sockets-essential-functions.html/sockets-model.html >>>>Got file (15944 of 16144): >>>>sockets-essential-functions.html/sockets-essential-functions.html >>>>Got file (15945 of 16144): >>>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/sockets-helper-functions.html >>>>Got file (15946 of 16144): >>>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/sockets-concurrent-servers.html >>>>Got file (15947 of 16144): >>>>usr/share/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html >>>> >>>>Files 15938 - 15944 have their directory path screwed up, and rsync >>>>failed >>>>(of course) when it tried to download the non-existent files. >>>> >>>>It also looked like the partial file transfer logic in rsync was not >>>>working, so, with a one line change in BackupPC's rsync code, I forced >>>>rsync to send entire files when they had changed, not just the changed >>>>blocks. >>>> >>>>After this last change, rsync no longer hung. But I got other >>>>errors >>>>reporting MD4 checksum errors. >>>> >>>>So I switched to using tar for backing up the FreeBSD machines. >>>>And, for >>>>the last 4 days, the backups have been flawless. >>>> >>>>Now I'm not writing to complain about BackupPC. Nothing could be >>>>further >>>>from the truth. I think it is an outstanding piece of >>>>software. I watched >>>>several Windows administrators spend years trying to get tape backups to >>>>work with expensive commercial software. They never >>>>succeeded. BackupPC >>>>does its job and does it well. >>>> >>>>I suspect that there is some subtle problem with rsync that *some* of us >>>>are tripping over. I'm willing to track it down, but I want to make >>>>sure >>>>my backups are rock-solid first. Then I'll track down the rsync >>>>problems. >>>> >>>>I suspect that some of you have rsync backups working just fine, and are >>>>shaking your heads, wondering what we must have screwed up. Believe >>>>me, >>>>I've tried many different things and have not been successful. I >>>>also can >>>>run rsync manually, and it will always succeed. Remember, >>>>BackupPC's half >>>>of the rsync transfer is written in Perl and C, and is not the standard >>>>rsync implementation. >>>> >>>>So, maybe it's something in FreeBSD (I really doubt it), or maybe it's >>>>because I'm using perl 5.6.1, or maybe it's OpenSSH 3.5p1, or maybe it's >>>>rsync 2.5.6, or maybe it's the C library that BackupPC uses, or some >>>>other >>>>external piece of the puzzle. (Yes, I know about rsync 2.5.7). >>>> >>>>If you are using rsync for backups, and it is working just fine for you, >>>>what programs and what OS are you using? Let us know for both the >>>>backup >>>>server, and each of the clients, and please be specific about version >>>>numbers. Maybe we can spot a pattern here. It would be nice >>>>to track this >>>>down and make rsync backups solid for *everyone*. >>>> >>>> >>>>Marlin Prowell >>>>Cadalog, >>>>Inc. |
From: Allen B. <al...@gi...> - 2003-12-11 23:14:07
|
I have a filesystem running on debian woody of around 130GB, with several largish files. (1 up to 15GB). Everything worked fine until we put the 15GB windows 2000 Server backup.bbf file in there, now we too are getting the ALRM error on the incremental backup This is on a direct connected 10/100/1000 ethernet card to Ethernet card setup. - I consistently get 5MB/s reported by backuppc. And no, rsyncd did not work for this file 15GB when hosted by the windows box, all it did is report the 15GB file as being 15EB _____ From: bac...@li... [mailto:bac...@li...] On Behalf Of denon Sent: Friday, 12 December 2003 3:46 AM To: bac...@li... Subject: Re: [BackupPC-users] rsync with ssh If anyone's interested, RSync did back up quite a few more files when I cranked the timeout, but it still fails on a ALRM error, even when the server is located on a local 100mbit switch. Has anyone actually gotten rsync to work with large files on win32 boxes? I guess I'll move back to SMB ... -d |
From: Ben <be...@uk...> - 2003-12-16 10:33:22
|
Finally I have got around to doing some more testing. I too tested it across a linux client and it worked perfectly, however it failed on the Windows machine. I have not finished testing though. I do know why it bombs out. It seems to be that any directory that contains mroe than 1500 files, will bomb out. Any less will be fine. I'm not sure if this is 1500 files total, or 1500 in one direcotry, im fairly sure though that it's 1500 files in one directory.=20 So, I will have to test this with the linux client but I doubt it's going to stuff up, however it is possible that it will. It's taken me ages to do all this testing. I did manage to get it to backup a dir with 2000 files in it, but that was a one off.=20 I upgraded rsync to the latest version on the windows client (even compiled it) but still no go. I don't think I'm ever going to solve this heh... On Fri, 2003-12-12 at 10:13, Allen Bolderoff wrote: > I have a filesystem running on debian woody of around 130GB, with > several largish files. (1 up to 15GB). >=20 > =20 >=20 > Everything worked fine until we put the 15GB windows 2000 Server > backup.bbf file in there, now we too are getting the ALRM error on the > incremental backup >=20 > =20 >=20 > This is on a direct connected 10/100/1000 ethernet card to Ethernet > card setup. =96 I consistently get 5MB/s reported by backuppc. >=20 > =20 >=20 > And no, rsyncd did not work for this file 15GB when hosted by the > windows box, all it did is report the 15GB file as being 15EB >=20 > =20 >=20 > =20 > ______________________________________________________________________ >=20 > From:bac...@li... > [mailto:bac...@li...] On Behalf Of denon > Sent: Friday, 12 December 2003 3:46 AM > To: bac...@li... > Subject: Re: [BackupPC-users] rsync with ssh >=20 >=20 > =20 >=20 > If anyone's interested, RSync did back up quite a few more files when > I cranked the timeout, but it still fails on a ALRM error, even when > the server is located on a local 100mbit switch. Has anyone actually > gotten rsync to work with large files on win32 boxes? I guess I'll > move back to SMB ... >=20 > -d >=20 >=20 |