Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #90474 > unrolled thread

Question about rsync operational modes - which is best? (Or are they all the same?)

Back to article view | Back to comp.os.linux.misc

Contents

  Question about rsync operational modes - which is best? (Or are they all the same?) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-25 00:27 +0000
    Re: Question about rsync operational modes - which is best? (Or are they all the same?) Rich <rich@example.invalid> - 2026-08-25 02:26 +0000
      Re: Question about rsync operational modes - which is best? (Or are they all the same?) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-25 07:18 +0000
        Re: Question about rsync operational modes - which is best? (Or are they all the same?) "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 11:50 +0200
          Re: Question about rsync operational modes - which is best? (Or are they all the same?) The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:33 +0100
        Re: Question about rsync operational modes - which is best? (Or are they all the same?) Rich <rich@example.invalid> - 2026-08-25 17:07 +0000
          Re: Question about rsync operational modes - which is best? (Or are they all the same?) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-25 18:02 +0000
          Re: Question about rsync operational modes - which is best? (Or are they all the same?) The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 20:14 +0100
        Re: Question about rsync operational modes - which is best? (Or are they all the same?) Rich <rich@example.invalid> - 2026-08-25 17:34 +0000
    Re: Question about rsync operational modes - which is best? (Or are they all the same?) c186282 <c186282@nnada.net> - 2026-08-25 03:03 -0400
      Re: Question about rsync operational modes - which is best? (Or are they all the same?) "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 11:53 +0200
        Re: Question about rsync operational modes - which is best? (Or are they all the same?) Rich <rich@example.invalid> - 2026-08-25 17:29 +0000
          Re: Question about rsync operational modes - which is best? (Or are they all the same?) c186282 <c186282@nnada.net> - 2026-08-26 03:40 -0400
        Re: Question about rsync operational modes - which is best? (Or are they all the same?) c186282 <c186282@nnada.net> - 2026-08-25 22:43 -0400
          Re: Question about rsync operational modes - which is best? (Or are they all the same?) "Carlos E.R." <robin_listas@es.invalid> - 2026-08-26 09:46 +0200
    Re: Question about rsync operational modes - which is best? (Or are they all the same?) Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-25 10:20 +0200

#90474 — Question about rsync operational modes - which is best? (Or are they all the same?)

I've recently done a large file copy between two Linux-ish machines, using
rsync.  It all went well, so no worries, but it made me wonder about
some things.

There are 3 ways that rsync can be setup to make the connection to the
remote machine:

    1) Using something like remotehost:/path/to/wherever
    as the destination.

    2) Running rsyncd on the remote host and connecting to that.

    3) Mounting the remote machine using sshfs (or similar, like NFS,
    Samba, or whatever else you might think of).  Then you can just do a
    normal-looking (it looks like a local-to-local) copy.

I usually use method 3, as it is the most flexible, since you can easily
check the contents of the target system while the copy is going on and
other things.  I use sshfs, because it is the easiest to setup and requires
no server side setup (other than an ssh server).

So, my questions boil down to:

    1) Is there any (significant) difference in performance between the 3
    methods?

    2) How exactly does method 1 work?  What do you need on the server side
    for it to work?  I know the answer is (or should be) "just an ssh
    server", but not all ssh servers are created equal.  I think it may
    depend on having the sftp module present, and I know of at least one
    ssh server where sftp is missing.

-- 
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Aspergers

[toc] | [next] | [standalone]

#90476

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> I've recently done a large file copy between two Linux-ish machines, using
> rsync.  It all went well, so no worries, but it made me wonder about
> some things.
> 
> There are 3 ways that rsync can be setup to make the connection to the
> remote machine:
> 
>     1) Using something like remotehost:/path/to/wherever
>     as the destination.
> 
>     2) Running rsyncd on the remote host and connecting to that.
> 
>     3) Mounting the remote machine using sshfs (or similar, like NFS,
>     Samba, or whatever else you might think of).  Then you can just do a
>     normal-looking (it looks like a local-to-local) copy.
> 
> I usually use method 3, as it is the most flexible, since you can easily
> check the contents of the target system while the copy is going on and
> other things.  I use sshfs, because it is the easiest to setup and requires
> no server side setup (other than an ssh server).
> 
> So, my questions boil down to:
> 
>     1) Is there any (significant) difference in performance between the 3
>     methods?

