I have a couple of old Sparc Duos that I am wanting to transfer the data to my new(to me) RN104. One of them has 0.2TB, the other 1.8TB data. I have previously transferred about 80% of the data from the 1.8TB Duo to the RN104
I have set up Rsync backup job on the RN104. It has been running for 60 hours now and is still "in progress". There are two issues:
1. Only one folder has not been replicated in full, and there have been no files copied for over 24 hours now.
2. The folder timestamps are showing the date copied, not the date on the original folder structure
There is no log of the backup job visible, is there any way to discover what the RN104 is actually doing.
I am thinking I should cancel the job, and either rerun it, or simply create a new job to run against the folder that hasn't been fully copied yet, but thought it would be sensible to ask for advice before I press the big red button.
I have made a previous posting about the folder timestamps, but didn't get the issue fully sorted. I am forming the opinion that OS 6 is much more about presentation that actual data handling as my Rsync jobs on the Sparc boxes always copied over the folder last modified dates faithfully
Thanks in advance for any help
ps, RN104 is running 6.6.0, the Duo is running 4.1.13
It does sound too long. Has the initial RN104 raid sync completed?
I haven't done this in the v1->OS 6 direction lately, but I do have daily rsync backup jobs in the OS 6 -> v1 direction. I run those on the v1 systems though.
I've run into your performance problem, but I have seen issues with UID/GIDs not being mapped. Generally I've found it works best if the user/group is set to admin/admin. Other options might work also, that's just what I use.
I've also seen the folder date problem. Though it's not a big deal to me, it would nice if that were fixed.
I am forming the opinion that OS 6 is much more about presentation that actual data handling
Rsync has been the same for years. There are fundamental differences in the OS 6 file system (btrfs), which enable a very different (and more useful) snapshot model.
