I am having some difficulties with tape spanning, and I've traced it down to the overwrite protection period.
What I'm trying to do is have the overwrite protection period long enough that it won't overwrite the first tape in a tape span. The issue I've come across is that I think it's too long and the overwrite/append protection is still in place when an append job starts a couple of days later.
What I am wondering is
a) Does the overwrite/append protection period start when the job STARTS or when the job ENDS. This will help dramatically trying to plan this out. I found a couple articles through the search but it describes everything but that.
b) The only other thing I can think of is have a tape job that erases all tapes present in the drives run before the main jobs start, this will definitely fix the problem but this seems like a sledgehammer approach to me.
OPP starts at the end of the job which last writes to the tape. AP starts at the beginning of the job which first overwrites the tape.
There is a section in the Admin Guide which explains how OPP and AP works. I would suggest that you read that section carefully.
There is no need to erase tapes to make them overwritable. You just need to move them to the Scratch media set to do so.
Hmm I have not specifically checked what happens but as I believe the Overwrite protection start is based on last write to a tape and not specifically the end of the job, then for spanned sets there will be a difference between when first tape becomes overwritable and when the second tape does i.e. I believe OPP works like this with spanned tapes:
Media Set OPP is set to 7 days
Day 1: Backup Job starts and overwrites first tape, which it fills after 8 hours and then uses a second tape for 2 Hours (which it does not fill) Overwritable status of tapes at this point is:
Tape1 - Overwrite protected until Day1 job start time + 8 Hours + 7 days
Tape2 - Overwrite protected until Day1 job start time + 8 Hours + 2 Hours + 7 days
Day 2: Another Backup job starts against same media set as Day1, at same start time as Day1, is configured to append and uses the remaining space on the second tape (taking 6 hours), before going to a 3rd tape which it also fills (taking 8 hours), before writing to 4th tape for 1 hour. Overwritable status of tapes at this point is:
Tape1 - same as at end of Day1 job processing - so in effect 1 day closer to being overwritable against the current time
Tape2 - Overwrite protected until Day2 job Start time + 6 hours + 7 days
- in effect this is now close to a day further away when measured against Tape1
Tape3 - Overwrite protected until Day2 Job Start time + 6 hours + 8 hours + 7 days
Tape4 - Overwrite protected until Day2 Job Start time + 6 hours + 8 hours + 1 hour + 7 days
As you can see there are always differences between when tapes can be overwritten in a spanned set - and these differences can be added to by using append jobs which can move the overwrite protection of the last tape that is not completely full further away from the earlier tapes.
There is however no way to configure it such that the overwrite protection for Tape1 also moves backwards against Tape2, if its overwrite period changes. Your overwrite protection should be based on how long you must keep that backup set for and as soon as the earlier tapes in a backup set have been overwritten, you need to be aware that any remains of the backup set on a tape that has not been overwritten is a partial set with limited restore capabilitities (for file system backups) or NO restore capabilities (for GRT backups)
Usually this is not an issue for tape based backups - as backup sets are typically kept both offline (so no overwrite possible) and for long enough on tape so more than one newer backup set of the same data already exists.
We did realize that this concept is a huge problem for disk based backup sets which is one of the reasons why we separated disk based sets from Media Set handling and introduced DLM (in Backup Exec 2012 and later)
Both tapes spanned by a backup set will be protected until the end of the job plus the OPP.
If the first example is true, then there is a possibility that Tape1 can be overwritten at start time + 8 Hours + 1 Hours + 7 days, this rendering Tape2 useless, even though it is protected until .start time + 8 Hours + 2 Hours + 7 days
It does not render tape 2 useless, just the part of tape 2 that is the same backup set as the earlier overwritten tape. I am going to see if I can somehow validate this belief - however not sure I have the equipment to do it. I did check with a colleague before writing my presvious answer and he had the same belief.
Either way if they append to the second tape after the spanning job has finished - it definitely separates the OPP for tape 1 and tape 2 and in this situation you can then overwrite Tape1 and break the remains of the same backup set on Tape2 (so the problem can still take place)
I am setting up a test of tape spanning - just as whilst I am confident of how I described what would happen once you run an append job a day after the spanned job (the overwrite period end of the two tapes will definitely NOT be the same) - the status immediately after the spanned job itself finishes may not be as I described.
Unfortunately I may only know the result next week (due to the size of my test server, the size of the tapes available to me and the overall speed of the test setup).
Oddly enough I don't think the support team in my region has ever been asked to confirm this exact behaviour, hence the reason the answer is unclear.
So I confirmed it was due to the OPP - when one tape filled up the next tape wasn't necessarily appendable (e.g. it was full), depending on how the tape drives were used in the last run.
Now that I know it starts after the write finishes, I set a more appropriate 3 day OPP, as the two append jobs will run in 24 hours after the initial backup runs. This way, the OPP should be cleared from the two append jobs by the Friday when the main job runs again.
Only time will tell now.
I have confirmed the behaviour is as I described - the last write operation to a tape (so when the tape fills in the case of spanned jobs) does trigger the start of the overwrite protection. This screenshot I have attached is where Tape 000005L5 was the first tape used and Tape 000004L5 was the one spanned onto by the same backup job - the 1st tape filled up approximately 8 minutes before the end of the job and there is an 8 minute difference in when the Overwrite protection period for each tape ends.
Also some more info based on the later post by DanFR
Be aware that appending ONLY applies to the first tape used by a job - you MUST overwrite the second tape after the first tape fills up. That is why the append setting choice in the job config actually is within a box called: "When this job begins" (PKH has also already mentioned this)
Also a 3 day OPP sounds a bit short - if this means you allow your only full backup of some data to be overwritten before the next full backup has completed this is bad practice, you should always have enough media capability to store at least two full backups as if you overwrite your only full and then experience a disaster whilst the next full is being created you won't have a valid backup at all.
Well, it still isn't working.
I put a tape in each drive. I've labeled the drives "Red" and "Rlue" physically on the drives and have them labeled in BE the same so I can tell them apart.
So the job runs, starts writing to the Blue tape. This fills up in a couple of hours... then I get a message buried in the event notifications "There is no media in the drive" for the Red tape drive. I look, and BE has ejected both tapes.
For the Blue drive, it notes that it's overwrite protected until "date". There's no such notification for the Red drive. If I take the tape that the Red drive ejected, and put it in the Blue drive, click OK... and it runs.
Surely BE can tell if a tape is in the drive or not?
I've checked, I can take a tape, put it in the Red drive, and run inventory and the job completes successfully, showing me the overwrite and append protection periods. These tapes are changed weekly so the OPP would have expired weeks ago as all tapes and jobs use the same Tape Pool and Media Set.
Does anyone else have any suggestion to solve this very annoying problem?
Ok so spanning could mean one of two things
1) The ability to write to a second tape cartridge (in the same drive) when the first tape fills
2) The ability to write via a second tape drive (to a second tape cartridge) when the first tape fills
Option 1 above is what I thought you were doing (possibly using a library), Option 2 for Backup Exec was historically called a Cascaded Drive Pool (so a casade that results in a span between media) and we stopped supporting Cascaded Drive Pools after Backup Exec 12.5 (so over 8 years ago)
Tape Pools in current BE versions just allow Backup Exec to start the job from one of the available drives in the pool (either in order or round robin) however for the job to continue when the first tape is full it will use the same drive and not another drive in the pool. Within a multi-drive library it would also continue to use the same drive.
So to solve this choose from:
- split your data into two jobs so that no job would completely fill a tape
- be prepared to change the tape in the chosen drive when the first tape fills
- invest in tape devices that can support larger capacity tapes (and buy the tapes too)
- change to using a library (which is the MOST flexible option in terms of job setup)
We are trying #2, or spanning across multiple drives in a pool. This would explain why it isn't working.
The site runs unattended backups to tape so manually swapping is not an option. I looked into a tape library and they start at $35000 here which is the whole year IT budget, so that's not an option either (nonprofit).
I don't want to try to manage 10 jobs when it could be done in two, the possibility of it having weird issues will climb significantly if I tried to manage that.
Symantec donated us Backup Exec through one of their charity programs... I will probably have to look at other backup software solutions as that surely won't cost 35k.
Thanks for clarifying why it doesn't work, though!