Feature Request v9.5 - File Copy Job

[TheOnlyWizard17]

I'd like to see the ability to either exclude files/folders or the ability to include wildcards for File Copy Jobs, eg. D:\Hyper-V\Virtual Machines\*.xml so it will copy all the XML-files (As Veeam doesn't back them up netively, it parses tthem and eventually even alters them when doing Veeam Replication !) but this way it would exclude the otherwise included folders holding the live *.BIN and *.vsv files.

[Vitaliy S.]

Maybe Veeam Endpoint Backup should be a better choice in your scenario, since it allows doing what you're asking for (exclude/include files to back up) > Veeam Endpoint Backup FREE 1.5: Select Backup Mode?

[Shestakov]

Hello Bart,
Could you elaborate on your request, please?
If you want to backup VM files of particular extensions, you may leverage backup job with the corresponding option.
If you want to backup files of physical machine, you may use Veeam Endpoint Backup.
Thanks!

[TheOnlyWizard17]

Nono...
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 marc@enterautomatisering.nl-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

[Vitaliy S.]

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!

Just our of curiosity, why would you need VM replicas that cannot be started at the DR situation? Sorry If I missed that from your post (read it twice to find the answer).

[TheOnlyWizard17]

You probably not gonna like the answer to that, but the idea behind it is lowering TCO. We can get a new server very quickly, and this DR is only for the worst possible scenario we can encounter.
Instead of having a capable Hyper-V Host (and the year-round powercost of that) on Standby hosting the Replicas, we decided to have a low cost backup-server as Hyper-V hosting the VMs. If disaster strikes, we would only attempt a failover and/or run the VMs from the replicas if we really have no other options available anymore (worst case scenario). We will then order a capable Hyper-V host, and next day we will Hyper-V replicate the Veeam Replicas to this host to run them. I have no use for an Exchange VM needing 128Gbyte to attempt to run it having only 24 Gbytes or so. In short, it's just to cut cost of having an expensive host on standby all year round doing exactly nothing (Cutting the normal cost of DR-solutions).

[Mike Resseler]

Bart,

I actually understand your scenario rather well, having worked at a company where money for IT always was an issue. I wonder if you can use PowerShell to change the resources (mem / cpu / ...) of the replicated VM just before you actually do the failover. Maybe that is a way to support this?

[TheOnlyWizard17]

Not an option, because you would only do a failover if On-site is gone/destroyed/airplane landed on the DC, etc. From where would I then get the original parameters to script those settings back ? (Besides doing so is a real pain in the ass, ever tried anything like that ? I know, I've got it partially covered for the local Hyper-V replication). Then, next replication those settings will be overriden again, requiring another run with such a script. So this too would have to be scheduled from Offsite requiring On-site to be there. Making this robust is even more cumbersome requiring alot of checking and doublechecking, eg. how would I go about it if in the middle of changing one VM the VPN goes down ? Script would fail, unless serious error-handling is written for it also... In short, a whole lot of work, just to get some XMLs "synced". Come on... This should be peanuts for Veeam, in fact, syncing the whole Offsite-VBR should be peanuts and a default possibility !

This is what I meant from my second post! Veeam really is great and robust, but there's way too little flexibility!