Yes.  sshfs runs through fuse, and fuse has significant overhead vs. 
having access to the actual destination filesystem (which is what 
methods 1 and 2 give the rsync deamon at the other end).

>     2) How exactly does method 1 work?  What do you need on the server side
>     for it to work?  I know the answer is (or should be) "just an ssh
>     server", but not all ssh servers are created equal.  I think it may

You need to be able to:

1) ssh to the destination machine, as the user that will be writing the 
files to the filesystem on the destination machine.  

2) rsync installed on the destination machine.


Your local rsync will launch a "slave" rsync, via ssh, on the 
destination machine to handle the remote end of the transfer.

Now, if the destination machine is Linux/Unix, and it has rsync 
installed (this is usual unless you go out of your way to "trim" down 
the installation) the only requirement is to setup ssh access (either 
by ssh keys (preferred) or allowing ssh password logins (will work, but 
setting up ssh keys is much more convient and more secure).

[toc] | [prev] | [next] | [standalone]

#90499

In article <116iufv$3ca8b$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
...
>> So, my questions boil down to:
>> 
>>     1) Is there any (significant) difference in performance between the 3
>>     methods?
>
>Yes.  sshfs runs through fuse, and fuse has significant overhead vs. 
>having access to the actual destination filesystem (which is what 
>methods 1 and 2 give the rsync deamon at the other end).

That's seems reasonable, but in practice, I doubt it matters.
The bottleneck is likely to be (*) the network throughput, more than
anything else.

(*) And, in practice, for this project, it was.

I wonder if anyone has ever actually measured what the fuse/sshfs overhead
is.

>>     2) How exactly does method 1 work?  What do you need on the server side
>>     for it to work?  I know the answer is (or should be) "just an ssh
>>     server", but not all ssh servers are created equal.  I think it may
>
>You need to be able to:
>
>1) ssh to the destination machine, as the user that will be writing the 
>files to the filesystem on the destination machine.  
>
>2) rsync installed on the destination machine.
>
>
>Your local rsync will launch a "slave" rsync, via ssh, on the 
>destination machine to handle the remote end of the transfer.

OK.  That makes sense.

>Now, if the destination machine is Linux/Unix, and it has rsync 
>installed (this is usual unless you go out of your way to "trim" down 
>the installation) the only requirement is to setup ssh access...

As it happens, in the instant case, the target machine was (is) running a
stripped down version of Linux and rsync is not installed there (nor can it
be).  But there is (just) enough there for sshfs to work.

-- 
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Aspergers

[toc] | [prev] | [next] | [standalone]

#90508

On 2026-08-25 09:18, Kenny McCormack wrote:
> In article <116iufv$3ca8b$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
> ...
>>> So, my questions boil down to:
>>>
>>>      1) Is there any (significant) difference in performance between the 3
>>>      methods?

I have never used method 3.

>>
>> Yes.  sshfs runs through fuse, and fuse has significant overhead vs.
>> having access to the actual destination filesystem (which is what
>> methods 1 and 2 give the rsync deamon at the other end).
> 
> That's seems reasonable, but in practice, I doubt it matters.
> The bottleneck is likely to be (*) the network throughput, more than
> anything else.

Depends on the power of the other machine.


I tried to do a copy of a disk partition using sshfs (as root) recently, 
and found that many files were refused due to i/o errors. Seems I did 
not write down the errors.

rsync against the rsync daemon in the other machine worked happily 
without errors.


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#90527

On 25/08/2026 10:50, Carlos E.R. wrote:
> rsync against the rsync daemon in the other machine worked happily 
> without errors.

I think that is what I use for my nightly backups of remote machines

-- 
There’s a mighty big difference between good, sound reasons and reasons 
that sound good.

Burton Hillis (William Vaughn, American columnist)

[toc] | [prev] | [next] | [standalone]

#90544

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <116iufv$3ca8b$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>>Now, if the destination machine is Linux/Unix, and it has rsync 
>>installed (this is usual unless you go out of your way to "trim" down 
>>the installation) the only requirement is to setup ssh access...
> 
> As it happens, in the instant case, the target machine was (is) 
> running a stripped down version of Linux and rsync is not installed 
> there (nor can it be).  But there is (just) enough there for sshfs to 
> work.

