View source for Network backup FROM Synology TO Amahi

<!-- 
This page is crated automaticaly by a script.
This part is commented and shall not show
-->
<!--At the top of the page can be vissible one of the following tags..-->
    {{WorkInProgress}}
<!--{{NeedsUpdate}}-->
<!--{{NeedsMerge | [[Main Page]]}}-->
<!--{{NeedsExpantion}}-->
<!--{{NeedsDelete |[[Main Page]]}}-->
<!--Please remove or place comment accordingly-->
<!--Your text bellow this line-->
 

This is for those trying to get a synology/xpenology box (source) to backup over the network to an Amahi box (target).  I thought that one could fill out the dashboard on the source, and hit the "go" button to start the backup to the HP/Amahi. I found it was not so easy.  This is for Amahi 6/ Ubuntu 12.04.  

For some reason, xpenology likes an rsync daemon running on the target. So we have to setup the target to be ready.

1. Edit the file /etc/default/rsync in the Amahi box to start rsync as daemon using xinetd. The entry listed below, should be changed from false to inetd.

RSYNC_ENABLE=inetd


2. Install xinetd on the Amahi box because it's apparently not installed by default.

$ sudo apt-get -y install xinetd

3. Create the file /etc/xinetd.d/rsync on Amahi box to launch rsync via xinetd. It should contain the following lines of text.

service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
log_on_failure += USERID
flags = IPv6
}

If I have anything other than user = root, I can't get it to work. Don't make it the user below. If I change it to "kevin" (user below) it fails to connect.

4. Create the file /etc/rsyncd.conf configuration on Amahi box to use rsync/daemon. The file should contain the following.

max connections = 2
log file = /var/log/rsync.log
timeout = 300

[datashare]
comment = Data backup share
path = /var/hda/files/data
read only = no
list = yes
uid = kevin
gid = nogroup
auth users = kevin
secrets file = /etc/rsyncd.secrets

I made auth user = kevin and uid = kevin. "kevin" is an amahi user with admin checked (in the user area of Amahi dashboard). For multiple shares to backup to, just copy the "destination module" created by [datashare] above, and paste and edit. In my case I have 4 shares: data, media, backup, autocad. So, I have 4 modules in the rsyncd.conf file.

5. Create /etc/rsyncd.secrets on Amahi box for user's password. User should be the same as above, with password the one used to log into/ SSH into the HP/Amahi box.

$ sudo nano /etc/rsyncd.secrets
kevin:theuserpassword


6. Then set the file permissions for rsyncd.secrets on the Amahi box.

$ sudo chmod 600 /etc/rsyncd.secrets


7. Start/Restart xinetd

$ sudo /etc/init.d/xinetd restart

not sure if this was needed, but what the heck.


Now for the source side of things: In the xpenology box, load the dashboard/web interface --> mainmenu/backup and replication.
click "backup destination"
click "create"
pick "network destination / rsync compatible" then NEXT
Name it something you'll understand ... in my case: "data share on Amahi"
IP address (self explanatory)
user: kevin
password: theuserpassword
backup module: datashare (if you made 4 modules like I did, all 4 are available for selection as backup targets)
hit APPLY. If it doesn't work, check the user and passwords.
Do the other modules in the same manner


Now, to setup a backup job on the xpenology box:
click "backup" , then "create", then "data backup task"
select the folders to backup (pick one with little data or a test folder to make sure it works)
select one of the backup destinations you just created and hit NEXT
name the task, say "backup of data to Amahi"
name the directory on the Amahi share where the backup is going
side note: here's where it got interesting. if I leave metadata and thumbnails selected or unselected and I have "kevin" as the user, it works fine. If I have "rsync" as the user with admin permission (as when I was experimenting with the setup) and have the above 2 things selected, the files came over with protections. I couldn't delete some folders of the test run (I think the metadata ones). I'd have to chmod them to be able to delete them. When I deselected them they were deletable. Someone better than me at this can tell me why. Anyhow, I can't see why you'd really need it, so deselect them and give it a shot.
then hit APPLY

Do a "backup now" to see if it works and that you can delete the backup directory (no odd permissions). If it works, then you can edit the backup task and put a schedule on it.

I think I captured everything I did accurately, and I hope that helps someone.
 
 


<!--Your text above this line-->
<!--This page must bellong to one of the following categories please remove comment-->
<!--[[category:Apps]]-->
<!--[[Category:Fedora]]-->
<!--[[Category:Platform]]-->
<!--[[Category:Pro Version]]-->
<!--[[Category:Services]]-->
<!--[[Category:VPN]]-->