I have finally installed OS6 onto my Ultra 6+, in order to make use of ReadyDR.
I am pulling the snapshots from a 316, once a day. The smart snapshot schedule on the source is hourly.
Firstly in order to get it to work I had to import the key from the destination onto the source which is the opposite of the instructions on the KB. The instructions to install the key from the source onto the destination NAS only works if it is a push job, it seems if it is a Readydr pull job then the key needs to be generated on the destination NAS and imported onto the source. Is this expected behaviour, if so could the KB be corrected?
Secondly it is not clear what happens with hourly snapshots as the backup time is exactly the same as one of the hourly snapshots. If a snapshot is being taken at the time the Readynas pulls the snapshots what will happen? I think this may have created a problem on my unit where one of the ReadyDR backups stalled. Hovering over the Status indicator showed the backup running and more data transferred than was actually in the share at that time (this was the first backup). All the other Readydr backups had completed and the Readydr shares had exactly the same amount of data as in the source share (as expected).
I was unable to cancel the job, even after a reboot and attempting to disable snapshot access. I was also unable to manually delete snapshots in the destination. I also could not delete the Readydr share as there was an error ( unable to delete snapshot. ) I could delete the Readydr job however. I eventually had to factory default the destination NAS to get rid of that particular Readydr share.
What happens to snapshot pruning in the destination NAS, does this follow the source?
I don't think this has anything to do with the fact that I'm running OS 6 on a legacy unit.
Perhaps the job settings need a more precise time setting to avoid clashes with snapshot times?
Finally after setting up and running just a single Readydr job for a very small share (1.0 MB space) the Readydr share indicates 1.0 MB space used, but on the volume tab the volume data indicates 289 MB of snapshots. If I then delete the Readydr share, this 289 MB disappears. Am I misunderstanding something here?
GTested the volume occupied on another small share and similar outcome. Readydr share indicates 496 MB occupied ( same as source share volume) but volume tab indicates 873 MB of snapshots. If the Readydr share is a backup of the snapshots, surely they should be the same especially as this is the first backup.
Running the Readydr backup again leads to something even stranger. The backup completes but the Readydr share then mysteriously loses some snapshots. There are 78 snapshots in the source share (hourly smart snapshots). The first Readydr backup backed them all up. Running it a second time now there are only 49 snapshots in the Readydr share. Reviewing the snapshots on source and destination it appears that all the retained daily and weekly snapshots have been omitted from the second backup. Only the 48 hours worth of hourly snapshots then monthly snapshots are kept whereas on the source there are daily snapshots and weekly snapshots (which is how smart pruning should work). The smart pruning on the destination is behaving differently .
Swapping to a push job works as expected, all snapshots are backed up and there is no unexpected pruning after the second run of a job. There is still a very large difference in the Readydr share volume compared to the volume occupied by snapshots in the volume tab. It appears then that if the job is setup on the destination NAS, then pruning in the Readydr share does not work correctly on the second run of a Readydr job. Bug?
I suppose I could set it up this way but my destination NAS is only powered on for backups so I want shutdown to be postponed for queued backup tasks. This would not happen if some of the jobs are push jobs. I don't want backup jobs to fail because the destination has shut down and I don't want to have to leave the destination NAS on for longer than necessary.
I spoke too soon. Shortly after my last post it appears that snapshot prune worker on the destination NAS pruned all the daily and weekly snapshots from the DR share, leaving only the hourly and monthly snapshots. This is with a Readydr job set up on my 316 pushing to a Ultra 6 + running 6.6.0. Definitely not working as expected.
Presumably a workaround would be to turn off smart pruning and use some sort of custom pruning. What I'd like to see is that the Readydr job just prunes the same snapshots that the source has pruned.
Have not been able to make some test with ReadyDR. But if I remember correctly, manually created snapshots are not pruned. So it might be the same with ReadyDR.
Yes you are correct but that is not the problem. I have deleted the manual snapshot so now all the snapshots are smart snapshots on the source. The snapshot pruner was removing scheduled snapshots on the destination even though these same snapshots were still present (and should have been) on the source.
1. Setup with keys with a pull job requires key generation on destination NAS to be imported to source, opposite of what KB says.
2. Smart snaphot retention setting in ReadyDR share does not seem to function correctly and inappropriate pruning of some snapshots (daily and weekly) occurs, behaviour is different to that on source NAS. Can work around this by setting a custom retention policy on the destination.
3. ReadyDR does not seem to handle non-scheduled snapshots, the presence of a manually generated snapshot on the source causes the job to hang and the readydr share to become undeletable because of a snapshot deletion error.
4. Occassionally a job will run for the first time and will not backup all snapshots. Once this happens only new snapshots will be added to the readydr share on subsequent runs of the job; the source snapshots missing from the destination are not backed up. Regenerating the job and the readydr share usually solves this,
5. There is a large difference between the snapshot space on the source and destination NAS. In my case (Volume tab) the snapshots on the source are 31GB, on the destination 65GB. This is after the first set of readydr backups.
Hmmm, I thought perhaps Netgear would be interested in feedback about a new feature and responded to this thread by now. The problems I am experiencing must surely have been exposed in testing this feature, if not perhaps Netgear would like to look at my logs to see what is wrong? FramerV, are you looking into this, or reporting it for testing?
The work around I tried to use to overcome the inappropriate pruning of backed up destination snapshots does not work of course as the destination then retains ALL snaphots, it does not simply mirror the source. So with hourly snapshots I see accumulation of snapshots.
Currently the developers are working on issues that have been reported. I am sure that this will be given the same attention as those currently being worked on.
I will be escalating this thread so that it can be looked at also.
I'm not using the beta. I haven't seen anything in the release notes for the betas that suggest this has been fixed! unless the snapshot pruning problem is related to timestamps.
The official 6.6.1 RAIDiator has been released. Even though it did not specify a fix for what you are experiencing it would still be best to update to it. I should at least be able to have your case be checked by then should it still show this issue.
I realise this is an oldish thread, however I have encountered the dreaded "Snapshot deletion failure" error.
I have had to recreate my backup NAS volume and hence recreate all the ReadyDR backups. 4 out of 5 of these ran correctly, however the 5th online backed up 32 of 52 snapshots, no error messages. I deleted the job as running it again made no difference. When I deleted the job, the readydR share remained so I tried to delete this - Error message saying Unable to delete share because of snapshot deletion failure.
This is exactly what I encountered the first time I set this up and I had hope this problem had been fixed.
I really don't want to have to factory default the unit (this is what I had to do a few months ago to fix this) just because of this snapshot deletion failure.
Does anyone have a technique for identifying and eleting these seemingly rogue snapshots?
