2 ms·

I must admit my rsync experience is limited. I do not know the behaviors and flags very deeply. It's on my list though, as it's surely another one of those foun

I must admit my rsync experience is limited. I do not know the behaviors and flags very deeply. It's on my list though, as it's surely another one of those foundational linux tools. I know it is even faster than cp on the same host for some situations.

ASalazarMX 2y ago
rsync is the tar of network transfers. It is extremely useful, but has too many options, so one ends up memorizing a few use cases and carefully sticking to them. I still have PTSD from the time I played with the options and made the mistake of swapping source and destination, where the destination was a blank disk.
- sigmonsays 2y ago
  haha, you say rsync is the tar of network transfers, but have you ever considered using tar for network transfers? Time a 'tar | nc' sometime to a remove server, it'll blow away the rsync time.
  - whalesalad 2y ago
    you are not wrong, but you are missing the argument
- dspillett 2y ago
  --dry-run is a useful safety net when trying new combinations of options. That, and the fact it'll never delete unless you specifically give it an option with "delete" in its name.
saghm 2y ago
In my experience, rsync is a tool that's worth it despite not knowing most of what it can do. I use `-a` to get the behavior you want (which is superset of a bunch of options like preserving filesystem permissions, copying recursively, and other things I haven't bothered to memorize) `--info=progress3` to show progress/network speed updating on a single line (no idea what the other progress options do, but this one does what I want), and if I'm transferring something that's not already compressed, I use `-z --compress-choice=zstd`. After those flags, it's basically a drop-in replacement for scp (`remote:srcpath dstpath` for copying to local and `srcpath remote:dstpath` for copying to remote).
dspillett 2y ago
The basics for just copying files as you would with scp are pretty intuitive: rsync source destination or rsync source destination --recursive with the only extra gotcha being that you need to be careful whether you need trailing /s on directories (sometimes where CP or scp would complain and exit, rsync will do something that isn't quite what you intended). The first complication you might hit is when you want to sync, including deleting files at the destination as needed, rather than just copying. This isn't _that_ complicated really, but caution is understandable because mistakes can cause unintended deletions. The --dry-run and verbose output options are your friend here, and the assurance that it won't delete anything unless you explicitly give it one if the --delete* options.

ASalazarMX 2y ago

rsync is the tar of network transfers. It is extremely useful, but has too many options, so one ends up memorizing a few use cases and carefully sticking to them. I still have PTSD from the time I played with the options and made the mistake of swapping source and destination, where the destination was a blank disk.

sigmonsays 2y ago
haha, you say rsync is the tar of network transfers, but have you ever considered using tar for network transfers? Time a 'tar | nc' sometime to a remove server, it'll blow away the rsync time.
- whalesalad 2y ago
  you are not wrong, but you are missing the argument
dspillett 2y ago
--dry-run is a useful safety net when trying new combinations of options. That, and the fact it'll never delete unless you specifically give it an option with "delete" in its name.

saghm 2y ago

In my experience, rsync is a tool that's worth it despite not knowing most of what it can do. I use `-a` to get the behavior you want (which is superset of a bunch of options like preserving filesystem permissions, copying recursively, and other things I haven't bothered to memorize) `--info=progress3` to show progress/network speed updating on a single line (no idea what the other progress options do, but this one does what I want), and if I'm transferring something that's not already compressed, I use `-z --compress-choice=zstd`. After those flags, it's basically a drop-in replacement for scp (`remote:srcpath dstpath` for copying to local and `srcpath remote:dstpath` for copying to remote).

dspillett 2y ago

The basics for just copying files as you would with scp are pretty intuitive: rsync source destination or rsync source destination --recursive with the only extra gotcha being that you need to be careful whether you need trailing /s on directories (sometimes where CP or scp would complain and exit, rsync will do something that isn't quite what you intended). The first complication you might hit is when you want to sync, including deleting files at the destination as needed, rather than just copying. This isn't _that_ complicated really, but caution is understandable because mistakes can cause unintended deletions. The --dry-run and verbose output options are your friend here, and the assurance that it won't delete anything unless you explicitly give it one if the --delete* options.