I have 10 protection groups that ran Saturday night.  I have put information about them in the following table:

I extracted the data in the table using Get-DPMProtectionGroup CmdLet and the job information from the Monitoring page of the DPM admin console.  As you can see from the tape barcode, DPM wrote the first four PGs to one tape, then started a second tape, and finally failed when starting a third because it had run out of free tapes.

All of the protection groups are assigned to the same "Co-Located Protection Group Set" in the "Tape Optimization Setup" dialog box.

Prior to the jobs running, I painstakingly ensured that each of the Protection Group's "Select Long-Term Goals" and "Select Library and Tape Details" screens are identical as follows:

Prior to running the jobs I had already disabled autoclean on the tape library.

I have checked to see if the tape drive is reporting IO error 0x8007045D using the method described in this blog post: http://blogs.technet.com/b/dpm/archive/2012/05/14/things-you-can-do-to-help-data-protection-manager-utilize-your-tapes-full-capacity.aspx

There seems to be no mention of 0x8007045D or -2147023779 in any of the MSDPM*.Errlog files.

These are LTO6 tapes with a capacity of 2.5 TB each.  The total data for all the jobs put together is less than 300GB.

Why is DPM 2012 R2 splitting these protection groups across three different tapes? 

What else should I check for that might cause DPM to start a new tape?

• Edited by alx9r Monday, August 18, 2014 8:53 PM

Hi Mike,

I must have made a mistake earlier.  I retraced my steps and searched again for "0x8007044C" and "0x8007045D" in each of DPMRA*.errlog and MSDPM*.errlog.  There are 46kB worth of lines containing "0x8007045D" in the DPMRA*.errlog.  The other three searches yielded no results.  The "0x8007045D" errors all seem to look something like this:

0C84 1804 08/17 06:11:15.676 22 genericthreadpool.cpp(537) [0000000000D87210]  WARNING Failed: Hr: = [0x8007045d] Thread 6148 received ERROR

0C84 1C9C 08/17 06:11:15.676 18 bufferedmediareader.cpp(782) [0000000000DA0A30]  WARNING Failed: Hr: = [0x8007045d] CBufferedMediaReader - Received unknown error. number of bytes - 0, index - 5.

The strange thing is that all of the occurrences are from either 08/12 or after 06:00 on 08/17 which is after all the backup jobs had finished.  None of the "0x8007045D" timestamps seem to match up with 08/17 00:15 or 08/17 02:38 which are the times when DPM switched to new tapes.

I have added BufferQueueSize and BusyRetryCount to the registry.  The co-located protection groups in question are scheduled to backup to tape on Saturday night.  Is there any way to run Saturday's backup jobs early without manually changing the schedule of all of the protection groups?

Alex

• Edited by alx9r Tuesday, August 19, 2014 7:01 PM

Hi Mike,

It looks like my installation is affected by the console crash problem after the UR5 update. I was able to set your recommended configuration before the weekly tape backups, and I suspect the test ran, however, it'll be a couple days before I have a chance to dig into the fix and regain console access to my DPM server.  I'm hoping there is a Microsoft-supported fix to the UR5 console crash problem that emerges by then.

Alex

• Edited by alx9r Monday, February 16, 2015 5:53 PM