Re: /usr/bin/ssh not found when rsync is executed within rsnapshot

[Chris Davies]

On 10/02/14 05:38, Lorenz wrote:
 i have a problem. But let me first describe my setup. [...rsnapshot 
configuration...]

 cmd_ssh/usr/bin/ssh
 ssh_args-i /home/backupuser/.ssh/id_rsa
 rsync: Failed to exec /usr/bin/ssh -i /home/backupuser/.ssh/id_rsa: 
No such file or directory (2)


There's a bug in some versions of rsnapshot that causes it to try and 
execute cmd_ssh + ssh_args as a single command. The workaround is either 
to put as much of ssh_args as possible into $HOME/.ssh/config for the 
specific target host, or to create a /usr/local/bin/ssh-for-rsnapshot 
type script that incorporates the call to ssh with the relevant arguments.


Chris



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: dynamic bwlimit with rsync

[Chris Davies]

On 28/09/12 16:06, Satish Shukla wrote:
Our pipe is limited and we don't want to give everything to rsync, We 
have situation where we want rsync transfers to scale up or down 
within a specified bandwidth limit. For e.g. if there are two (or 
multiple)  rsyncs running parallel they should be contained in max 
bwlimit (say like 1Mbps) and if there is only one running it should 
use the entire allocated bandwidth limit.


Instead of trying to use --bwlimit, take a look at trickle. It's old 
but works well

Chris


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Link-dest breaks on uid/gid mismatches

[Chris Davies]

On 11/06/12 21:24, Kevin Korb wrote:

You might want to look into --fake-super.  It can store metadata
things (like ownership) in the file attributes instead of setting them
on the file.


Thank you for the suggestion. Again, that seems to be a work-around 
(albeit possibly a better one)?

Chris
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Link-dest breaks on uid/gid mismatches

[Chris Davies]

I want to use rsync to backup a couple of Windows systems to a central 
point. To this end I installed the DeltaCopy implementation of an 
rsync server on the Windows boxes. On the central server I have rsync 
3.0.7 running on a Debian GNU/Linux distribution. (I also have a similar 
configuration but with a QNAP - a NAS with bells on - as the central 
backup point. Since both exhibit the same behaviour I'm going to stay 
with the more common scenario.) I also have rsnapshot in the mix but to 
keep things simple I'm going to ignore that for now.


A cut-down example rsync command could be something like this,

rsync -avxH --delete --numeric-ids --relative --delete-excluded 
--modify-window=1 --password-file=/etc/rsnapshot.secret 
--link-dest=/backup/last/ rsync://rsync@windows/DocumentsAndSettings 
/backup/this/


If this call contacts a Linux based system, the hard links between files 
in /backup/last/... and their unchanged counterparts in /backup/this/ 
are created by the --link-dest option as expected. If this contacts a 
Windows based system running DeltaCopy they are not linked. Ever.


I believe I have narrowed this down to a mismatch between the UID/GID 
values on the Windows side and the Linux side. What appears to be 
happening is that the Windows system is providing UID/GID values in a 
range that cannot be handled by the Linux system, and so it is 
truncating/converting them to 0/0. Then, when the next rsync runs, the 
UID/GID values provided by the Windows system do not match 0/0 and so 
copy is made of the file. (This is fast as it's built from the 
--link-dest item, but nevertheless it's a copy.) The resulting copy 
cannot have its UID/GID values applied correctly as they are out of the 
valid range on the Linux side, and so they are again truncated/converted 
to 0/0. And so on.


The work-around is to apply --no-owner and --no-group to the rsync 
command line, at which point the files are owned by the caller of the 
rsync command on the central server and --link-dest can work as 
expected. However, I believe a better solution would, if possible, be to 
force the UID/GID values into a valid range before comparing them to an 
existing file referenced via --link-dest.


Additional comments -
1. I haven't tried an alternative Windows client (e.g. cygwin/rsync) as 
this is outside the scope of what I can change on these systems. 
Therefore I cannot be sure whether this is a client or server issue, 
i.e. I cannot confirm that this fault report belongs to rsync rather 
than to DeltaCopy
2. I did get a UID/GID range error at one point but I can neither 
reproduce it nor remember it sufficiently accurately to want to cite it here


Any other thoughts, please? Should I report this as a bug?

Cheers,
Chris
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html