In a recent blog post, I explained my approach for securing my data on a NAS. In this blog post, I’d like to explain how I back up my home NAS to a remote NAS by showing the (somehow gimmicky) process of setting up an automatic backup process from a Synology NAS to a «WD My Cloud Mirror Gen 2» NAS (short «WD My Cloud» hereafter). If you have recently upgraded from a WD NAS to a Synology NAS, this may help using your old NAS as a remote backup destination, rather than throwing it into your basement. The main motivation of doing this is the implementation of a 3-2-1 backup strategy, explained in this blog post.
This article is based to a large extent on a blog post by pentestit.de and I would like to give them credits for laying the foundation of this post. In this post, I will not only summarize their approach but also show some refinements I made as well as highlight some of the caveats I encountered following their approach. Finally, I will try to break down certain concepts into simpler language for non-experts and explain how I specifically implemented my off-site, remote NAS backup.
This tutorial presumes that the reader has basic knowledge of linux, IPv4 addresses and port forwarding. Basic knowledge of rsync is of advantage.
The approach proposed in this article is using Synology’s pre-installed remote backup utility “HyperBackup”, which cannot only create one-off backups but is capable of backing up file history and versions in a smart way, thus working similar to the pre-installed utility “Time Machine” in MacOS. HyperBackup cannot only backup to other Synology NAS but also to any Linux server with rsync, as long as the server has a public and stable IP address. The latter approach is explained below. In the text below, I will call my Synology NAS, which sits at my home office, my «Origin NAS» and I will call the WD My Cloud NAS, which sits in a relative’s apartment, my «Remote NAS».
Having a static IPv4 address on both the home NAS and remote NAS are an important condition for being able to follow the instructions below. Nowadays, many internet carriers don’t offer static IPv4 addresses anymore but only dynamic IPv4 addresses, which change regularly, using so-called Carrier-Grade NAT (CGNAT).
While this is not an issue for most “normal” internet users, it may cause issues to people who want to set up a home server or a smart home. I am based in Switzerland and subscribed to an internet package by Salt, who charge an additional 10 Swiss Francs per month for having a fixed IPv4 address (on-demand, need to call hotline). At the location of my remote NAS, the internet provider is Sunrise, who does currently not use CGNAT and seems to provide semi-static IPv4 for free. That is, over the months of using the remote NAS, I’ve noticed that the IPv4 address may change when the router is restarted, but it remains static thereafter.
Preparation on Remote NAS
The first step in setting up the remote NAS as a backup source is to access WD’s web interface. From there, one needs to perform the following steps:
Outside of the NAS interface, you need to do the following things:
ssh [SSH_USER]@[REMOTE NAS IP ADDRESS] -p [REMOTE NAS SSH PORT]
`#from the Synology NAS, connect to the WD NAS via SSH.`
`#starting on the lines below, we are connected to the remote NAS via SSH.`
`#on the remote NAS, first, use the command "echo…" to write the following lines to a file rsyncd.conf (end on line 20)`
echo "use chroot = no
uid = root
gid = root
secrets file = /etc/rsyncd.secrets
pid file = /var/run/rsync.pid
timeout = 300
Hosts allow [ORIGIN NAS IP ADDRESS] `#Specifically allow origin NAS IP to connect to the remote NAS`
`#define target rsync process for backup process`
[ [PROCESS_NAME] ]
path = /mnt/HD/HD_a2/[PARTITION] `#location where backup will be saved on remote NAS`
read only = false
list = yes
auth users = [SSH_USER]">/etc/rsyncd.conf `#add SSH user name to authenticated users`
`#write user password(s) in secrets file`
echo "[SSH_USER]:[SSH_PASS]">/etc/rsyncd.secrets
`#restrict access to secrets file`
sudo chmod 600 /etc/rsyncd.secrets
The [PROCESS NAME] variable can be set as wanted, e.g., “SynBackupWD”. This will later show up in the list of available rsync processes.
The code lines above fully set up the rsync client on the destination NAS, in this case, WD My Cloud. What’s practical about this approach is that by using an SSH connection, you can always re-do these steps if the rsync client ever stops working on the destination NAS. This typically happens if the WD My Cloud NAS installs automatic firmware updates, in which case it restarts. Whenever the WD My Cloud NAS restarts, the files written above are erased. I tried adding a CRON job, in order to avoid manually restarting the rsync process every time, however, there seems to be no easy way to do this on WD NAS devices currently.
Now, on your Synology NAS, connect to the rsync server:
And that should be it! Please let me know if you found these instructions helpful and or if you have any refinements for this blog post.