Backing up different disks of same VM in different jobs

[HDClown]

I have a Windows Server 2022 VM in VMware that is a file server with disks C/D/E that are SCSI 0:0, 0:1, 0:2. Disk C is the OS and Disk D/E are just be "data volumes" that have file shares on them. No applications, databases, etc. would ever be on D/E, just "flat files" shared over network.

I want to have different backup retention and repo targets for the data volumes of D/E. It would be fine if Disk C uses the same retention/repo as Disk D.

What is the best way to setup jobs? Do I go with two jobs where first one includes disk C/D and second job includes disk E? How would that impact doing a full image-level restore across these jobs to get the VM back with all 3 disks? There is the "remove exclude disks from VM configuration" option that I assume would be a factor in here.

Or am I better off creating 3 jobs where first job is only C and I do a image-level restore with that job, and use only file-level restore for the jobs that cover D/E? This would require me to manually create the disks in the VM for D/E after I did the image-level restore that includes only C but I don't have to worry about mixing volumes back into a VM from different jobs (if that is a concern). Outside of that manual work, I would think the file-level restore of these entire disks would be a lot slower than an image-level restore as there will be a few TB of data on each disk D/E.

In addition to the above, is there anything I need to consider in regards to AAIP? I assume I should use AAIP since it's a Windows VM and that seems to be the best practice in general if everything in the VM is supported by AAIP (which is true here). Do I need to add anything to exclusions under the AAIP settings if the disk is excluded at the job level?

[HannesK]

Hello,
I would avoid such things and keep it simple. Imagine doing things like that with hundreds or thousands of VMs sounds painful for me

Two jobs are less complicated than three jobs. But as said above: I would go with one job. It sounds like, you already found the disk exclusion in the job. So I'm not sure, what the question is. For restore, you would do disk restore to the VM instead of full VM restore.

I would never do file level restore if I have the option to do block-level restore for "full restore"

You can use AAIP (optional). Nothing special to consider here, because you have no databases (two jobs trying to do log shipping would be bad, but you don't have that)

Best regards,
Hannes

[HDClown]

I found [ulr=veeam-backup-replication-f2/can-not-flr ... ml#p111313]this old post about FLR not working in a job if system disk is excluded[/url]. Is this still the case for V11/V12? That would alter my idea for 2 jobs. I can include the system disk in both jobs though if that easily mitigates this issue.

I also found posts that doing something like this means both jobs can't run at once, which make sense, so I would need to chain jobs together to avoid that issue. Other thing that I need to consider is impact on replication. I would want to replicate this VM but only with Disks C/D. Replication jobs let you exclude disks so this seems like I can do this without much of an issue.

Are there other options to skin this cat beyond "just back everything up in a single job" ?

[mkaec]

I have a large file server split up like this in order to have different retention periods for different volumes, and also to redirect different volumes to different repositories (some backups go to an appliance that does replication). Each job backs up one single disk from the VM. AAIP is enabled only because the jobs need to run a pre-freeze script. The processing mode is set to "Disable application processing". Before the pre-freeze script was added, AAIP was off.

You're right that DR restore would probably be messy and slow. I've never had to do that. The most I've needed to do is single file or folder restores. There is redundancy with all of the (important) content available on other servers backed by separate physical hardware. So, fast RTO of this system is a requirement.

With this configuration, I suspect that Veeam's instant restore feature would not function. And I've had problems with Enterprise Manager. File search will only search the most recent backup from the VM. If I'm searching for a file that is on D: and E: was the most recent job that ran for the VM, Enterprise Manager will not find the file. It's not smart enough to know that it should look at the most recent job that contained D:.

[mkaec]

I also found posts that doing something like this means both jobs can't run at once, which make sense

I wonder if that was my post. I did have problems with this and chained the jobs together (along with running pre-job delay script) to resolve it. The original problem was that the related jobs would all wait, but after one job completed another would start before Hyper-V cleaned up the snapshot. That resulted in the next job trying to back up an avhdx file that would shortly be gone. However, the switch to Hyper-V 2016+ changed how snapshots/checkpoints are handled and I moved the jobs back to non-chained. Checking the logs, it's still not perfect. There was one avhdx event this month and one in December. It's much improved over happening every night. I think I'll put back the pre-job delay script to resolve the remaining infrequent occurrences.