This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Appassure 5.4.3 replicating to RR6.1.x - slow

I have a appassure 5.4.3 core replicating to RR6.1.2 (newly upgraded).

It appears to be taking ages to complete the replication.  The actual transfer of the data is still quick but it just sits there on'updating the agent and volume(s) metadata' for ages.

Is this a known problem?

  • appears to be Exchange & SQL agents experiencing this issue
  • have been asked to upgrade the source core to version 6.1.2, needles to say that isn't happening.

    They say they support 5.4.3 replicating to 6.1.2 but actually they don't beyond getting you to upgrade...

    No fix at present.
  • I would raise this issue higher, like you are doing here or have the case re-assigned. You have to play roulette with support people till you get one that is decent. I always feel bad for the good engineers at Quest as they do way more work than the others, even if the number of cases closed maybe the same.

    This seems to be a fairly common tactic with some support people. They will demand you upgrade and refuse to continue trouble-shooting until you do. I have had this happen on cases where I am a patch or two behind (patch, not release) but they still demand I upgrade. The patch notes will not have a single fix related to my issue and they wont give me any logical reason to apply the patch. But they will refuse to move forward and ignore all my requests until I upgrade.
  • Yeah, the engineer i'm working with has been there a while and is normally ok. I haven't worked with him for a couple of years as I haven't needed to.

    Dev asked him to get me to upgrade, I've sent him back to Dev.

    I have also discovered that purging a multitude of recovery points (2000>200) has sped this up, it seems as though it feels it needs to update every single recovery point that is on the target system on every single replication. I can't see why it needs to do that and I also can't rely on having RP's down as low.

    It still takes 10 minutes to perform the post replication agent and metadata updates and I just think it must be possible to be smoother and more efficient. My replications in general are far behind where they ever were before we upgraded and I have large amount of replication queued up nowadays and I think they are all related to this component. I also believe that this is making everything far slower than it used to be.

    in case anyone is interested, case #4069749.

    Have you noticed that the infoGatheringTool is a lot slower, but if you uncheck the 'collect recovery points' option it is far quicker. Looked at one of the archives that did complete and apparently this folder is >1GB in size when extracted
  • I can't say that I had spent much time on replicating AA to RR, other than just to make sure it works. So after reading your post I purposely spun up a couple cores to test this out.

    I found that RR replication to RR was actually slightly slower in job than the AA cores were into RR. This included FSs, DCs, and SQLs (I didn't have an Exchange available to test that). The target cores was the same for all the tests, the sources were identical VMware VMs running on the same Datastores (as were their repos). The replication from AA to RR was from a range of 25 MB/s - 34 MB/s across the agents, the replication from RR to RR was a range of 18-28 MB/s. The RR core was a vanilla 6.1.2 without a patch or reg change, the AA core was 5.4.3 with P-1517 and no reg changes.

    Just an example of what I see when I try to perform what you've mentioned. Also as far as the speed of the infogatheringtool that does overall take longer than the old support bundle, I would agree with you there. As well as with your statement about the RPs, without having to gather that data that is one less task to complete.
  • had an update from development. "they expect it to be quicker, is it still slow"
    not bad for 19 days work