Network backup FROM Synology TO Amahi

	Work In Progress
	This article is currently undergoing major expansion or restructuring. You are welcome to assist by editing it as well. If this article has not been edited in several days, please remove this template.

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.

bash code
​sudo nano /etc/default/rsync​

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.

bash code
​sudo apt-get -y install xinetd​

3. Create the file /etc/xinetd.d/rsync on Amahi box to launch rsync via xinetd.

bash code
​sudo nano /etc/xinetd.d/rsync​

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.

bash code
​sudo nano /etc/rsyncd.conf​

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.

bash code
​sudo nano /etc/rsyncd.secrets​

User should be the same as above, with password the one used to log into/ SSH into the HP/Amahi box. Format is user:password, like below.

kevin:theuserpassword

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

bash code
​sudo chmod 600 /etc/rsyncd.secrets​

7. Start/Restart xinetd

bash code
​sudo /etc/init.d/xinetd restart​

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

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

Now, to setup a backup job on the xpenology box:
1. click "backup" , then "create", then "data backup task"
2. select the folders to backup (pick one with little data or a test folder to make sure it works)
3. select one of the backup destinations you just created and hit NEXT
4. name the task, say "backup of data to Amahi"
5. name the directory on the Amahi share where the backup is going
6. 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.
7. 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.