Well, in that case you appear to have no choice but to use sshfs as the 
"network transport" for the file data.

[toc] | [prev] | [next] | [standalone]

#90549

In article <116ki56$3tfgm$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <116iufv$3ca8b$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>>>Now, if the destination machine is Linux/Unix, and it has rsync 
>>>installed (this is usual unless you go out of your way to "trim" down 
>>>the installation) the only requirement is to setup ssh access...
>> 
>> As it happens, in the instant case, the target machine was (is) 
>> running a stripped down version of Linux and rsync is not installed 
>> there (nor can it be).  But there is (just) enough there for sshfs to 
>> work.
>
>Well, in that case you appear to have no choice but to use sshfs as the 
>"network transport" for the file data.

Quite so.

-- 
People seem to think that Youtube (and Facebook and Twitter and so on) is
(are) some sort of resource created for the public good.  Why they delude
themselves into believing this is beyond my ability to comprehend.

Usenet will always be here.  Longer than people remember what port 80 was for.

[toc] | [prev] | [next] | [standalone]

#90561

On 25/08/2026 18:07, Rich wrote:
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <116iufv$3ca8b$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>>> Now, if the destination machine is Linux/Unix, and it has rsync
>>> installed (this is usual unless you go out of your way to "trim" down
>>> the installation) the only requirement is to setup ssh access...
>>
>> As it happens, in the instant case, the target machine was (is)
>> running a stripped down version of Linux and rsync is not installed
>> there (nor can it be).  But there is (just) enough there for sshfs to
>> work.
> 
> Well, in that case you appear to have no choice but to use sshfs as the
> "network transport" for the file data.
> 
I decided on rsyncd


-- 
There’s a mighty big difference between good, sound reasons and reasons 
that sound good.

Burton Hillis (William Vaughn, American columnist)

[toc] | [prev] | [next] | [standalone]

#90546

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <116iufv$3ca8b$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
> ...
>>> So, my questions boil down to:
>>> 
>>>     1) Is there any (significant) difference in performance between 
>>>     the 3 methods?
>>
>>Yes.  sshfs runs through fuse, and fuse has significant overhead vs.  
>>having access to the actual destination filesystem (which is what 
>>methods 1 and 2 give the rsync deamon at the other end).
> 
> That's seems reasonable, but in practice, I doubt it matters.  The 
> bottleneck is likely to be (*) the network throughput, more than 
> anything else.
> 
> (*) And, in practice, for this project, it was.
> 
> I wonder if anyone has ever actually measured what the fuse/sshfs 
> overhead is.

For local filesystems, substantial vs. a native in-kernel filesystem 
driver.

For 'over the network', yes, network bandwidth (and, often more 
critically, network round trip latency) can often become the limiting 
factor.

On a low latency direct ethernet link between machines here, I can 
saturate the ethernet via NFS while an sshfs to the same machine runs 
at about 20% of network bandwidth.

But as you said, with no rsync installed at the destination, your only 
choice was/is sshfs.

[toc] | [prev] | [next] | [standalone]

#90497

On 8/24/26 20:27, Kenny McCormack wrote:
> I've recently done a large file copy between two Linux-ish machines, using
> rsync.  It all went well, so no worries, but it made me wonder about
> some things.


   'Rsync' is REALLY good - and a param or two for EVERY
   need. Used it - evoked from many pgms - for nearly 20
   years for backups.

   Only note, DO be careful with the "delete" option, because
   if a mount fails (and they CAN) it can do damage. PROBE
   for existing mounts BEFORE using rsync with 'delete'.

   Wrote a big nice Pascal backup pgm that called rsynch
   using 'delete'. After working well for a long time it
   did serious damage, had to re-load EVERYTHING from an
   older archive. Took like 24 hours.

   As said, the REAL problem was that the source mount
   got DROPPED somewhere along the way. 'Delete' relies
   on the source mount to work as designed.


