Feature(s) Request: Full Backup & Job Group

[jks_45]

Here are some pretty important features I would like to see...

1. Ability to schedule a backup and get a full backup each time! I know...I know.. data de-dup...etc, why not make a simple option to enable/disable or even just tweak the increment settings so it can be set to 0 instead of minimum of 1 on each job?

To currently do this, we have to create a new job for every VM each time we want a full backup. Not very efficient.

2/3. A "schedule job group". Instead of creating an individual job for each VM (because we want to take it to that level), we would like to create a "job group" and then add/select VMs to the group. That way each VM would have the same backup configs, settings, destination...etc, BUT also with the ability to say "group them in one big file" (which would probably be the default), or to select or unselect a check that allows us to not create one big file... so "create a new folder for each VM" or "maintain separate folders for each VM"...etc

We have nothing against data de-dup...in fact we want to use it, but just not at the top level..we want at least a full backup of each VM and then increments after, all within their own folders. For example 1 Folder = (Full Backup of VM + say 2 weeks of increments of that VM)

Currently, to do this, we have to create a Job for each VM.

I was a little caught off guard when I saw it didn't have these features....

[Gostev]

Hello,

1. Actually, with synthetic backup Veeam Backup leverages, you do get full backup after each backup cycle, whether it is full or incremental cycle. Did you know this?

2/3. This feature request does make sense if you want to have an individual backups for each VM, but could you clarify what is your use case for this requirement?

Thank you!

[jks_45]

1. To clarify. I mean a full back file each time. No increments. Each backup would be a new *.vbk file. The use for this would be, that we want to schedule a Job to run a weekly full backup every time to the same destination, say drive letter F. The media at drive F: will change, so there will be no full backup or increment available to build on. Thus the reason for the new full backup *.vbk file each time. That media will then be sent off-site. From what I understand the next/second backup will always be an increment or actually synthetic backup, but it requires the original *.vbk file to be there to build the new full backup. Then the previous full backup gets pushed back as the increment. Right?

2/3. The groups would make it easier to organize and maintain backups/backup schedules that don't really change...easy to add/remove VMs, or all production VMs to one location, and all development, or terminal servers to another backup location...etc. The case: Well, instead of a page full of say 50 to 100 Identical Jobs, except for the VM name, there would be say 3 or 4 groups. But you would still get the benefit of either allowing them to all data de-dup together in one *.vbk file or maintain separate folders for each VM along with their increments. Currently with 22 Jobs, with Veeam Backup at full screen, the job list takes up most of the screen. And from what I understand, the only way to get a full backup of each VM is to create a New Job for each VM. So 1 per VM.

Having at least a full backup and possible increments for each VM is a high priority for us. A main point is we don't like single points of failure. A second main point is size and portability. The ability to restore a VM at any point from desktop, to multiple servers in multiple locations, to off-site, the ability to put it on portable media as well as for disaster recovery, which is a third point. Redundancy. Several VMs, especially development VMs are constantly changing, while others hardly change at all. We don't want our dev box backups or constantly changing backups near or making changes to the same files that the non-changing VM backups use if they don't need to be. Also, it doesn't make sense to carry around the kitchen sink when all I want is to be focused on is say a dev box if it gets hosed. So say a portable drive with just dev box VM+increments. These are just a few examples. The dev box is not the only case. We would like this flexibility with all of our VMs.

Thanks.

[Gostev]

1. I understand this, we also take our backups off site in a similar fashion. To achieve this with ever-replacing media, you should backup locally to your Veeam Backup server, and simply use post-job script functionality from backup job wizard to copy the produced VBK file (its name never changes) to your F: drive. This way you can still benefit of having fast incremental backup (resulting in smaller backup windows and much less load on production systems), and having full backup available for you after each backup run to address your requirement.

2. Thanks, yes I was mostly asking why you wanted one backup file per VM (last paragraph). It was clear why you would need groups if you want to have 1 VM per job only.

I must admit that the requirement of having 1 VM per job is quite unique to date. So I would like to understand your environment a little bit better if possible. How large is your environment in terms of number of ESX hosts and VMs? Please correct me if I am wrong, but what you describe in last paragraph as example (portable drive with dev VM backup) sounds like backup micro-management that would be hardly possible if your had thousand of VMs? Also, having separate backup per each VM means that you loose deduplication and will need significant backup storage space if you have many VMs.

As for your concern about some VMs (dev) constantly changing while other not, would it make sense then to group those dev VMs together as one job, and other rarely changing VMs as another job?

BTW please PM me if you'd like to take this conversation offline.

[dkvello]

2/3 This might be something other that what You request, but we use the Folders/Groups function in vCenter to do this.
We make backup-jobs that backs up whatever is currently in the Folders.
Adding and removing a VM from a folder in vCenter equals adding or removing from a Group-backupjob.

VM's in the /Dev folder-tree has its own backupjob(s)
-----""----- /QA folder-tree has its own backupjob(s) (split in Windows x32/x64/Linux x32/x64)
-----""----- /Prod folder-tree has its own backupjob(s) (split in Windows x32/x64/Linux x32/x64)
etc.

Once the jobs has been created, we manage what to back-up from vCenter by moving VMs in or out of the Folders. This is done both manually and by Powershell-scripting.