Loading backup jobs from script?

[ARycroft]

Hi,

Please can you advise me? I have to migrate from a legacy backup product to Veeam. Is it possible to load the backup jobs and host details using an export from the existing platform with the relevant fields and import it into Veeam? There are over 900 jobs. I do not want to enter them all manually.

Kind regards
Andrew Rycroft

[Mildur]

Hi Andrew

Veeam doesn't provide an import tool for configuration of a foreign backup application. But you may write your own "onboarding" script with PowerShell or RestAPI. Export the configuration as XML or JSON from your old backup product. Then import the settings as a new backup job in Veeam.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

With Veeam, you can process hundreds of VMs with a single backup job. Maybe 900 backup jobs are not required anymore?
If this for a bigger environment, I would suggest to get in contact with your regional Veeam SE and ask for assistants from one of our architect. I'm sure we will be able to provide guidance for migrating from the legacy backup product to Veeam Backup & Replication.

Best,
Fabian

[TitaniumCoder477]

Is it possible to load the backup jobs and host details using an export from the existing platform with the relevant fields and import it into Veeam?

While I am not familiar yet with Veeam's REST API capabilities, I can testify to the power of the PowerShell cmdlets (pun intended!) having used it extensively. Virtually anything can be automated with PowerShell. The first question is not actually "if" but "should" it be automated. This is because anything that can be automated can also be manually done. The manual effort should be weighed against the time it would take to automate it. Based on the surface of what you've said about the use case, it does seem like automation would be the route to take.

"There are over 900 jobs. I do not want to enter them all manually."

I completely concur with Fabian's comments about the number of jobs. With Veeam, you do not want a 1:1 ratio of assets to jobs. If you have that many assets, you probably want to design your jobs around the asset functions or asset locations or a combination of both. For example, if all your assets are in one location, then perhaps you would segregate them logically into "File Servers", "Domain Controllers", "DB Servers" etc. Then your job layout would be based on this logical breakdown. If your assets are in different locations, then you might use something like "Azure-FileServers", "Charlotte-FileServers", "London-FileServers", etc for each of the functions. While not intending to overwhelm you with too much detail, if you do have very defined RTO and RPO, then you can also work that into the job layout / naming convention.

So in summary:
1. Define what you mean by "900 jobs"; do you really mean jobs, or do you mean assets?
2. If you truly meant jobs, then is your old software basically 1:1? (i.e. one job protects one asset) If so, you want to plan on 1:many with Veeam for optimal performance and management. (i.e. one job protects many assets; this doesn't mean you only have one job, just that any one job protects many assets.)
3. If you do have a lot of assets, hosts, environments, etc. then you really need to architect the solution. This speaks to Fabian's latter suggestion about getting in contact with a SE and architect. If you setup Veeam correctly, you will have an awesome experience and be able to achieve results in protection, management, and recovery few other competitors can touch. If you do not setup Veeam correctly, at best you'll achieve no more than your old product + a lot of migration and learning curve headache + complication that you're not using the product the way it's intended to be used.

I hope this helps!

[oleg.feoktistov]

Hi Andrew,

I am with Fabian and James here. As for the technical side of an automated import, I'd say you will need some kind of a mapper that would take job properties from an API output of your legacy backup solution, cross reference them with what VBR API (Powershell or REST) has to offer and then construct a precise specification for VBR API to consume. Now, I cannot say I have an experience with automating this kind of scenarios and it should, of course, be tailored to what's available both on source and target APIs, but if you calculate that the game is worth the candle with an automated solution, please reach out to our SE and architects. They can also raise a discussion with me (VBR APIs product manager), I think we can work something out.

P.S. We do have import endpoints for jobs and other resources in VBR REST API, which are designed primarily to migrate configs from one VBR server to another. For jobs it works only for VMware vSphere backups for now, but could also be looked into in your case together with all the entirety of Powershell.

All the best,
Oleg