rsync VS scp

There are two main differences between rsync and scp. 

 

  • Before a file is transferred rsync takes the checksums of the file 
(MD5 and adler-32 I believe) and sends them to the receiver. 
After a file is transferred the receiver verifies
the data integrity using those checksums. 




 


scp does not have such mechanism. scp uses ssh to transfer the data and although


ssh uses checksums on the packet level that's a different story 




    

  • Another difference is what happens during a transfer retry,
    

    • 





While scp will ignore any partially transferred set of files and


overwrite them on the receiving end,






 


but rsync is more clever than that. Rsync will check the destination for any


files present and if their signature matches that of the files on the


sender side it will not retransmit these files.


It might be possible to overwrite this behavior.







































Comments











Post a Comment



















Popular posts from this blog









Resolved: DOCKER: Error response from daemon: Could not attach to network / rpc error: code = 7 desc = network not manually attachable.




















Image







 I got this error: 'docker: Error response from daemon: Could not attach to  network <nw-name>: rpc error: code = 7 desc = network <nw-name> not  manually attachable.' when i try to create the container on the overlay network  on swarm mode enabled,              In docker 1.12 with swarm mode enabled, "Swarm" scoped networks (see the  "SCOPE" column) cannot be used for docker run, only for services   and now it has been rectified.    I'm using updated version of docker, but still why i'm experiencing the error  ?               because the network just created but not manually attachable. To fix the  issue we gonna use --attachable flag while creating network.     [ --attachable             Enable manual container attachment ]                  (Need to create service on the overlay network, so that the overlay network  will available / list on the worker node)         docker inspect attnw  (attnw is our test network)should show your own  c








Read more










yum failed 6 times. Cannot continue!





















 Error while cPanel installation:   (ERROR):   - ssystem [EXIT_CODE] '/usr/bin/yum' exited with 1 (ignored)  (DEBUG):   - ssystem [END]  (FATAL): yum failed 6 times.  Cannot continue!   fix:   It looks like you have some name resolution issues on the server. Just  run the following commands on your server and it will resolve the name  resolution issues.   #echo "nameserver 8.8.8.8" >> /etc/resolv.conf  #echo "nameserver 8.8.4.4" >> /etc/resolv.conf   if it is not working properly still facing same error, then here we go,   # rpm -e --nodeps bind-chroot  # rpm -e --nodeps bind   # yum install bind  








Read more










unexpectedly shrunk window (repaired) in dmesg log - TCP Peer





















 Don't Panic,    This normally occurs when a client decides to reduce its TCP window size, without the server expecting it. This can be the case when fragmentation is an issue, or when the client is using an embedded device with very little NIC buffer memory. This is a completely normal behaviour, and you’re likely to see quite a few such packets in your log. The messages are informational only, and are used to debug networking issues. I’d be worried if you saw hundreds of thousands of these packets, since there are attacks that involve packet fragmentation and small window sizes, but otherwise it’s just the normal sort of noise you should expect to see on any internet-facing network. In fact, the “repaired” part of your message is showing that your network driver fixed the issue, which is usually done by concatenating the payloads of two fragmented packets together. Shouldn’t be an issue at all.   … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …   








Read more