> There are 3 ways that rsync can be setup to make the connection to the
> remote machine:
> 
>      1) Using something like remotehost:/path/to/wherever
>      as the destination.
> 
>      2) Running rsyncd on the remote host and connecting to that.
> 
>      3) Mounting the remote machine using sshfs (or similar, like NFS,
>      Samba, or whatever else you might think of).  Then you can just do a
>      normal-looking (it looks like a local-to-local) copy.

   Never used rsync as a daemon - just a straight-up app.
   There MAY be uses for the daemon mode, but never really
   saw it.

> I usually use method 3, as it is the most flexible, since you can easily
> check the contents of the target system while the copy is going on and
> other things.  I use sshfs, because it is the easiest to setup and requires
> no server side setup (other than an ssh server).
> 
> So, my questions boil down to:
> 
>      1) Is there any (significant) difference in performance between the 3
>      methods?
> 
>      2) How exactly does method 1 work?  What do you need on the server side
>      for it to work?  I know the answer is (or should be) "just an ssh
>      server", but not all ssh servers are created equal.  I think it may
>      depend on having the sftp module present, and I know of at least one
>      ssh server where sftp is missing.

   DID fool with sshfs ... decided it was Too Complicated
   for anything I wanted to do. Ordinary methods, using rsync,
   were more than good enough and easy to understand/monitor.

   IF you want to use the rsync client/server approach, well,
   it's pretty well documented and by all accounts very reliable.
   Rsync seems even 'smarter' than sshfs these days so by all
   means go with it.

   If you're worried about like a TEN PERCENT speed diff ...
   well, DON'T. Come ON now. Much more complexity is NOT
   worth a 10% gain ! If the 'faster' method craps you'll
   never figure out where it went wrong.

   Hmm ... 70s/80s/90s ... if you wanted a superior car
   you could buy German - like Mercedes-Benz - or something
   Japanese - like Honda or Toyota. Weird issues, the
   Germans thought 'superiority via complexity" - like
   25 gears/cogs/sensors to solve some little thing. In
   keeping with the Japanese philosophy, they practiced
   "superiority via simplicity". GUESS which one was
   more prone to defects and cost OUT THE ASS to fix ?

[toc] | [prev] | [next] | [standalone]

#90509

On 2026-08-25 09:03, c186282 wrote:
> On 8/24/26 20:27, Kenny McCormack wrote:
>> I've recently done a large file copy between two Linux-ish machines, 
>> using
>> rsync.  It all went well, so no worries, but it made me wonder about
>> some things.
> 
> 
>    'Rsync' is REALLY good - and a param or two for EVERY
>    need. Used it - evoked from many pgms - for nearly 20
>    years for backups.
> 
>    Only note, DO be careful with the "delete" option, because
>    if a mount fails (and they CAN) it can do damage. PROBE
>    for existing mounts BEFORE using rsync with 'delete'.
> 
>    Wrote a big nice Pascal backup pgm that called rsynch
>    using 'delete'. After working well for a long time it
>    did serious damage, had to re-load EVERYTHING from an
>    older archive. Took like 24 hours.
> 
>    As said, the REAL problem was that the source mount
>    got DROPPED somewhere along the way. 'Delete' relies
>    on the source mount to work as designed.


I concur. I deleted the wrong tree once. The source, by mistake.

...
-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#90545

Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2026-08-25 09:03, c186282 wrote:
>> On 8/24/26 20:27, Kenny McCormack wrote:
>>> I've recently done a large file copy between two Linux-ish 
>>> machines, using rsync.  It all went well, so no worries, but it 
>>> made me wonder about some things.
>> 
>> 
>>    'Rsync' is REALLY good - and a param or two for EVERY   need.  
>>  Used it - evoked from many pgms - for nearly 20   years for 
>>  backups.
>> 
>>    Only note, DO be careful with the "delete" option, because   if a 
>>  mount fails (and they CAN) it can do damage.  PROBE   for existing 
>>  mounts BEFORE using rsync with 'delete'.
>> 
>>    Wrote a big nice Pascal backup pgm that called rsynch   using 
>>  'delete'.  After working well for a long time it   did serious 
>>  damage, had to re-load EVERYTHING from an   older archive.  Took 
>>  like 24 hours.
>> 
>>    As said, the REAL problem was that the source mount   got DROPPED 
>>  somewhere along the way.  'Delete' relies   on the source mount to 
>>  work as designed.
> 
> I concur. I deleted the wrong tree once. The source, by mistake.

