Script for Veeamzip job

[ithark]

Dear Team,

We are following the below process to do the archival of the VMs to the tapes.

1) Create a backup using Veeamzip
2) File to tape job to backup the vbk of the Veeam Zip.

Now, the problem is, for the auditing purpose, we need some kind of logging for these Veeamzip jobs. Hence if you can help me with a powershell script to do a veeamzip job and then to send a HTML formatted email notification about the completion of the job (with the following parameters), it would be really helpful.

Backup Start time
Backup End time
VM name
Retention
Repo used.

Thanks in advance!

[HannesK]

Hello,
a little bit of topic... but why don't you just use normal backup functionality?

Best regards,
Hannes

[ithark]

Hi,
We could use the normal backups but the backup sets won't be deleted automatically after a period of time.
Our aim is to store the archives to the tapes and this Veeamzip is only a intermittent step to achieve this.
Hope this clarifies your question.

[HannesK]

hmm not really... for sure, the retention of a backup job deletes the data after a configured amount of time.

I'm pretty sure, that there is an easier solution, but let's see whether someone can help you with a powershell script.

[soncscy]

I'm actually not convinced you need a script for this particular goal.

1. Do a normal backup job and use that email report which gets exactly what you want.
2. Do a Tape backup job
3. Script deleting the one-off backup.

It's not hard to make what you're asking (just pull this from the VeeamZIP obsession result), but the script to delete the job is so much easier.

1. Check if the Tape job was successful
2. Get the Backups that were successful and pass them to Remove-VBRBackup

I think this is far less work and uses already existing code.

[ithark]

HI,
Thanks for your reply.
A normal job requires a lot of cleanup as it would leave the following,
a) a scheduled job on the job list
b) vbk file on the disk
c) logs on the Veeam's program data folder.
We would like to avoid all these cleanup.
Also, we would like to use Veeamzip for other purposes as well and it would be really helpful to have a email alert for the Veeamzip job.
Thanks in advance!

[soncscy]

Hi Karthik,

I understand your concern, but the code to clean this is:

Get-VBRJob | ?{$_.Description -contains 'some keyword'} | Remove-VBRJob

Once the backups are under imported, just:
Get-VBRBackup | Where-Object {$_.JobId -eq '00000000-0000-0000-0000-000000000000'} | Remove-VBRBackup -Confirm:$false -FromDisk

Your point c) I don't quite get as VeeamZIP would leave the same, but you can even just get this with by just parsing the Job name(s) from the Job array and removing the folder.

I'm afraid I don't understand your final point -- you asked for a script to delete the Veeamzips after a time, which this could do?

I really think you're overthinking this arrangement.

[oleg.feoktistov]

@soncscy has a point. Let's imagine you have a script for VeeamZIP Job creation & Backups deletion, which you trigger manually every time.
With a single VM as a job object it's not a big deal, but if you got more... I don't know, I think you'll probably end up using task scheduler. But since you then need to take created vbk to tape, you must be already using it. Next, min retention policy for VeeamZIP is 1 week. So, why deleting backups manually after they have been moved to tapes if you can just configure a super short-term retention policy with a normal job?

VeeamZIP

• Manual trigger is needed

• Task scheduler to run before other jobs

• Minimum retention of 1 week

• No option to run File To Tape "After this job"

VS

Backup Job

• Runs on schedule

• Short-term retention available

• Backup To Tape can run "After this job"

Thanks,
Oleg

[ithark]

@soncscy Thanks for the scripts. Let me try and see if this can be done

@oleg.feoktistov Thanks for your reply.
About the retention policy, the normal backup job doesn't delete the backup set after the retention is over. The old backup set would be overwritten after the expiration period only when the next backup for the same data-set takes place. Having said that, I will try what @soncscy has mentioned and would update the thread