I just did the transition from "ReadyNAS Replicate" to "ReadyDR". I'm using two RN312 NAS'. One is the main NAS server and the second is the BACKUP NAS.
The first problem I encountered was, that older snapshots from 2014 seemed to be a problem. I always received an error message like "Operation not permitted" when I tried to do the INITIAL very first and large, complete data transfer. When I checked the result after the (failed) end of the backup, I saw that these older snapshots were missing. OK, so I deleted these old snapshots from my main NAS server and tried everything again. Result -> No error message -> Happy user -> OK so far.
During the setup process I configured the ReadyDR job for a daily backup (the same rhythm as my snapshops on the main server) with INSTANT BACKUP. It says, that -> "Instant Backups send the snapshot immediately "AFTER" it is taken".
Unfortunately, now I receive an error message every morning, that there was a problem with the backup at midnight -> "Operation not permitted". When I check the history I can see, that the ReadyDR backup seems to start at about 00:00:30 and fails (Operation not permitted). The ReadyNAS system seems to try to do the ReadyDR backup again at about 01:00:00 (I don't know why), and THIS backup seems to succeed.
It almost seems, that the now snapshot is not ready, when the ReadyDR backup starts?!?!
What is wrong here?? For this night (and the coming ones), I changed the ReadyDR backup schedule from INSTANT to PERIODIC and defined a time window from 03:00:00 - 04:00:00 in the morning. But this can't be the the right solution when there is an option called "INSTANT BACKUP".
After setting the backup option to "PERIODIC BACKUP" and the start time to 03:00:00, I received the same error message today at 03:00:00 "Operation not permitted"! Whats wrong here?!?!
You might need (paid) support via my.netgear.com for this, and not the community support that is offered here. If you purchased your RN312 between 1 June 2014 and 31 May 2016 then you have lifetime free chat support.
Another (brute force) approach is to rebuild the source NAS (factory default) and then restore the NAS from backup.
Have you contacted NETGEAR Support about this? Do you have a case number?
It would be best if you contact NETGEAR about your issue specially if you need urgent assistance.
this is a Community support and is used for discussions, communications and sharing of knowledge which is available for you to check but we cannot oblige any members to answer your query right away.
"Unfortunately" we bought the two NAS we are using in January 2014, so no support....
To be quite honest we do not want to buy a "SUPPORT" from Netgear. It should be a matter of course , that if there is a question or problem, that Netgear tries to help directly. OK, perhaps not via telephone or chat, but I just saw that even email support is not available... so without money no direct support from Netgear 😞
The last days we saw that our NASs have the names "NAS_Backup" and NAS_Server". We chose these names 4 years ago and the systems accepted the names without any problem. Now, I saw that the "_" character could be a problem. The questions is: Is it really likly that the "_" causes this problem. We really only want to change the NAS names if it is probably the solution. We use the NAS names at several locations in our company and would have to change all of them. After we change the name, we can not change it back.
To be quite honest we do not want to buy a "SUPPORT" from Netgear.
They do charge for support after 90 days, and that was their policy when you purchased back in 2014. Of course, one way or another the customers always pay for support - either they purchase it separately, or the support costs are bundled into their original purchase price. Similarly, the warranty costs are always bundled into the purchase price. Otherwise, the vendor quickly goes out of business. As noted above, I don't work for Netgear.
Just guessing here, but I doubt your problem could be resolved by their Tier-1 support, I'm thinking it would need escalation to a Tier-2 or Tier-3. It's not something I've seen posted here before.
wrote:
Now, I saw that the "_" character could be a problem. The questions is: Is it really likly that the "_" causes this problem. We really only want to change the NAS names if it is probably the solution.
It seems unlikely that the "_" causes your problem, since only some snapshots generate the error. You can test it by setting up a test ReadyDR backup job that uses the NAS IP addresses instead of their hostnames. But if the solution (or some future issue) requires a factory default, then you will be forced to change the hostnames, since you can no longer enter a name that includes the "_" character.
My guess is that your issue is related to a BTRFS issue with the specific snapshots (or perhaps shares) that generate the "Operation Not Permitted".
The last three weeks we made extensive tests to find the reason for the problem "Permission Denied" that we described.
There is one thing that really puzzles us:
To localize the problem, we created a new share (directory ) on our RS312 server , we put some data in it (some data from our main share) and created a ReadyDR job for a automatic daily backup. The result was that everything worked fine and we received the message: "ReadyDR Job xyz completed successfully." Sounds great!
After that we copied ALL data from our main share (40GB) to the new share and tested the backup. Still everything worked fine.
At this point, our main share and our test share data was identical. The automatic ReadyDR backup of our test share worked great, but the backup of our main share failed every single night. ("Permission denied").
So we desided to rename our main share to "xyzOLD" and renamed our test share to the same name as our original share (the main share name is really simple, 11 characters, no special symbols, only lower case letters and one leading upper case letter).
From this point on everything went south. We again got the message "Permission denied" and the backup failed.
What could be the reason for that?? The physical data and core of the "new" share must be okay because it was freshly been created.
