Writing fulls twice in a row??

[Dave1337]

Hello everyone,

I have an issue where one of my tape jobs where it seems to write the weekly full backup on both Saturday and Monday instead of writing the full backup on Saturday and moving on the incremental for the Monday backup.

Friday-Saturday = Full backups
Monday-Thursday = Incremental backups

Three weeks worth of tapes with 1 week retention
30 restore points kept on disk

We have 2x standalone HP LTO5 SAS attached tape drives with seperate media pools. Each media pool contains all three weeks worth of tapes (fulls and incrementals use same media pool). I'm thinking the issue may be related to the retention policy set in the media pool, so I just changed the policy to "Do not protect data (cyclically overwrite tapes as required)".

I have another tape job for a seperate set of VMs that seems to run just fine and the settings are exactly the same..... Last night when that tape job started it started the job with:

Processing full backup of tape to disk job 1: nothing to backup and continued with the incremental as designed.

The other job however said:
Processing full backups started at 01/20/2015 01:41:00 and just filled up the tape in the drive....

I had this same issue last week and was told by support it may be because the backup to disk job had just been modified (added a VM to the job).


I am not sure why this is occuring but am hoping someone can give me some guidance.

[Dave1337]

Case # 00731274

[skruje]

Registered to post this. We are having the same issue since the Christmas holidays.

Our setup:
Friday: Full
Saturday morning: Write full to tape
Saturday-Thursday: Incrementals

28 restore points kept on disk (4 fulls on disk at any time)
Four weeks of tapes in single media pool with retention disabled.
1x Dell PV-124t LTO5 SAS-attached tape library

In the last two weeks' full-to-tape jobs (Jan 17 and Jan 10), the Full from Dec 26th has been scooped into the job, causing us to have more data to write than the tapes in the library can hold. When I rerun the job, it works normally, i.e. writes the last full only.

OP please keep the thread up to date on the case. Our Dec 26th full will fall off of our disk retention this week so I suspect the problem will just go away but I wanted to report this in case other customers are having problems.

[veremin]

@Skruje

I think that the following situation has happened with you. A medium containing .vbk from December 26th got overwritten, even though that .vbk was still present on disk. As the result, during its next cycle a backup to tape job tried to cope that .vbk again, because tape catalogue didn't have a reference to it.

You can either increase retention on media pool level or update to version 8 (if you haven't done it yet) and re-create a backup to tape job, making it copy only portion of a chain starting from the latest full backup.

Thanks.

[Dave1337]

Just an update on this,

I think it had to do with a couple problems, but may be fixed now (hopefully).

Tape retention needs to be higher than disk. One feature request I would like for this is to maybe have a "match" function or otherwise to say keep the exact same amount of data on tape as is on disk, or change the wording so the tape retention can also be set to restore points like the disk retention is.

The other part of my problem is when we originally implemented, I tested doing fulls a few different ways, and those fulls never properly got written to tape (I guess), so for some reason the tape job would try to get those orphaned fulls every week after the first incremental.

I'm going to give it a couple more days but I am in much better shape.

Thanks,
-Dave

[veremin]

Tape retention needs to be higher than disk.

Yep, it's the best practice, indeed.

The other part of my problem is when we originally implemented, I tested doing fulls a few different ways, and those fulls never properly got written to tape (I guess), so for some reason the tape job would try to get those orphaned fulls every week after the first incremental.

I think the second problem is the result of the first one. Due to shorter retention, backup to tape job tried to copy those backups that had been deleted from tapes, but were still present on disk.

Thanks.