Find the answer to your Linux question:
Results 1 to 7 of 7
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jun 2012
    Posts
    4

    Rsync vs Rsync over SSH | permissions??


    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?

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,411
    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.
    You must always face the curtain with a bow.

  3. #3
    Just Joined!
    Join Date
    Jun 2012
    Posts
    4
    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
    Code:
    #!/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
    Code:
    #!/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

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

  4. $spacer_open
    $spacer_close
  5. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,411
    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.
    You must always face the curtain with a bow.

  6. #5
    Just Joined!
    Join Date
    Jun 2012
    Posts
    4
    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!

  7. #6
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,411
    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.
    Last edited by Irithori; 06-06-2012 at 12:56 PM.
    You must always face the curtain with a bow.

  8. #7
    Just Joined!
    Join Date
    Jun 2012
    Posts
    4
    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..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •