Hi Burak,
Thanks for the detailed description, and sorry to hear about the challenges.
A new media set always begins with an empty (free) tape
I'm guessing you're correct that once the job was started and the necessary tape for Yearly wasn't inserted, a new media set was created, the previous media set was closed, and now the previous Yearly tape is protected until 2029 as per your screenshots.
Tape GFS works pretty well, and it's designed to be very "set and forget". With a smaller pool of tapes to use, there are a few finer points on the GFS logic to iron out, but it still can work pretty fine, and the options you've settled on seem reasonable for your workflow.
1. The necessary tape was offline
2. Expired tape Woche 1 was found and marked as viable for selection (I suspect TapeGfsExpiredMediumSharing registry value may be set for this environment)
3. The expired tape was selected for starting the new media set
I think that in the future likely you will not hit this again as the conditions above lead to the situation you're in. With Append enabled and ensuring the tape is online and available for the tape drive during the yearly, this will not repeat.
Thanks for the detailed description, and sorry to hear about the challenges.
Correct, with Media Sets, there is one major rule to remember:Can someone confirm that this is the issue and it is all by design? Therefore, if we use the wrong tape at the time of the backup we are not able to append anymore to the previously tapes?
A new media set always begins with an empty (free) tape
I'm guessing you're correct that once the job was started and the necessary tape for Yearly wasn't inserted, a new media set was created, the previous media set was closed, and now the previous Yearly tape is protected until 2029 as per your screenshots.
It's a balance, as in larger environments, this method would mean a lot of pausing in the tape-out process if a needed tape wasn't available. There is a wait period where the job will notify of a need for a tape and send an email notification (If configured), but in this case, it looks like an expired tape was present and used for the new media set.Would it not be much better that the job waits until a media from the correct media set is inserted and then take a look if the tape is free or from a previously media set and just append it?
Tape GFS works pretty well, and it's designed to be very "set and forget". With a smaller pool of tapes to use, there are a few finer points on the GFS logic to iron out, but it still can work pretty fine, and the options you've settled on seem reasonable for your workflow.
In this case, the issue was three-fold:If I create another GFS pool and job with yearly only, would the same issue happens again if a tape from GFS-weekly media set was inserted at start time of the yearly backup?
1. The necessary tape was offline
2. Expired tape Woche 1 was found and marked as viable for selection (I suspect TapeGfsExpiredMediumSharing registry value may be set for this environment)
3. The expired tape was selected for starting the new media set
I think that in the future likely you will not hit this again as the conditions above lead to the situation you're in. With Append enabled and ensuring the tape is online and available for the tape drive during the yearly, this will not repeat.
Statistics: Posted by david.domask — Jan 06, 2025 9:02 am







