This post shows how to set up a rsync backup between a TrueNAS 15.10 source and a QNAP QTS 5.2.10 target via rsync over ssh with ssh keys. The QNAP system will reside in a different household and be reachable over tailscale from this NAS. It’s the “one copy off-site” part of the 3-2-1 backup strategy).

Note: In previous TrueNAS versions, TrueNAS required that both the source and the target system of an rsync backup task had to have the same user setup (the name must match the unique administration user created on both systems for the rsync task to work, source). At least in version 25.10 this is NOT the case anymore and different usernames on different systems work. (Don’t ask how many hours I wasted by following older tutorials which still followed this)

Create a new SSH key pair on the TrueNAS side Link to heading

  1. Go to Credentials -> Backup Credentials and add a SSH Keypair (the dialog allows to generate a new key pair, don’t reuse a real user key!)
  2. Copy the public key to the clipboard so it can be added on the QNAP side.

Prepare the QNAP side Link to heading

The goal here is to have an account which has write access to a specific folder and is accessible over ssh via the generated ssh key pair. These steps set this up for a QNAP system. It was tested with an aging QNAP TS-253 Pro running QTS 5.2.10.3377 (thanks to QNAP for supplying that aging systems with updates!). I hope I got all the steps as I did not start fresh.

  1. Add a new volume for the backup: Storage & Snapshots -> Storage/Snapshots -> add a new volume under a storage pool. I suggest to add snapshots as well, then deleting stuff will still keep some backups on the QNAP side (I’ve snapshots “on” on both sides!).
  2. Add a new shared folder: Control Panel -> Shared Folders and put it on the newly created volume. That new shared folder will show up as /share/<chosen-name>. e.g. /share/rsync-backup
  3. Add a new user with a nice long password: we only use this user for ssh rsync calls, so only very seldom logins into the UI… Give it admin rights by adding it to the “administrator” group (only admins can log in into a QNAP systems via ssh :-(). Allow that user read-write access to the new shared folder and the “homes” folder (to add a $HOME where the ssh config can be stored)
  4. Enable ssh: Control Panel -> Telnet/SSH. Enable “Allow SSH connections…”. In the same page, “Edit Access Permission” and enable the new user to access via SSH. Look at the port (usually port 22), you will need it on the TrueNAS side.
  5. Login as that new user and go to Login and Security (e.g. via the dropdown next to the name in the top menu bar) and in the opened dialog to the SSH Keys tab. Try to add one: it will ask you to choose a $HOME folder. Set it to a folder the user has access to (i.e., the “homes” one which we gave read-write access to a few steps above). Then add the ssh key by pasting the key from the TrueNAS side.

To enable restore in a disaster case (the private key is gone!), another user MUST also have access to the network share. So configure at least read access to the network share for a second user on the QNAP!

Set up the rsync backup task on the TrueNAS side Link to heading

  1. Under Credentials -> Backup Credentials, create an SSH Connection. Set the “Hostname”, “Port”, and “Username” as configured on the QNAP side. Chose the “Private key” to be the ssh key you’ve created earlier. Use “Discover Remote Host Key”, to see if the TrueNAS system can access the QNAP one.
  2. Under Data Protect add an Rsync Task. As “Path” chose the dataset you want to back up to the QNAP NAS: I’ve chosen a top level data set as I wanted to back up everything below that top level dataset. The “User” should be able to access all the data, so I chose “root”. Direction is “Push”. As “Rsync Mode” chose “SSH” with an “SSH connection from the keychain”. Chose the “SSH Connection” created in the step before. The remote path should be under the shared folder path you created on the QNAP. I chose /share/rsync-backups/nas/<source-host>/ to have the possibilities to have other stuff backed up next to it (Note: rsync adds the dataset as a subfolder there, so you do not need to add a dataset name into the path). By enabling “Validate Remote Path” you get a response if that path is accessible to the user when clicking save (if it doesn’t exist yet, it will fail!). Schedule as you wish and both have the checkmark under “Enable” and “Recursive” (to actually back up stuff from subfolders of the chosen dataset). I checked “Times” and eventually “Delete” in the “More Options” section. “Compress” did not work (some “STREAMIO” error I did not bother to figure out). I did not choose “Preserve Permissions” as everything I back up this way is user content which likely anyway gets it’s permission adjusted after a restore (system content gets rebuild…).

The “Validate Remote Path” on “Save” is nice, but the real check is actually running the backup task. If that fails, the output I got was usually short and cryptic.

  • You can find out what concrete rsync command is run under System -> Audit -> “Service: Sudo”.
  • The logs for each job are available in the “jobs page” (https://<nas-host>/ui/jobs). It’s available in the menu bar at the top under the clipboard icon -> “Go to Jobs Page”. If the log is missing something: sudo less /var/log/jobs/<job-number>.log should give the full one. In my case it showed that some subfolders could not be accessed.

I added backup rsync tasks for all relevant top level datasets on my TrueNAS. This turned up surprisingly many, as I added top level datasets for a lot of things.

Using tailscale for the connection Link to heading

As the QNAP NAS will not be reachable directly from the internet, only via tailscale net. Tailscale is installed as app on the QNAP and the TrueNAS system. These apps work in a totally different way: on QNAP it’s a regular process on the host, on the TrueNAS system it’s a docker container. In my system I could ping the QNAP NAS from the TrueNAS shell, but name resolution needed an additional DNS server configured.

  • At one point in the past, I added a bridge to let the containers communicate with the host : Accessing NAS from VMs and Containers. I’m not sure if this is required here, but I guess it won’t hurt either…
  • Under System -> Network in the “Network Configuration” settings, add 100.100.100.100 as the first DNS server (inspiration). Adding it as secondary will not work as the resolution stops with the top level domain ts.net, but not the tailnet hostnames names as in qnap-nas.funny-name.ts.net.
  • Configure the QNAP host name in the SSH Connection (Credentials -> Backup Credentials) instead of the local host

Verify the backup Link to heading

  • The rsync backup task should show a successful run. If it cannot access a source subfolder, it will fail (check that with a different user and that you get an e-mail alarm!)
  • I checked on the target side via the QNAP file station app to check if subfolders were there and had a sane size.

Verify that a failure ends up as an email in your inbox Link to heading

Emails are configured under System -> General settings -> “Email” widget.

Invalidate the hostname or change the user running the rsync task to see if failures show up in your mailbox.

Verify that restore works Link to heading

My use case is to restore particular files in case my TrueNAS system has catastrophic damage. In such a case, I expect that I need to rebuild the NAS from scratch and I accept that restoring the data will need some manual work (manual copy the data, adjusting permissions). For that reason, my restore check is that I can copy the files via rsync or ssh to my local laptop which has ssh access to the QNAP and have granted read access to the backup “Shared Folder”.

# login to the qnap nas to snoop around
ssh <laptop-account>@<qnap-nas-host>
cd /share/rsync-backups/nas/<source-hist>/<dataset>/
# This should show everything you expected
ls -la
exit

# Restore a file to the laptop
rsync -rvz --partial "<regular-user>@<qnap-host>>:/share/rsync-backups/nas/<dataset>/file.pdf" ./whatever