Rsync vs Rsync over SSH | permissions??

[medS]

I can't seem to find out what the differences are.

I tried to backup a remote server to a local NAS. I always use rsync over ssh with this stuf(because rsync alone can't do without passwords, so no cron possible).

No i first rsynced the stuf. Worked like a charm
After that, altered the connection in the script to use rsync over ssh. And now i get al kinds of permission errors?

I use the same commands and the same user? so why is 'over ssh' so different?

[Irithori]

As both rsync and ssh are versatile tools, it would help a lot if you list the working and non-working commands along with the errors (in CODE tags please).

Also: rsync can work without password, if it is configured this way.

[medS]

well, i know that you don't HAVE to have a password.. but i because it's a backup over the net, it would be like an open rsync... (no a good plan i guess)

but the scripts are this:

rsync

#!/bin/sh

/usr/bin/nice -n 19 /usr/bin/rsync -az -v \
        --delete \
        --delete-excluded \
        --bwlimit=30 \
        --stats \
        --exclude=tmp \
        --exclude=.cache \
        /{backupfolder} {user}@{targetNAS}::/{module} > /tmp/backup.txt

over ssh

#!/bin/sh

/usr/bin/nice -n 19 /usr/bin/rsync -az -v \
        --delete \
        --delete-excluded \
        --bwlimit=30 \
        --stats \
        -e 'ssh -l {user}' \
        --exclude=tmp \
        --exclude=.cache \
        /{backupfolder} {targetNAS}:/{folder} > /tmp/backup.txt

an error is

rsync: opendir "/{targetbackupfolder}/share/document" (in backups) failed: Permission denied (13)

[Irithori]

The difference is, that the "rsync only" probably still runs as root on the remote machine,
whereas rsync via ssh is limited to {user}.

Check, if
- {user} can access all direcories and files in {targetNAS}:/{folder} . Especially in {folder}/share/document
- the sourcefiles/dirs have multiple uids/gids. If yes, then rsync attempts to modify these on the remote site, because you requested all bits to be copied (-a). But {user} cannot set a uid for example.


Slightly OT:
Depending on your usecase, you might want to replace cron with lsyncd
lsyncd works via inotify.
So it only triggers a sync, if the source changed and not periodically.
Which saves IO resources, as the cron approach has to build two filelists on each run.

[medS]

Thanx for youre quick reply!

so would it be a smart move to manually change the uids/guids to the {user} ? After that change the -a and replace it with the normal flags(without the uids/ guids).
than the backup wouldn't be an exact copy... but else i will probably have the same problems next run!

reply to OT:
Unfortunatly lsyncd is not really good in thus case. but def worth exploring. so thanx for the tip!

[Irithori]

Well, it depends
Do you need the uids/gids to be exactly the same or not?

If no: then dont use -a or -p, but a more fitting set.
If yes: One could think of establishing a tunnel first (via ssh or stunnel or even openvpn) from the server to the NAS
and then use that tunnel to connect to the rsync daemon on the NAS, just like in your "rsync only" approach, just that {tagetNAS} would then the the tunnel endpoint on your server.

The downside of this is, that you would either need to write some script with logic to open/close such a tunnel on every rsync run
or treat this tunnel as a service and monitor it.
In both cases, locks and possible connection issues need to be addressed by the script logic.


But actually, there might be a better approach:
Duplicity will create encrypted tarballs and can copy them to a rsync modul.
The consequence of this is, that you need space on the server to create the tarballs.

[medS]

Well.. it's just data storage. So don't really need the uid and gid.
I like the tunnel bit.. totally forgot about that..

So i'm going to test with changing my backup waterfall.. and the tunnel option(dealing with the tunnel and stopped crons and so on)

so big thanks. Your explenation made it all more clear!!

When i find my perfect solution. i will post it..