What causes this error is pretty straightforward. The error is caused by the fallocate command failing and returning with an exit code of 1 (fail) as opposed to succeeding and returning an exit code of 0.
The error in and of itself does not effect the system, it is actually a symptom of an underlying problem.
The root cause could be an attempt to allocate more space for a file than the system has available or perhaps a corrupted filesystem (whether actual or virtual disk). I would expect the full error in the first case to be fallocate failed: No space left on device
A failure to deallocate space could also throw an error. This IMHO would point toward the aforementioned corrupt filesystem.
If you do not have a current backup/image/clone of the filesystem in question it would be prudent to make one. Doing so would ensure that you could return to where you are now without having to be concerned about the unintended consequences of rebooting the VM. If the underlying disk hosting the filesystem is damaged you may wish to use something like ddrescue in an attempt to preserve as much as possible from the physical disk. This message will not cause a failure to reboot the VM however do not take that statement as a guarantee that your VM will reboot successfully. Anything can go terribly wrong at any time and a detailed view of the future is not something I (or anyone) can provide for you.
For more detail on the fallocate command see man fallocate
EDIT: It's entirely likely that your R1Soft backups are using snapshots without your knowledge. See this which seems to increase the relevancy of the link you posted in your question. It would seem to be worthwhile to check the version of the driver/agent installed on the system to ascertain if you have the latest version and whether any bugs have been squashed that would indicate whether you should update it or report a bug.You might consider exploring alternative backup methods in the interim for safety if at all possible.
