What you seem to be looking for is the --link-dest functionality that is part of rsync. What you seem to describe is exactly how dirvish operates.
The link-dest option creates hard-links from the destination path to another copy of the structure.
With dirvish you perform an initial backup, which just uses rsync.
After that each additional back, is hard-linked to the previous successful backup. Meaning there is no duplication of files. You can directly access any single backup from within the vault, and each backup is a complete and full backup. You can remove previous backups at any time.
Here is a script that you can use to demonstrate.
# create test area
mkdir -p /tmp/backuptest/{source,dest1,dest2,dest3}
for a in `seq 10` ; do dd if=/dev/urandom of=/tmp/backuptest/source/file$a bs=1M count=1; done
# look
find /tmp/backuptest/ -ls ; du find /tmp/backuptest/
# initial backup
rsync -va /tmp/backuptest/source/ /tmp/backuptest/dest1/
# look
find /tmp/backuptest/ -ls ; du find /tmp/backuptest/
# make chagnes
rm /tmp/backuptest/source/file[2-4]
cat /tmp/backuptest/source/file[6-7] >/tmp/backuptest/source/file11
# new backup linked to previous
rsync -va /tmp/backuptest/source/ /tmp/backuptest/dest2/ --link-dest=/tmp/backuptest/dest1/
# look
find /tmp/backuptest/ -ls ; du find /tmp/backuptest/
# make changes
rm /tmp/backuptest/source/file5
cat /tmp/backuptest/source/file[5-7] >/tmp/backuptest/source/file12
# new backup linked to previous
rsync -va /tmp/backuptest/source/ /tmp/backuptest/dest3/ --link-dest=/tmp/backuptest/dest2/
# look
find /tmp/backuptest/ -ls ; du find /tmp/backuptest/
# remove dest1
rm -r /tmp/backuptest/dest1/
# see your dest2, and dest3 are still complete backups for the state at those times.
find /tmp/backuptest/ -ls ; du find /tmp/backuptest/
The rsync command's -H (or --hard-links) option will, in theory, do what you are trying to accomplish, which is, in brief: to create a copy of your filesystem that preserves the hard linked structure of the original. As I mentioned in my answer to another similar question, this option is doomed to fail once your source filesystem grows beyond a certain threshold of hard link complexity.
The precise location of that threshold may depend on your RAM and the total number of hard links (and probably a number of other things), but I have found that there's no point in trying to define it precisely. What really matters is that the threshold is all-too-easy to cross in real-world situations, and you won't know that you have crossed it, until the day comes that you try to run an rsync -aH or a cp -a that struggles and eventually fails.
What I recommend is this: Copy your heavily hard linked filesystem as one unit, not as files. That is, copy the entire filesystem partition as one big blob. There are a number of tools available to do this, but the most ubiquitous is dd.
With stock firmware, your QNAP NAS should have dd built in, as well as fdisk. With fdisk, create a partition on the destination drive that is at least as large as the source partition. Then, use dd to create an exact copy of your source partition on the newly created destination partition.
While the dd copy is in progress, you must ensure that nothing changes in the source filesystem, lest you end up with a corrupted copy on the destination. One way to do that is to umount the source before starting the copying process; another way is to mount the source in read-only mode.
Best Answer
The issue here is that if you want to keep a copy of the whole versioned backup on a remote location, you're going to have to handle the fact that rsnapshot rotates the directory names whenever it runs, so you'll end up with a fresh copy of the most recent backup being copied over every time.
You can alter the way rsnapshot runs in terms of when it performs the copies and when it rotates (renames) the directories and you can also execute scripts at various points in rsnapshots execution cycle, like before or after a specific backup point is run.
There's a helpful post here:
https://stackoverflow.com/questions/10691522/mirror-rsnapshot-backup-directory
Another approach is to get a copy of rsnapshot on your second machine and have it backup the contents of /snapshot_root/daily.0 AFTER your main back has been completed. This, in conjunction with the correct rsync flags will give you an incremental copy of your latest backups.