{"id":475,"date":"2017-08-28T21:12:08","date_gmt":"2017-08-28T19:12:08","guid":{"rendered":"http:\/\/www.geohei.lu\/geoheiWP\/?p=475"},"modified":"2017-09-03T17:45:28","modified_gmt":"2017-09-03T15:45:28","slug":"rsync-backup-from-ubuntu-server-to-synology-nas","status":"publish","type":"post","link":"https:\/\/www.geohei.lu\/geoheiWP\/rsync-backup-from-ubuntu-server-to-synology-nas\/","title":{"rendered":"rsync backup from Ubuntu server to Synology NAS"},"content":{"rendered":"<p><a href=\"https:\/\/i0.wp.com\/www.geohei.lu\/geoheiWP_TEST\/wp-content\/uploads\/2017\/08\/synology_dsm.png\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" class=\"alignleft size-medium wp-image-1180\" src=\"https:\/\/i0.wp.com\/www.geohei.lu\/geoheiWP_TEST\/wp-content\/uploads\/2017\/08\/synology_dsm-300x200.png?resize=300%2C200\" alt=\"\" width=\"300\" height=\"200\" \/><\/a>This tutorial describes how to do scripted passwordless encrypted automatic <a href=\"https:\/\/en.wikipedia.org\/wiki\/Rsync\">rsync<\/a> backups from an Ubuntu server to a Synology NAS. It is supposed to be a general guide, which can be used with other Linux variants as well. Only minor changes should be required.<\/p>\n<p>I did this first of all in order to help other Synology NAS users perform efficient and secure backups to their NAS, but also to get get my scratch pad like personal installation notes in a more reasonable shape, so I can recall later on myself what I did, how, and why.<\/p>\n<p><!--more--><\/p>\n<p><a href=\"#a1\">1. Setup prerequisites for rsync on source and destination host<\/a><br \/>\n<a href=\"#a2\">2. Create home directory for DSM user (to hold .ssh directory)<\/a><br \/>\n<a href=\"#a3\">3. Setup ssh and avoid password entry<\/a><br \/>\n<a href=\"#a4\">4. Create a script and use cron to automate execution<\/a><br \/>\n<a href=\"#a5\">5. Use another module than the default &#8220;NetBackup&#8221;<\/a><\/p>\n<p>For this tutorial, the following hardware\/software was used:<\/p>\n<p><strong><u>Source host:<\/u><\/strong><br \/>\nOS : ubuntu-16.04-server-amd64.iso running in a VM.<br \/>\nip : 192.168.1.167 (not relevant for this tutorial)<br \/>\nhostname : <span class=\"highlight\" style=\"background-color: #404040;\"><code>vmtest<\/code><\/span><br \/>\nuser : <span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei<\/code><\/span><\/p>\n<p><strong><u>Destination host:<\/u><\/strong><br \/>\nhardware : DS1817+<br \/>\nOS : DSM 6.1.3-15152 Update 3 running in a VM (Virtual Machine Manager)<br \/>\nip : 192.168.1.174<br \/>\nhostname : <span class=\"highlight\" style=\"background-color: #404040;\"><code>vm-neelix<\/code><\/span><br \/>\nuser : <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway<\/code><\/span><\/p>\n<p>The following targets should be achieved:<\/p>\n<ul>\n<li>rsync from client (Ubuntu server) to server (NAS)<\/li>\n<li>encrypted and passwordless rsync data transfer<\/li>\n<li>automatic script execution using cron<\/li>\n<li>script should catch previous unterminated script execution and avoid starting it again<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h1 id=\"a1\"><span class=\"highlight\" style=\"background-color: #ab6408;\">1. Setup prerequisites for rsync on source and destination host<\/h1>\n<p>Destination host DSM rsync service needs to be enabled on destination host:<br \/>\nDSM : <span class=\"highlight\" style=\"background-color: #633903;\">File Services > rsync > Enable rsync service : enable<\/span><br \/>\nThis automatically creates the shared folder &#8220;NetBackup&#8221;.<\/p>\n<p>rsync data transfer should ideally be accomplished to a destination user having minimal permissions. Unfortunately however, this user must be a member of the &#8220;administrators&#8221; group, since rsync requires shell login at the destination host. Only users of the &#8220;administrators&#8221; group generate the <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/etc\/passwd<\/code><\/span> field 7 (last field) <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/bin\/sh<\/code><\/span>. Users not being member of &#8220;administrators&#8221; group have <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/sbin\/nologin<\/code><\/span>, which doesn&#8217;t allow (rsync) logins. Basically, the user created during initial DSM setup is just fine. He has all the necessary permissions required for rsync and belongs to the &#8220;administrators&#8221; group.<\/p>\n<p>Perform a first manual rsync from source <span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei@vmtest<\/code><\/span> to destination <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway@vm-neelix<\/code><\/span>. Note that destination directory &#8220;rsyncfolder&#8221; is created by rsync if necessary (only one directory will be created, not multiple).<\/p>\n<pre>geohei@vmtest:~$ rsync -rlptogRv -e ssh \"\/home\/geohei\/data\" janeway@192.168.1.174::NetBackup\/rsyncfolder\r\nThe authenticity of host '192.168.1.174 (192.168.1.174)' can't be established.\r\nECDSA key fingerprint is SHA256:###########################################.\r\nAre you sure you want to continue connecting (yes\/no)? yes\r\nWarning: Permanently added '192.168.1.174' (ECDSA) to the list of known hosts.\r\njaneway@192.168.1.174's password:\r\nCould not chdir to home directory \/var\/services\/homes\/janeway: No such file or directory\r\nsending incremental file list\r\ncreated directory rsyncfolder\r\n\/home\/\r\n\/home\/geohei\/\r\n\/home\/geohei\/data\/\r\n\/home\/geohei\/data\/bar_file_1.txt\r\n\/home\/geohei\/data\/foo_directory\/\r\n\/home\/geohei\/data\/foo_directory\/bar_file_2.txt\r\n\r\nsent 298 bytes  received 113 bytes  18.27 bytes\/sec\r\ntotal size is 0  speedup is 0.00<\/pre>\n<\/p>\n<p>Transferred data of source host (uid:gid shown as numeric IDs):<\/p>\n<pre>geohei@vmtest:~$ ls -ldn \/home\/\r\ndrwxr-xr-x 3 0 0 4096 Dec 31  2016 \/home\/\r\ngeohei@vmtest:~$ ls -ln \/home\/\r\ntotal 4\r\ndrwxr-xr-x 6 1000 1000 4096 Aug 27 19:38 geohei\r\ngeohei@vmtest:~$ ls -ln \/home\/geohei\/\r\ntotal 4\r\ndrwxrwxr-x 3 1000 1000 4096 Aug 27 19:32 data\r\ngeohei@vmtest:~$ ls -ln \/home\/geohei\/data\/\r\ntotal 4\r\n-rw-rw-r-- 1 1000 1000    0 Aug 21 20:41 bar_file_1.txt\r\ndrwxrwxr-x 2 1000 1000 4096 Aug 22 12:47 foo_directory\r\ngeohei@vmtest:~$ ls -ln \/home\/geohei\/data\/foo_directory\/\r\ntotal 0\r\n-rw-rw-r-- 1 1000 1000 0 Aug 22 12:47 bar_file_2.txt<\/pre>\n<\/p>\n<p>Transferred data of source host (uid:gid shown as numeric IDs):<\/p>\n<pre>janeway@vm-neelix:~$ ls -ln \/volume1\/NetBackup\/rsyncfolder\/\r\ntotal 0\r\ndrwxr-xr-x 1 0 0 12 Dec 31  2016 home\r\njaneway@vm-neelix:~$ ls -ln \/volume1\/NetBackup\/rsyncfolder\/home\/\r\ntotal 0\r\ndrwxr-xr-x 1 1000 1000 216 Aug 27 19:38 geohei\r\njaneway@vm-neelix:~$ ls -ln \/volume1\/NetBackup\/rsyncfolder\/home\/geohei\/\r\ntotal 0\r\ndrwxrwxr-x 1 1000 1000 54 Aug 27 19:32 data\r\njaneway@vm-neelix:~$ ls -ln \/volume1\/NetBackup\/rsyncfolder\/home\/geohei\/data\/\r\ntotal 0\r\n-rw-rw-r-- 1 1000 1000  0 Aug 21 20:41 bar_file_1.txt\r\ndrwxrwxr-x 1 1000 1000 28 Aug 22 12:47 foo_directory\r\njaneway@vm-neelix:~$ ls -ln \/volume1\/NetBackup\/rsyncfolder\/home\/geohei\/data\/foo_directory\/\r\ntotal 0\r\n-rw-rw-r-- 1 1000 1000 0 Aug 22 12:47 bar_file_2.txt<\/pre>\n<\/p>\n<p>rsync preserves data permissions and uid:gid at the destination host. However this only occurs if source rsync command includes <span class=\"highlight\" style=\"background-color: #404040;\"><code>-og<\/code><\/span> options, and if the destination rsync daemon is being run as super-user. See rsync(1) and rsyncd.conf(5) for details. On top, the destination host needs to be addresses by destination module name <span class=\"highlight\" style=\"background-color: #404040;\"><code>::NetBackup<\/code><\/span>, as opposed to a destination path (<span class=\"highlight\" style=\"background-color: #404040;\"><code>\/volume1\/NetBackup<\/code><\/span>). In the latter case, the uid:gid would be inherited from the user used by the rsync command (<span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway:users<\/code><\/span> in the example above).<\/p>\n<p>To make the mess complete, Synology customized its rsync binary. At this point it really (!) gets complicated, especially because there is barely any information available about the changed code. If interested in details, please have a look at <a href=\"#a5\">this<\/a>.<\/p>\n<p>&nbsp;<\/p>\n<h1 id=\"a2\"><span class=\"highlight\" style=\"background-color: #ab6408;\">2. Create home directory for DSM user (to hold .ssh directory)<\/span><\/h1>\n<p>rsync prints the message (no error, just an information) after the password was entered: <span class=\"highlight\" style=\"background-color: #404040;\"><code>\"Could not chdir to home directory \/var\/services\/homes\/janeway: No such file or directory\"<\/code><\/span>. This is normal since DSM doesn&#8217;t create a home directory when adding new users (<span class=\"highlight\" style=\"background-color: #404040;\"><code>--no-create-home<\/code><\/span>). The same message shows when logging into shell using any DSM user. If desired (not required for now!), create the home directory. First, sudo to user <span class=\"highlight\" style=\"background-color: #404040;\"><code>root<\/code><\/span>. The sudo password is the one of user <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway<\/code><\/span>. Then create the home directory for user <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway<\/code><\/span> and finally the required symlink.<\/p>\n<pre>janeway@vm-neelix:\/$ sudo -i\r\nPassword:\r\nroot@vm-neelix:~# mkdir \/home\r\nroot@vm-neelix:~# mkdir \/home\/janeway\r\nroot@vm-neelix:~# chown janeway:users \/home\/janeway\/\r\nroot@vm-neelix:~# mkdir \/var\/services\/homes\r\nroot@vm-neelix:~# ln -s \/home\/janeway \/var\/services\/homes\/janeway<\/pre>\n<\/p>\n<p>ssh and rsync logins should not complain anymore about a missing home directory.<\/p>\n<p>While until now, the generation of a home directory for user <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway<\/code><\/span> was cosmetic, it becomes a requirement for chapter 3 below.<\/p>\n<p>&nbsp;<\/p>\n<h1 id=\"a3\"><span class=\"highlight\" style=\"background-color: #ab6408;\">3. Setup ssh and avoid password entry<\/span><\/h1>\n<p>First, generate an RSA 2048 bit key for user <span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei@vmtest<\/code><\/span> using ssh-keygen. Accept default file name suggestion for <span class=\"highlight\" style=\"background-color: #404040;\"><code>id_rsa<\/code><\/span>. Leave the passphrase empty (you will be asked twice). Below, I used <span class=\"highlight\" style=\"background-color: #404040;\"><code>ssh-keygen -t rsa -b 2048<\/code><\/span>, but the <span class=\"highlight\" style=\"background-color: #404040;\"><code>-t<\/code><\/span> and <span class=\"highlight\" style=\"background-color: #404040;\"><code>-b<\/code><\/span> options are defaults, hence <span class=\"highlight\" style=\"background-color: #404040;\"><code>ssh-keygen<\/code><\/span> would have been sufficient.<\/p>\n<pre>geohei@vmtest:~$ ssh-keygen -t rsa -b 2048\r\nGenerating public\/private rsa key pair.\r\nEnter file in which to save the key (\/home\/geohei\/.ssh\/id_rsa):\r\nCreated directory '\/home\/geohei\/.ssh'.\r\nEnter passphrase (empty for no passphrase):\r\nEnter same passphrase again:\r\nYour identification has been saved in \/home\/geohei\/.ssh\/id_rsa.\r\nYour public key has been saved in \/home\/geohei\/.ssh\/id_rsa.pub.\r\nThe key fingerprint is:\r\nSHA256:########################################### geohei@vmtest\r\nThe key's randomart image is:\r\n+---[RSA 2048]----+\r\n|   E      . Eo   |\r\n|        +  =.o.  |\r\n|   =      o=+.   |\r\n| o.   .  ..o*    |\r\n|     o +S.o+o.   |\r\n|    . =o=.o*+    |\r\n|  X  =.+. += o   |\r\n|    o oo. X+o    |\r\n|   .  ...*o+.    |\r\n+----[SHA256]-----+<\/pre>\n<\/p>\n<p>Next, you need to copy the just generated <span class=\"highlight\" style=\"background-color: #404040;\"><code>id_rsa.pub<\/code><\/span> from the source host to the destination host. Now we need the home directory of the destination host user (<span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway<\/code><\/span>) since the content of <span class=\"highlight\" style=\"background-color: #404040;\"><code><\/code>id_rsa.pub<\/span> is stored in this directory (<span class=\"highlight\" style=\"background-color: #404040;\"><code>\/home\/janeway\/.ssh\/authorized_keys<\/code><\/span>). The command <span class=\"highlight\" style=\"background-color: #404040;\"><code>ssh-copy-id<\/code><\/span> should be used to transfer the key. This command requires login at the destination host. That&#8217;s another reason (besides the rsync ccommand) why user <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway<\/code><\/span> needs to be part of the DSM &#8220;administrators&#8221; group (see above).<\/p>\n<pre>geohei@vmtest:~$ ssh-copy-id -i \/home\/geohei\/.ssh\/id_rsa.pub janeway@192.168.1.174\r\n\/usr\/bin\/ssh-copy-id: INFO: Source of key(s) to be installed: \"\/home\/geohei\/.ssh\/id_rsa.pub\"\r\nThe authenticity of host '192.168.1.174 (192.168.1.174)' can't be established.\r\nECDSA key fingerprint is SHA256:###########################################.\r\nAre you sure you want to continue connecting (yes\/no)? yes\r\n\/usr\/bin\/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed\r\n\/usr\/bin\/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys\r\njaneway@192.168.1.174's password:\r\n\r\nNumber of key(s) added: 1\r\n\r\nNow try logging into the machine, with:   \"ssh 'janeway@192.168.1.174'\"\r\nand check to make sure that only the key(s) you wanted were added.\r\n\r\n<\/pre>\n<\/p>\n<p>From now on, <span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei@vmtest<\/code><\/span> can login (ssh, rsync, &#8230;) to <span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway@vm-neelix<\/code><\/span> without password entry. This also permits scripted rsync as shown below.<\/p>\n<p>The bottom line with the RSA key exchange can be summarized as follows. The user, invoking the ssh transfer (<span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei@vmtest<\/code><\/span>) must generate the RSA key. This RSA key must be transferred to the home directory of the destination user@host (<span class=\"highlight\" style=\"background-color: #404040;\"><code>janeway@vm-neelix<\/code><\/span>).<\/p>\n<p>If for some reason, <span class=\"highlight\" style=\"background-color: #404040;\"><code>ssh-copy-id<\/code><\/span> cannot be used, then copy the RSA key manually from source host <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/home\/geohei\/.ssh\/id_rsa.pub<\/code><\/span> to destination host <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/home\/janeway\/.ssh\/authorized_keys<\/code><\/span>. A situation where this is required would be for example a destination user which doesn&#8217;t have a password (as it is for DSM user <span class=\"highlight\" style=\"background-color: #404040;\"><code>root<\/code><\/span> as seen in chapter 5 below), as <span class=\"highlight\" style=\"background-color: #404040;\"><code>ssh-copy-id<\/code><\/span> requires entering destination user password.<\/p>\n<p>&nbsp;<\/p>\n<h1 id=\"a4\"><span class=\"highlight\" style=\"background-color: #ab6408;\">4. Create a script and use cron to automate execution<\/span><\/h1>\n<p>The following script will automate the rsync process.<\/p>\n<pre>geohei@vmtest:~$ cat backup.sh\r\n#!\/bin\/bash\r\n\r\nserver='192.168.1.174'\r\n\r\nscript=$(basename $0)\r\nlock=\"\/tmp\/$script.pid\"\r\npid=$$\r\n\r\necho $lock\r\n\r\n# open $lock for writing on file descriptor 200\r\nexec 200> $lock\r\n# copy write file descriptor 1 (stdout, which is pid in this case) to file descriptor 200\r\necho $pid 1>&200\r\n\r\necho \"INFO : rsync started.\"\r\nif flock -n -x 200; then\r\n  # if $script is not already active\r\n  rsync -rlptRv -e ssh \"\/home\/geohei\/data\" janeway@192.168.1.174::NetBackup\/rsyncfolder\r\n  echo \"INFO : rsync finished.\"\r\nsleep 10\r\n  rc=0\r\nelse\r\n  # if $script is active\r\n  echo \"ERROR : rsync not possible since $script is still busy !!!\"\r\n  rc=1\r\nfi\r\nrm $lock\r\necho \"INFO : rsync finished.\"\r\nexit $rc<\/pre>\n<\/p>\n<pre>geohei@vmtest:~$ ls -l backup.sh\r\n-rwxr-xr-x 1 geohei geohei 659 Aug 26 00:57 backup.sh<\/pre>\n<\/p>\n<p>Make sure that permissions are set to 755.<\/p>\n<p>The script includes comments, which explain the basic operation. It works with file descriptors, which permit to check if the script is still active or not. This design avoids running the script twice, possibly causing mutual interence.<\/p>\n<p>cron takes care of daily trigger. I run it as user <span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei<\/code><\/span>, but it could also be user <span class=\"highlight\" style=\"background-color: #404040;\"><code>root<\/code><\/span>. Just make sure the RSA keys of the user invoking cron, are transferred to the destination host@user&#8217;s home directory.<\/p>\n<pre>0 3 * * * ~\/backup.sh<\/pre>\n<\/p>\n<p>&nbsp;<\/p>\n<h1 id=\"a5\"><span class=\"highlight\" style=\"background-color: #ab6408;\">5. Use another module than the default &#8220;NetBackup&#8221;<\/span><\/h1>\n<p>First of all, this chapter was added after the great (!) help of user &#8220;nixjps&#8221; in the Synology forum. It is based on this thread &#8220;<a href=\"https:\/\/forum.synology.com\/enu\/viewtopic.php?f=39&#038;t=134724\">rsync issues and questions<\/a>&#8221; and greatly simplified below. If you really want to explore it &#8230; get yourself some coffee!<\/p>\n<p>Ok &#8230; let&#8217;s say you don&#8217;t like the default folder &#8220;NetBackup&#8221; (which is automatically created when the DSM rsync service is enabled) as rsync directory, and you prefer something like &#8220;rsync Backups&#8221;. The first thing you need to know is that the shared folder &#8220;NetBackup&#8221; is hardcoded into the customized Synology rsync binary. It is not just another rsync module. It has a special status. I didn&#8217;t dig through the (outdated 3.0.9) rsync source code, but it can apparently be found at SourceForge.<\/p>\n<p>My rsync objective is to keep all file\/directory permissions as well uid:gid throughout the entirely copied filesystem tree. Using the DSM rsync version, this can only be done on the <u>client side<\/u> with the rsync <span class=\"highlight\" style=\"background-color: #404040;\"><code>-og<\/code><\/span> (tells the rsync server to keep uid:gid) and <span class=\"highlight\" style=\"background-color: #404040;\"><code>--numeric-ids<\/code><\/span> (avoids name mapping) options, while on the <u>server side<\/u>, rsync must be started by a user of the &#8220;administrators&#8221; group in daemon mode (which occurs when a destination module name is used on the client side, as opposed to a destination path).<\/p>\n<p>The only possibility to make DSM rsync server behave like for the &#8220;NetBackup&#8221; folder, is to create a desired new module and to use user <span class=\"highlight\" style=\"background-color: #404040;\"><code>root<\/code><\/span> as login from the client side to the DSM rsync server.<\/p>\n<p>The original <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/etc\/rsyncd.conf<\/code><\/span> looks like this:<\/p>\n<pre>#motd file = \/etc\/rsyncd.motd\r\n#log file = \/var\/log\/rsyncd.log\r\npid file = \/var\/run\/rsyncd.pid\r\nlock file = \/var\/run\/rsync.lock\r\nuse chroot = no<\/pre>\n<\/p>\n<p>The modified version would be something like that:<\/p>\n<pre>#motd file = \/etc\/rsyncd.motd\r\n#log file = \/var\/log\/rsyncd.log\r\npid file = \/var\/run\/rsyncd.pid\r\nlock file = \/var\/run\/rsync.lock\r\nuse chroot = no\r\n\r\n[rsyncB]\r\npath = \/volume1\/rsync Backup\r\ncomment = module for rsync backups\r\nread only = false\r\nuid = root<\/pre>\n<\/p>\n<p>The above assumes of course that the shared folder &#8220;rsync Backup&#8221; exists on the DSM.<\/p>\n<p>Restart of the rsyncd service is not required since <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/etc\/rsyncd.conf<\/span><\/code> is re-read when newly invoked.<\/p>\n<p>Listing all (listable) rsync destination modules and paths from the client looks like this:<\/p>\n<pre>geohei@vmtest:~$ rsync 192.168.1.174::\r\nrsyncB          module for rsync backups\r\nNetBackup       System default shared folder\r\nrsync Backup\r\nhome            ~<\/pre>\n<\/p>\n<p>If passwordless access is desired (required for script operation &#8211; see above), then RSA key from <span class=\"highlight\" style=\"background-color: #404040;\"><code>geohei@vmtest<\/code><\/span> also needs to be copied to the directory of <span class=\"highlight\" style=\"background-color: #404040;\"><code>root@vm-neelix<\/code><\/span>. This works like explained <a href=\"#a3\">here<\/a>.<\/p>\n<p>Be aware that DSM user <span class=\"highlight\" style=\"background-color: #404040;\"><code>root<\/code><\/span> has per default no password. The command <span class=\"highlight\" style=\"background-color: #404040;\"><code>synouser --setpw root [root_pwd]<\/code><\/span> would generate a password, but this is not recommended. Nevertheless, if done, delete it later on again out of <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/etc\/shadow<\/code><\/span>.<\/p>\n<p>The better solution is to manually copy the RSA key. Below shows permissions, uid:gid and content (one RSA key per line) of <span class=\"highlight\" style=\"background-color: #404040;\"><code>\/root\/.ssh\/authorized_keys<\/code><\/span>.<\/p>\n<pre>janeway@vm-neelix:\/$ sudo -i\r\nPassword:\r\nroot@vm-neelix:~# ls -ld .ssh\/\r\ndrwx------ 2 root root 4096 Sep  3 17:21 .ssh\/\r\nroot@vm-neelix:~# ls -l .ssh\/\r\n#total 4\r\n-rw------- 1 root root 396 Sep  3 17:13 authorized_keys\r\nroot@vm-neelix:~# cat .ssh\/authorized_keys\r\nssh-rsa ... geohei@vmtest<\/pre>\n<\/p>\n<p>Now, there are 2 possibilities to invoke rsync on the client side:<\/p>\n<pre>geohei@vmtest:~$ rsync -rlptogvDR -e \"ssh -l root\" --numeric-ids \"\/home\/geohei\/\" janeway@192.168.1.174::rsyncB<\/pre>\n<\/p>\n<pre>geohei@vmtest:~$ rsync -rlptogvDR -e ssh --numeric-ids \"\/home\/geohei\/\" root@192.168.1.174::rsyncB<\/pre>\n<\/p>\n<p>Both seem to produce identical results in all respects.<\/p>\n<p>Like that, shared folder &#8220;rsync Backup&#8221; can be used exactly the same way as &#8220;NetBackup&#8221;, hence cirumnavigating the Synology rsync &#8220;NetBackup&#8221; folder restrictions.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This tutorial describes how to do scripted passwordless encrypted automatic rsync backups from an Ubuntu server to a Synology NAS. It is supposed to be a general guide, which can be used with other Linux variants as well. Only minor changes should be required. I did this first of all in order to help other&#8230; <\/p>\n<div class=\"read-more navbutton\"><a href=\"https:\/\/www.geohei.lu\/geoheiWP\/rsync-backup-from-ubuntu-server-to-synology-nas\/\">Read More<i class=\"fa fa-angle-double-right\"><\/i><\/a><\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[21,31,3],"tags":[],"class_list":["post-475","post","type-post","status-publish","format-standard","hentry","category-server","category-synology","category-ubuntu"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5mjlH-7F","_links":{"self":[{"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/posts\/475","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/comments?post=475"}],"version-history":[{"count":22,"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/posts\/475\/revisions"}],"predecessor-version":[{"id":497,"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/posts\/475\/revisions\/497"}],"wp:attachment":[{"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/media?parent=475"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/categories?post=475"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.geohei.lu\/geoheiWP\/wp-json\/wp\/v2\/tags?post=475"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}