Has nothing to do with backing up files...
Veeam in our case is used to backup Hyper-V VMs. Besides and parallel to that, we also do Veeam replicate them offsite. Since I discovered through an earlier ticket with support, that Veeam does NOT backup the VM xml files itself, but instead parses the xml and sort of "reconstructs" that information at the offsite location, with Replication, you DO NOT get an exact copy of the XML. For instance, online VBR backs up a VM which has 128Gbytes of Memory allocated on the Hyper-V Host. If you replicate that offsite to a Hyper-V Host which only has 32 Gbytes of Memory, Veeam will automatically adjust the Memory-settings on the Replica-VM to make it able to "fit" on the target-host. This is NOT what I want. I want to have that replica to have the exact same settings, thus 128 Gbytes of memory, even if that means it won't start and you can't do a direct failover! So, I have to resort to some other way to have an exact offsite copy of the XMLs. File Copy Job to the resque. Only to find out, I cannot select the "Virtual Machines" folder as source, because doing so will include the folders inside that folder which holds the Memory State (BIN) files, which are in use for running VMs. I would thus need the File Copy Job to be able to Select a folder and exclude subfolders, or it should be able to select a folder with a filemask-wildcard, eg. D:\Hyper-V\Virtual Machines\*.xml. That way, it would simply copy those XMLs to offsite, ignoring the in use BINs in subfolders under it. Don't need those as an offsite disastercopy anyway. Yes, I know I can create a script, schedule that on Task Scheduler and use that to copy what I want offsite. But then it's just another thing I as Admin will have to find a workaround for (see earlier Feature requests and tickets under email@example.com
-account if you like)... I feel that, while Veeam is a very very good and robust product, it really lacks alot of flexibility and ease of use functions for the Admins it is targetted at using it:
I can't have a VBR on-site which "syncs" with an offsite VBR for disaster-recovery. I need to manually schedule a Config backup File Copy to offsite and I need to manually restore that backup offsite before use in case of disaster.
I can't schedule pre/post scripts in any way besides just pre/post. I also can't run those scripts using different credentials, even though all the rest of the distributed environment uses credentials to setup ?!?
The scheduling-options are quite inflexible, try running a Job every 6 hours, starting it 20:00 ?
We are backing up the Hyper-V Replicas. Yes, we don't backup the live VMs from the live hosts, we backup the Hyper-V Replicas from a Hyper-V Replica DR solution. For one ,this consolidates all VMs on one host, and more important, it has Zero performance impact on the live hosts and VMs. We are aware of the implications: No Guest VM processing, only crash-consistent backups, reduced restore-capabilities, etc. We also do the offsite replication from that Hyper-V Replica. Hyper-V replication isn't playing nice with Veeam when it tries to build a VM list to backup/replicate. Then sometimes the Hyper-V configs are locked, causing Veeam to fail that VM (case 02015469). This can be solved by slowing down or temporarily pausing Hyper-V Replication at Job-start. Hence the pre/post example, but I cannot do what I need with that (no network-access because of VBR running in SYSTEM-account).
While I know for each exists work-arounds and/or possible solutions, it nevertheless becomes clear that, while Veeam provides a very robust backup-engine across multiple systems, it lacks admin-functionality which would bring it to a whole new level where an admin would only have one place (preferably one console) to take care of it all.
(Now need extra scripts, windows task scheduler to schedule them, seperate copy tasks using scripts, etc.)
It would be very much nicer if that kind of admin-functionality would be expanded upon from within Veeam,
No need to reply with work-arounds, as I am aware of those and am (forcebly necessary) using them already, hence my Feature Requests