I’ve had a primary NAS and a backup.working for years in a primarily Windows environment. Over the last year, I’ve moved to a primary Linux environment. When backing up my Linux directories using the Samba connections, I noticed my Linux file read-write-execute permissions were not being properly maintained, so I’m switching to rsync. So far, I’m using command-line rsync to copy my host files to the master NAS using a mounted drive:
sudo mount -t nfs4 -o “vers=4.0” fastnas:/Private /mnt/fastnas
This is all working. Files are copied to the NAS, and retain their original ownership and permissions.
The last piece is using HBS 3 to copy these files to the backup NAS. I configured the backup NAS as a Remote Rsync Server. I can successfully create an HBS 3 job to copy a single folder from the master NAS to the backup, and again files are copied to the backup NAS, and retain their original ownership and permissions.
Finally, my question: in this configuration, HBS 3 limits jobs to a single folder pair. My biggest job has 12 folder pairs. With some help from Google Gemini, I got this working by creating 12 different jobs, one folder per job, and daisy-chaining them to run one after the other. This works, but it is painful to configure. Why does HBS3 have this restriction? It could easily allow multiple folder pairs just like it normally does, and if necessary, sync each folder sequentially, one at a time.
Before digging into why the rsync path behaves that way, I assume both ends here are QNAP NAS units, have you considered adding the backup NAS as a Remote NAS (RTRR) destination rather than a Remote Rsync Server? an RTRR job supports multiple folder pairs in a single job, so your 12 pairs would be one job instead of 12 daisy-chained ones.
Was there a particular reason you chose the Rsync Server destination over Remote NAS?
On the rsync folder-pair limitation itself: we’ve taken it in as a product requirement and it is now in evaluation on our side. Thanks.
NA9D, thanks for the reply. I’ve successfully had sync job running for several years, employing multiple folder pairs. This new job is specifically using “Remote Rsync Server”, which is different. As i explained in my initial post, using a simple sync job resulting in my Linux scripts ending up with changed rwx permissions on the NAS. I didn’t pay much attention previously because my workstation environment was primarily Windows. Now that I’ve shifted my workstation to mostly Linux, I’m paying closer attention and seeing the change in my script permissions. I don’t want that because if I should experience a failure on my workstation, I don’t want to spend a lot of time fixing the script rwx permissions.
Hi everyone, I use QTDsync to synchronize my server with Windows. As for RRTR, it allows for synchronization between two Qnaps, not between the operating system and the Qnap.
Following up with the update I mentioned. I just tried RTRR, and can confirm it is working again. I don’t use the backup server for real-time backups; I don’t keep my NASs powered up 24/7, so I only do backup when I deem necessary by manually invoking an HBS 3 job.. I would still prefer an rsync solution. When I tried a backup just now with multiple folder pairs, the files and folders on the master NAS matched those on my workstation with both permissions and timestamps, as I would expect since I use rsync to copy the updated files, and I specifically request it to preserve timestamps. However, when I ran the HBS job on the master to replicate to the backup, the timestamps on top-level recently updated folders were not correctly replicated on the backup NAS. Just the root folder timestamp was incorrect; all the folders and files within it had timestamps matching those on the master NAS. And timestamps on less recently updated top-level folders were correct (looks like folders with a timestamp earlier than the current date are replicated correctly.)
When I replicated to the backup NAS configured as a Remote Rsync Server, all top-level replicated folders on the backup had timestamps matching those on the master.