Incremental back up vhdx files of Hyper-V Virtual Machines hosted on Cluster Shared Volumes to a network share

It's 2015 so why would anyone still use Windows Server 2008 R2? Windows Server Backup in Windows Server 2012 includes great (but limited,see below) support for CSV backup. Some notes and warnings:

•     Virtual machines hosted on CSV’s cannot be added as part of normal system backup configuration
•     Windows Server Backup has to be configured on all nodes to ensure that backup and recovery will be available in the event of a failure on one of the nodes in the cluster.
•     Volumes recovery not supported - can be cheated
•     Security access control lists are not applicable on CSV file service root. Therefore, file recovery to the root of CSV volume is not supported.

Say you have two Hyper-V hosts, one SAN hosting your VMs' files via Cluster Shared Volumes for your Hyper-V Hosts and you also have four VMs on the Hosts - each has two VMs. You already set up your OS level (e.g. Windows Backup) jobs inside your Hosts OSs and VM OSs and has already been backing up your data to the SAN on dedicated backup LUNs lying on physically separeted fault tolarent arrays. Look sufficient, isn't it.
Actually, it isn't that good. What if your SAN blows up? You lost all your VMs and your VMs' backups at the same time. You also need to have a fool-proof off-site backup and it must be easily handled. Luckily, there is a simple solution without the need to include third party tools, like HVbackup. (which is, anyway, a good one)
Let's say that your first Hyper-V Host server called HOST1 and your VMs running by it are named VM1 and VM2.
So you have a file system on Host1 like this:

as C:\ClusterStorage\Volume4\VM1\ ....

To backup your first virtual guest (with its entire CSV, being on the safe side) on your external backup server share, just execute:

wbadmin start backup -include:C:\ClusterStorage\volume4\ -backuptarget:\\backupserver\vmbackup\vm1

It takes some time:

You can easily restore files from your VM's virtual disk if you find it in the backup:

Then just mount it in your Disk Management (Attach VHD) .....

and then assign a drive letter to it, open your new disk with a file explorer and find your real VD :) inside it. You should repeat above process by attaching this real VD also with your Disk Management console.

In case you need to restore your whole VM (whole means: disaster recovery including all its Hyper-V settings)
Find your backup versions: (if you are lucky enough to have more than a single one)

wbadmin get versions -backuptarget:\\backupserver\vmbackup\vm1

Restoring: (be careful)

wbadmin start recovery -version:02/11/2015-08:25 -backuptarget:\\backupserver\vmbackup\vm1 -itemtype:file -items:C:\ClusterStorage\Volume4\  -recursive -recoverytarget:Z\recover -machine:HOST1

What did I mean when I said backup versions? Have you ever been frustrated that Windows Backup can't maintain multiple versions on a network share? So did I. I've tried to cheat WSB with using a local hardlink pointing out to the network share.
mklink /D M:\MyNetwork \\mybackupserver\vmbackup
and
wbadmin start backup -include:C:\ClusterStorage\volume4\ -backuptarget:\\localhost\d$\MyNetwork\vm1 -quiet
Tadaamm! So far so good.

Unfortunately,
wbadmin get versions -backupTarget:M:\MyNetwork                                               
matter-of-factly answers that it can't be fooled in such a stupid way.

wbadmin 1.0 - Backup command-line tool
(C) Copyright 2013 Microsoft Corporation. All rights reserved.
The backup cannot be completed because the backup storage destination is a shared folder mapped to a drive letter. Use the Universal Naming Convention (UNC) path (\\servername\sharename\) of the backup storage destination instead. 

In short, it sadly won't be versioning, just keeps one full version as usual. Bad luck. Folks say I should use iSCSI based network drives because thats the only way to get WSB versioning. I don't want to bother with this because I already have lots of iSCSI drives from the SAN and I would be a bit afraid of messing up these drives from different sources.

Meanwhile, here are some useful facts from Technet topics to consider about WBS: 
You can also set -vssFULL  parameter in backup jobs but there's not much use in doing so. According to the manual: "If specified, performs a full backup using the Volume Shadow Copy Service (VSS). Each file's history is updated to reflect that it was backed up. If this parameter is not used, wbadmin start backup makes a copy backup, but the history of files being backed up is not updated." In short: "vssfull is only meaningful if there is another 3rd party backup application is being simultaneously used on the same machine along with server backup application and you have application like exchange running on the machine who have vss writers. if that is not the case - it can be ignored and defaults will work fine."
And "All backups after first backup automatically takes incremental storage space on the backup location since changes are tracked using volume shadow copy on the backup location. This incremental storage space is proportional to the changes from the last backup."