For interactive use, the --dry-run switch is always a good one to add 
first, just to see what will happen before committing to the changes.

Esp. given the differing interpretations of "dir-name" vs "dir-name/" 
by rsync.

But --dry-run does not help for automated background jobs when mounts 
disappear.  One does have to "check first that the filesystems exist" 
before launching the rsync run in those cases.

[toc] | [prev] | [next] | [standalone]

#90604

On 8/25/26 13:29, Rich wrote:
> Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2026-08-25 09:03, c186282 wrote:
>>> On 8/24/26 20:27, Kenny McCormack wrote:
>>>> I've recently done a large file copy between two Linux-ish
>>>> machines, using rsync.  It all went well, so no worries, but it
>>>> made me wonder about some things.
>>>
>>>
>>>     'Rsync' is REALLY good - and a param or two for EVERY   need.
>>>   Used it - evoked from many pgms - for nearly 20   years for
>>>   backups.
>>>
>>>     Only note, DO be careful with the "delete" option, because   if a
>>>   mount fails (and they CAN) it can do damage.  PROBE   for existing
>>>   mounts BEFORE using rsync with 'delete'.
>>>
>>>     Wrote a big nice Pascal backup pgm that called rsynch   using
>>>   'delete'.  After working well for a long time it   did serious
>>>   damage, had to re-load EVERYTHING from an   older archive.  Took
>>>   like 24 hours.
>>>
>>>     As said, the REAL problem was that the source mount   got DROPPED
>>>   somewhere along the way.  'Delete' relies   on the source mount to
>>>   work as designed.
>>
>> I concur. I deleted the wrong tree once. The source, by mistake.
> 
> For interactive use, the --dry-run switch is always a good one to add
> first, just to see what will happen before committing to the changes.

   Alas my uses were NOT "interactive" - but in
   scripts/pgms. Had to try and 'survey the land'
   in code before doing anything. USUALLY worked.

> Esp. given the differing interpretations of "dir-name" vs "dir-name/"
> by rsync.
> 
> But --dry-run does not help for automated background jobs when mounts
> disappear.  One does have to "check first that the filesystems exist"
> before launching the rsync run in those cases.

   Alas rsync does not seem to have any option for
   ensuring a mount is STILL connected before doing
   anything. Did the best I could, but ONCE in a
   while ......

   So, keep MULTIPLE backups.

   Ensuring a mount exists is EASY, /proc/mounts.
   Python can easily do a pattern match to find
   what you're looking for. But rsync often does
   BIG dir trees ... what if the mount drops
   in the middle of that ? Been there, seen it,
   suffered for it.

[toc] | [prev] | [next] | [standalone]

#90581

On 8/25/26 05:53, Carlos E.R. wrote:
> On 2026-08-25 09:03, c186282 wrote:
>> On 8/24/26 20:27, Kenny McCormack wrote:
>>> I've recently done a large file copy between two Linux-ish machines, 
>>> using
>>> rsync.  It all went well, so no worries, but it made me wonder about
>>> some things.
>>
>>
>>    'Rsync' is REALLY good - and a param or two for EVERY
>>    need. Used it - evoked from many pgms - for nearly 20
>>    years for backups.
>>
>>    Only note, DO be careful with the "delete" option, because
>>    if a mount fails (and they CAN) it can do damage. PROBE
>>    for existing mounts BEFORE using rsync with 'delete'.
>>
>>    Wrote a big nice Pascal backup pgm that called rsynch
>>    using 'delete'. After working well for a long time it
>>    did serious damage, had to re-load EVERYTHING from an
>>    older archive. Took like 24 hours.
>>
>>    As said, the REAL problem was that the source mount
>>    got DROPPED somewhere along the way. 'Delete' relies
>>    on the source mount to work as designed.
> 
> 
> I concur. I deleted the wrong tree once. The source, by mistake.

   Yep. 'Delete' looks at the source to decide what
   to cut from the dest. If the source suddenly becomes
   'empty' then it decides ALL the backup files are
   too old and zaps them.

   There's no perfect fix for this so far as I know.
   In theory you'd have to confirm the source was
   still mounted between EVERY operation. Best cheat
   is to confirm yourself JUST before evoking rsync.
   That can save a lot of yer stuff.

   I'd rigged a 'reverse delete' to get rid of obsolete
   source files. Employees tended to copy/paste rather
   than cut/paste, often involving large dir trees.
   It was the reverse delete that got me. Rsync WAS
   doing exactly what I told it to do, but ...

