09-03-2012 02:48 AM
Hi
i have seen below problem in BESR 2010. 9.0.3
recovery point sets numbering malfunction like below
this is seen today on two production servers WIN 2k3 server
abcd-D-Drive092_i115.iv2i
abcd-D-Drive093.v2i
anyone seen this before?
09-03-2012 02:51 AM
Not sure I see the problem here...
#92 is an incremental
#93 is the next full recovery point
Am I missing something here?
09-03-2012 02:59 AM
@ Chris Riley thnks for reply
see
abcd-D-Drive093.v2i is yesterdays full backup..
and abcd-D-Drive092_i115.iv2i is current incremental backup..
So according to rule the next incremental backup should be abcd-D-Drive093_i115.iv2i...
it should not be @92,.. but since yesterday incremental it is taking @92 number..
i hope this clears u now.
09-03-2012 04:29 AM
There was not enough information in your original post.
We'll need to see a screenshot from windows explorer that shows the filenames & date/time from the backup destination folder.
Can you also confirm the backup schedule being used for this machine.
09-03-2012 04:53 AM
yes the backup schedule is as per below
Incremental Every 1 hours from 7:00 AM to 11:00 PM Full At 6:00 AM every Sunday Medium compression recover point set limit is 4 |
In this U'll see the D drive full backup scheduled to run 6:00 AM on sunday
and next incrementals showin older number..
09-03-2012 06:20 AM
Very strange. I can only think that maybe there was a service crash or something that caused the most recent full backup to not update the history file. I'm guessing here. Without logs, it's difficult to know what could have caused this.
How often are you seeing this and on how many machines?
Is it something that is easily reproducible?
09-04-2012 04:46 AM
i am attaching two logs in there you can find the 1st september logs and 2nd september logs because as per schedule the backup job should run on 2nd september sunday 6am instead it started on 1st september also after that it started automatically on 2nd sept. day(scheduled full)
i have seen this on 2 machines.
09-04-2012 06:09 AM
Those logs are not enough to figure out what is going on here.
I would suggest updating to 9.0.5 (2010 SP5) to see if this helps.
Failing that, you need to open a case with support.