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

Transfer has been deactivated / some volume have not enough free space

I have gotten a rather useless "Transfer has been deactivated" notice for two of my four RapidRecovery client servers. A search of the cause at first seemed to indicate a possible problem with the number of concurrent snapshots here: https://support.quest.com/rapid-recovery/kb/211305, with follow-up here: https://support.quest.com/rapid-recovery/kb/211305. However, I have four client servers, with all drive backup times staggered to avoid system slowdowns. Maximum concurrent transfers was set to 3 (just reset to 4), but I had two of the four servers for which RR generated this message. So I suspect it may be something else.

1) So, first part of the question: where can I tell exactly why I got this message.

2) Second part of the question: I may have inferred the cause here. For some of the drive letters under Summary → Volumes, I see a yellow square with white exclamation mark, and when I hover over it, I see this: "Some volumes have not enough free space. Please, pay attention that transfer may be failed for full volumes." That seems to be the one thing I can see that the two clients have in common. Despite the obvious grammatical clues in that statement that indicate that the software was written overseas, I think I get the drift; however, in one case, I have 375.25 GB used of 511.97 GB, and in the other case, 96.63 of 127.48. How is that a problem?

And how do I determine definitively if the deactivation actually occurred because of #1 or #2 above?

Parents
  • 1) In the journal section of the events tab you should be able to see every action the core is taking. So you should see it queue the transfer jobs and then see them get deactivated. If you compare time stamps you should be able to see what jobs were running that were blocking the transfers from starting so that when the backup window ended they were deactivated. It's very possible that a job like rollup was blocking the agent from taking a backup.

    Basically the deactivation message means that a transfer job had been put in queue to run, but because it was unable to start during the backup window, it was deactivated and blocked from starting. The only way to ensure you never see this warning is to change your scheduling so that the backup window is 24 hours a day and then set your interval so that it matches the schedule you want. Otherwise it is always possible that a long running job that conflicts with a backup may cause a transfer job to be held in queue until after the backup window and deactivated.

    2) The warning threshold in Rapid Recovery for volume free space is 30%. This was an arbitrary number chosen by our Product and Dev team. Please note this is just a warning and has no bearing on any other portion of the software or the ability of the software to take a backup. It is simply alerting you that free space is getting "low" (depending on your definition of low). I can guarantee this has nothing to do with #1.
Reply
  • 1) In the journal section of the events tab you should be able to see every action the core is taking. So you should see it queue the transfer jobs and then see them get deactivated. If you compare time stamps you should be able to see what jobs were running that were blocking the transfers from starting so that when the backup window ended they were deactivated. It's very possible that a job like rollup was blocking the agent from taking a backup.

    Basically the deactivation message means that a transfer job had been put in queue to run, but because it was unable to start during the backup window, it was deactivated and blocked from starting. The only way to ensure you never see this warning is to change your scheduling so that the backup window is 24 hours a day and then set your interval so that it matches the schedule you want. Otherwise it is always possible that a long running job that conflicts with a backup may cause a transfer job to be held in queue until after the backup window and deactivated.

    2) The warning threshold in Rapid Recovery for volume free space is 30%. This was an arbitrary number chosen by our Product and Dev team. Please note this is just a warning and has no bearing on any other portion of the software or the ability of the software to take a backup. It is simply alerting you that free space is getting "low" (depending on your definition of low). I can guarantee this has nothing to do with #1.
Children
No Data