PowerShell script exchange
Post Reply
unmaximized
Novice
Posts: 3
Liked: never
Joined: Jan 12, 2024 8:56 am
Contact:

Detect end of weekly full backup

Post by unmaximized »

Hi everyone,

i need to write a Script that needs to activate something else (currently it just sends me a mail) once the weekly backup finished, but i can't get the timing right. The jobs are managed by our GFS media pool. As i am currently a beginner with using Veeam, my solutiion is the following:
  • script runs every time a job finishes
  • checks whether the job was for the weekly mediaset
  • if yes, adds the jobs name to a list
  • checks whether all backup jobs have been entered into the list
  • if yes, sends the mail
jobs for the weekly mediaset can run from friday to monday, sometimes multiple times

The Problem is: Since the jobs can sometimes run multiple times, the script could, for example, send my mail an on saturday because every job ran once and then a job runs a second time on sunday. So i didn't actually detect when the backup is finished but randomly cut it off in the middle.

I checked the properties for mediasets, mediapools, libraries and jobs but didn't find any way to see whether a job has run the last time for this cycle and googling sadly did not help either.
Is there a way to do this? Personally i think i am on the right path, but since i am a beginner, i might have totally missed a better solution. If you need any information, i'll try my best to add it asap.

Thanks a lot :?
david.domask
Veeam Software
Posts: 1226
Liked: 322 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: Detect end of weekly full backup

Post by david.domask »

Hi @unmaximized,

I'm not quite sure I get the exact business logic you're needing here but as I understand it, you're needing to know how to determine if a job will be retried or if it's on its final run? Am I correct?

If so, Get-VBRBackupSession and Get-VBRTaskSession objects should have a property WillBeRetried, which returns boolean. I think you can check on that and the result to decide if the job should be added to your list. If I misunderstand though, perhaps you can elaborate a little on the business logic you need? What job type are we working with and what's the schedule?
David Domask | Product Management: Principal Analyst
unmaximized
Novice
Posts: 3
Liked: never
Joined: Jan 12, 2024 8:56 am
Contact:

Re: Detect end of weekly full backup

Post by unmaximized »

Hi @david.domask,
sadly this does not work for me.
I am working with BackupToTapeJobs and the Schedule is managed by a GFS Mediapool. With the current settings, the Backup Jobs will start to write on the tapes specified by the weekly mediaset on friday.
The problem is that i do not know when they stop writing to this mediaset. Sometimes a job will use the mediaset on friday and then again on Saturday, but sometimes only once. What i want to do is eject the tapes as soon as the backup is over, which is why i want to know when all the neccessary jobs finished.

Also, i apologize for the late reply.
david.domask
Veeam Software
Posts: 1226
Liked: 322 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: Detect end of weekly full backup

Post by david.domask »

Ah, tape GFS is a tough one.

Tape GFS doesn't have "normal" retries, so you won't be able to track it that way, but you will be able to check it with Get-VBRBAckupSession (and Get-VBRSession) and Get-VBRTaskSession.

Why not just set Eject Media Upon Completion or Export the tapes?

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Is your Tape GFS media pool set to append data to existing tapes or it makes a new media set every backup session? (I assume append based on your question)

Do you want it to append or it should be a new tape each Tape GFS Session?
David Domask | Product Management: Principal Analyst
unmaximized
Novice
Posts: 3
Liked: never
Joined: Jan 12, 2024 8:56 am
Contact:

Re: Detect end of weekly full backup

Post by unmaximized »

Hi @David.domask

I think there was a misunderstanding. We don’t try to eject the tape from the drives, we try to eject the whole Magazine.

Let me try to explain it again.

My goal is:
Eject the Magazine from our Tape library after the last weekly and/or monthly Backup to tape Jobs are finished.
We use a GFS Media Pool for our monthly and weekly media sets.
After a backup is finished Veeam will eject the tape from the drives.

The Problem we have is:

Sometimes the Job runs multible times on different days

My Script at the moment checks which media set is written by the Backup to Tape Job (Daily/Weekly/Monthly) and adds it to a list.
Is the number of Jobs equal to the number of running jobs the script should be trigger the library to eject the magazine.
But if the job runs multiple times, I need a other parameter to figure out which tape is the last weekly or monthly backup tape.

Is there a parameter setting by Veeam to check is it a Dayl/Weekly or Monthly job.
If so, I can use it to make sure if the next run is a Daily media set and then current run should be the last backup set for Weekly or monthly and then I can count it.


About your questions:

Q: Why not just set Eject Media Upon Completion or Export the tapes?
A: We use this setting at the moment.
Q: Is your Tape GFS media pool set to append data to existing tapes or it makes a new media set every backup session? (I assume append based on your question)
A: It makes a new media set every backup session.

Q: Do you want it to append or it should be a new tape each Tape GFS Session?
A: New tape each Tape GFS Session

Thanks a lot,
unmaximized
david.domask
Veeam Software
Posts: 1226
Liked: 322 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: Detect end of weekly full backup

Post by david.domask »

Hi @unmaximized,

Thanks for the clarification, the idea is more clear now.

Can you tell from the HTML report (right-click the job, select "Report"), for the times when the GFS job does multiple runs, did the scheduled run have a failure of some sort?

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

> If the GFS job failed for some reason, it will try to restart every hour for 24 hours.

I think that might be the item which is confounding your script logic -- I have some ideas on how to detect and workaround this as it's not a "normal" retry, but can you confirm that the sequence of events is as described?
David Domask | Product Management: Principal Analyst
Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests