NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyDR setup
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?
17 Replies
Replies have been turned off for this discussion
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.
- I have updated and will see if it works.
Hi vandermerwe,
Just would like to verify if the firmware made any difference.
Regards,
- Well I haven't yet tested every problem I reported, but the snapshot retention pattern seems to be correct with daily smart snapshots.
Hi vandermerwe,
Thanks. Please keep us posted.
Regards,
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?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
