reason why SAT backups not taking place

[oskhan]

hello all

I had made some changes to the backup schedules before leaving for a month long vacation. I had scheduled, cumulative incremental backups to occur daily (ret. period : 2 weeks) , and a full backup to occur every saturday (ret. period: 6 weeks), a monthly backup(on the first of every month) (ret. period - 6 months)and the 1/2-yearly backups(ret. perid 18 months)

When I cam back, I saw that all the downloads had been proceeding smoothly, except for those that had been scheduled to run on saturday, I checked and rechecked all the valuses in the schedule (GUI console), but I could not find any descrepancy. Could someone tell me what the reason why this might have happened?

Is it possible for the admin GUI to show some settings that are actually not being implemented??

thanks

os

 

[comtec17]

Can you post a screenshot of the screen you are looking at as well as provide us with the actual schedule configurations?

 

[oskhan]

Hi comtec17

I cannt post a screenshot, however I can provide all the details.

In my policies (one for NT , other for Solaris workstations), I have 4 schedules:
- (cumm diff. backups from Sun-Fri) (from 7pm - 4am)
- (Full backup every Saturday) (from 7pm- 1;00pm)
- (Full Bacckup on monthly basis on the 1st)
- (Half Yearly backups every 6 months, on May 11 and Nov 11 )

The backups usually don;t take that long. They are done in 2-3 hours. However I have noticed that all the schedules work properly except those that run on SATURDAYS. I have taken steps to ensure that I can recover the data if something bad happens and I am going to create a new policy but I just wanted to know why it was happening.

The properties for the saturday backups are
Type: Full Backup
Freq: 1 weeks
Override policy vol pool: Full_Sat_Bkup
Ret. : 6 weeks
Media Multiplexing: 1
Start Window: Sat 19;00 - Sun 13:00

Volumes in Full_Sat_Bkup vol. pool are
A00004
A00005

The problems report as well as All logs Report do not show anything. In fact the logs show that there was no attempt to start a backup on Saturdays.

 

[comtec17]

You will need to change your frequency of the backup from 1 week to 3 days. The reason being is that NBU uses the time from the end of the backup to count the frequency of the next backup.

This means that if this Saturday the backup started at 19:00 and ended at 23:00, then the next backup would start at 23:00. Now lets say that backup finished at 3:00AM Sunday, now netbackup will use the frequency to start the next backup on Sunday around 3:00AM.

By using a frequency of 3 days, the bpsched daemon would fire off a schedule request on Tuesday, and recognize that the Window is closed for this policy but will flag it to run when the next window opens.

 

[Calz]

I've had this exact same problem which has probably been happenening for quite some time without our knowledge as they don't attempt to run so they never fail. See thread

http://www.tek-tips.com/viewthread.cfm?qid=1189135&page=1

You can use a predcict command to calculate what will run on a set M/D/Y time, I did a comparison before/after the change and there was loads of extra jobs that would run.

 

[Stumpr]

Comtech,
I have not been able to find any documentation as to whether the frequency is determined from when the backup started or from when the backup completed. If you can find this written somewhere then please share it with me as this question has come up several times.

I thought it was from the start of the backup because the image includes in its filename the UNIX ctime. But I have never been able to prove it one way or the other.

Bob Stump
Just because the VERITAS documentation states a certain thing does not make it a fact and that is truth.

 

[oskhan]

Hi all

Comtech,

I can consider your scenrio, however I have a slight problem with it. Let me assume that the freq is determined from the moment the backup is completed. and for the sake of argument let me assume that the backup completed on sun 14;00(ie 2pm)

so the next time the backup will try to start on sun 2pm. However since the start window was from Sat 19;00 - Sun 13:00, the backup will not happen and it will be flagged for whenever the next window opens(ie. next week Sat 19;00 - Sun 13:00)

So in such a case, it should only be possible to skip the weekly backups once !! and then rest of the weeks, the backups should proceed until this cycle happens again

Correct me if I am wrong

oskhan

 

[comtec17]

I think I complicated the matter somewhat.

Let me try an clarify myself.

Lets say, your weekly full backup is configured as frequency based and set to 1 week.

Now lets assume the Backup Window is from 8:00PM on Friday to 6:00AM Sunday.

Now your Friday backup kicked off @ 8:00PM Friday and Ended at 4:30AM on Saturday.

Now due to your backup ending at 4:30AM on Saturday and the frequency set to 1 Week and will be marked as "Backup Complete @ 4:30AM on Sat (I simplified it some as there is a much more detailed process to this)

As Stumpr noted there is time stamp that gets noted, and it is as of the end of a "completed" backup. (This is because an failed backup gets deleted and not commited to the catalog). This will be different if you have 10 streams running as each stream is a backup job and the image gets that time, not the entire policy.

Now with that stated, the bsched process runs at 4:33AM on Saturday and fires off the backup from last friday because you are starting the backup 1 Week from its completion. Now lets say that this backup completes at 7:00AM Sunday.

You can see that 1 Week from 7:00AM Sunday is outside of its window of 6:00AM so it will be skipped the next week. Now bpsched marks this as "I know there is another Window next Friday @ 8:00PM and will run at that point but leaving you with a skipped backup for this week.

Now this gets even more messed up if you only have a Window from 8:00PM Friday - 4:00AM Saturday.

The manifestation is unbelievable if you are not careful.

OK, now lets take the same scenario and give the schedule a frequency of 3 days.

Your original Friday kicked off and completed @ 4:30 AM. The bpsched process runs in 3 days (Tuesday) and notices that there is a schedule that is marked to run due to the frequency, but does not have a run Window, so it will be marked to run again its actual scheduled day & time.

As you can see, using the 3 day frequency will not allow a backup to get skipped.

The same scenario should be put in place for daily backups, using a frequency of 16 or 20 hours should cover you so the backup never skips its run time.

This is actually written in the NBU 3.4 and 4.5 training manuals and I do believe there is a mention of this in the Admin Guides. I will check to verify. I also believe there is some PDF's located on support.veritas.com with a search of "Frequency".

Hope I didn't confuse anyone...

 

[GreyWanderer]

I think comtech is on the right track, except it is at the individual schedule level.

Here's what we use to keep things sorted, in just about every possible schedule you can think of runs in this enviro.

Daily = 18hr freq
weekly = 5 day frq
Monthly = 26 day freq


...you can see where this is going, and the same server can be in many polices, and have many different schedules run against it. The daily schedule frequency only affects the daily schedule. The daily sched frequency has no impact on the weekly schedule or its frequency.

 

[comtec17]

Correct as each schedule has its own retention, frequency, and run times...

 

[Calz]

I have our backups set at:-



For reference you can run a command before and after you make changes to the policies to see what effect it's had, for me this last fri-sun we had 120+ extra backups run.

Predicting what backups will run...

/usr/openv/netbackup/bin/admincmd/bpschedreq -predict <M/D/Y> <12:00:00>

Where <M/D/Y> is the specified date to query.
Where <12:00:00> is the specified time to query.