[toc] | [prev] | [next] | [standalone]

#90605

On 2026-08-26 04:43, c186282 wrote:
> On 8/25/26 05:53, Carlos E.R. wrote:
>> On 2026-08-25 09:03, c186282 wrote:
>>> On 8/24/26 20:27, Kenny McCormack wrote:
>>>> I've recently done a large file copy between two Linux-ish machines, 
>>>> using
>>>> rsync.  It all went well, so no worries, but it made me wonder about
>>>> some things.
>>>
>>>
>>>    'Rsync' is REALLY good - and a param or two for EVERY
>>>    need. Used it - evoked from many pgms - for nearly 20
>>>    years for backups.
>>>
>>>    Only note, DO be careful with the "delete" option, because
>>>    if a mount fails (and they CAN) it can do damage. PROBE
>>>    for existing mounts BEFORE using rsync with 'delete'.
>>>
>>>    Wrote a big nice Pascal backup pgm that called rsynch
>>>    using 'delete'. After working well for a long time it
>>>    did serious damage, had to re-load EVERYTHING from an
>>>    older archive. Took like 24 hours.
>>>
>>>    As said, the REAL problem was that the source mount
>>>    got DROPPED somewhere along the way. 'Delete' relies
>>>    on the source mount to work as designed.
>>
>>
>> I concur. I deleted the wrong tree once. The source, by mistake.
> 
>    Yep. 'Delete' looks at the source to decide what
>    to cut from the dest. If the source suddenly becomes
>    'empty' then it decides ALL the backup files are
>    too old and zaps them.
> 
>    There's no perfect fix for this so far as I know.
>    In theory you'd have to confirm the source was
>    still mounted between EVERY operation. Best cheat
>    is to confirm yourself JUST before evoking rsync.
>    That can save a lot of yer stuff.

If you do:

rsync --link-dest=PREVIOUS_BCK SOURCE DEST

and DEST is a new path, it will not delete the existing backup in 
PREVIOUS_BCK.

> 
>    I'd rigged a 'reverse delete' to get rid of obsolete
>    source files. Employees tended to copy/paste rather
>    than cut/paste, often involving large dir trees.
>    It was the reverse delete that got me. Rsync WAS
>    doing exactly what I told it to do, but ...
> 


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#90503

gazelle@shell.xmission.com (Kenny McCormack) wrote:
>    1) Using something like remotehost:/path/to/wherever
>    as the destination.

That is by far the most secure and the most efficient version. ssh
provides secure authentification and encrypts the transfer, and the
use of a slave rsync allows reading of the remote file with full local
disk speed. All that method 1 needs on the remote side is a running
and configured sshd and rsync installed.

>    2) Running rsyncd on the remote host and connecting to that.

That is one more port being bound (more complexity network wise),
which is already a total showstopper for me. I have never seen rsyncd
deployed beyond publishing data like a mirror of software
distribution.

>    3) Mounting the remote machine using sshfs (or similar, like NFS,
>    Samba, or whatever else you might think of).  Then you can just do a
>    normal-looking (it looks like a local-to-local) copy.
>
>I usually use method 3, as it is the most flexible, since you can easily
>check the contents of the target system while the copy is going on and
>other things.  I use sshfs, because it is the easiest to setup and requires
>no server side setup (other than an ssh server).

When you rsync data that is already partly present on the target side,
yo read all of the target data back over the network this way, that is
grossly inefficient.

>So, my questions boil down to:
>
>    1) Is there any (significant) difference in performance between the 3
>    methods?

Yes.

>    2) How exactly does method 1 work?  What do you need on the server side
>    for it to work?  I know the answer is (or should be) "just an ssh
>    server", but not all ssh servers are created equal.  I think it may
>    depend on having the sftp module present, and I know of at least one
>    ssh server where sftp is missing.

It does not depend on sftp, it starts another rsync on the remote side
that needs to be installed. I have never tried rsync with other ssh
implementation than OpenSSH on Linux or Free/OpenBSD though.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web