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

Question

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 &rarr; 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?

Tim Seymour · Accepted Answer

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.

Tudor.Popescu · Answer

Hi Brian: 
The "Transfer has been deactivated" message does not mean that "All transfers have been deactivated for that server"; it means that a queued transfer has been removed from the transfer queue before it could start transferring data because of a scheduled constraint. 
For instance you allow backups to be performed for a specific agent only between 5PM to 7:30PM and 1 hour intervals. 
A backup starts at 6:00PM as scheduled but due to the amount of data did not finish by 7PM. As such the 7PM job is put in a waiting queue. If by 7:30PM the job that started at 6PM is still running, the job that is in the waiting queue since 7PM is dropped since no new backups are allowed after 7PM and the "Transfer has been deactivated" is generated. The best way to check what is going on is to reference the recovery points that you have for your machines with the schedule and the events in the Tasks/Alerts/Journal pane. Specifically the journal pane gives you granular information about the activity of your core. 
If the behavior pattern described above does not reflect you setup please let us know (and you may open a case with our support team to investigate the issue). 
 
The second question is related to an arbitrarily chosen threshold of 30% designed to draw attention about your available free space. This is helpful only on small volumes with a lot of activity (i.e. volumes containing Exchange logs/databses) that would trigger VSS growths over the accepted 10% mandated by Microsoft combined with a quick increase of the data hosted by these volumes (i.e. Exchange logs)