Showing results for 
Search instead for 
Did you mean: 

Jobs won't un-que and creates a @@@@@@@@.bkf

Level 2

I just set up a NAS using iSCSI and connected it with a Windows Server 2008 R2.  The connection is working.  I can copy files to the iSCSI drive.  BE2010 sees the iSCSI drive.  I have created a Device in BE2010 which successfully completed.  BE2010 successfully creates a Back-up-disk-Folder on the iSCSI drive.  I created a simple backup job to test everything.  It just backups some Word and Excel files.  I have run the credential check in the job creation successfully.  Domain Admin account is used for BE2010.

When the job is submitted to run, it sits at "Queued" forever and won't actually run the job.  I have waited for the job to start over night (10+ hours) to backup less than 200mb of data and it never runs. In the Back-up-to-disk-Folder, BE2010 seems to have started because it created a "Changer.cfg" and a "Folder.cfg" file.  But then it also created another file labeled "@@@@@@@@.bkf" which ought to be the backup file right?  I need some help.  What is going on?


Partner    VIP    Accredited

Some things to check:

1. right-click the job and choose Respond to Alert and see what the issue is;

2. Make sure any installed AV isn't actively scanning the B2D folder, and if it is, put in exclusions for this.


Level 2

Respond to Alert is greyed out.

AV isn't set to scan the iSCSI folders but I checked and the AV engine wasn't running a scan at all.

From another thread, I read that Pausing/Unpausing the folder under the Devices tab might work.  I tried that but it didn't make a difference.  There was some advice to try Disenabling/Enabling it in a like manner.  Tried and no effect.

I know BE2010 can access the folder because if I run an Inventory job, it completes successfully in under 10 seconds.  It's as if BE2010 cannot handle dealing with an empty, clean, new folder for the first time.  Like it expects some kind of file or data to already be there or something and then just waits as a Queued job.  (Not saying that is actually the case, just what it seems like.)

I'm going to create a blank text file in one of the new folders I made on iSCSI drive and then rename it something like "B2D0000001.bkf" AND then try running the test backup job so see if that helps.

Level 2

So the jobs ran over night with fake .bkf files and after 10 hours they failed with "User Cancelled the Job" which wasn't true as I never did.  I looked into the job logs and found that they failed either because a user canceled OR the device was offline and the job had timed out.  OK, 10 hours is a ridiculously long time for BE2010 to decide a device is offline but ok fine that's some more info to work out.  The log also listed " V-79-57344-33039 - Error - Mount failed. User canceled a Physical Volume Library operation."  Clicking on the link sent me to the article:"  Reading there listed:

The backup job fails with the above error message and at the same time shows an alert  in Backup Exec:

Backup Exec Alert: Media Error.
The Backup-to-Disk device is offline.
This is typically caused by the folder becoming inaccessible due to it being deleted, renamed, or unshared. It may also be caused by a disk full condition. The folder state has been set to offline. Please attend to this condition. Additional detail may be found in the Event Viewer - Application Log. 
The Application Event Log contains the Event ID 58057 and 33808 respectively.
Yep the App Event Log had those IDs alright.  Oh and look there's our friend the @@@@@@@@.bkf in the 33808 event!
The cause?  "This issue occurs when the option "Allocate the Maximum size for backup-to-disk files" is selected while creating a backup to disk folder. This option is typically referred to as pre-allocation and is available on the General tab of each B2D device."
So BE2010 can't handle a clean, new, formated, empty iSCSI drive AND allocate the whole drive for backups?  I mean the drive is there FOR backups.  The resolution of course is to turn off the "Allocate the Maximum size for backup-to-disk files" which I suppose means that now BE2010 won't try to make one .bkf file the entire size of the empty folder???  In any event, turning off that "feature" let the test backups run immediately without getting stuck at "Queued" for hours and hours.  I'm glad I figured out how to get the test jobs to run (the ACTUALLY backups will start tonight with fingers crossed) but I got to stay that "Allocate the Maximum size of backup-to-disk files" does NOT seem like it is functioning as someone would expect it to.  I mean if BE2010 can see a folder on an empty iSCSI drive with 1TB of free space, then it should be able to know that it has 1TB of free space to work with and then start backing up files!  Don't know if BE2010 is still being supported with updates but if so, there is an issue here that needs looking at.
Thanks CraigV for the advice and help!

Employee Accredited Certified

If that is BE 2010 and NOT BE 2010 R3 I would suggest you update. (as it might be somethign we have address (and 2010R3 wil work with yoru existing licenses)

With regards the allocate max size - it can take time to allocate the max size and this can look like a hang (and depends on the write speeds etc)

I hope you are not allocate all of the size of the disk to the BKF file as this very likely will cause a hang - the intention of this setting is for you to still use sensible BKF sizes but reduce fragmentaion on the disk. As such whilst whatever the default size is might be too small (especially for BE 2010) and you can increase the size you should not increase it too far.


Finally we have enhanced the pre-allocation in the newer versison of Backup Exec to be configurable in such a way that you can pre-allocate part of the file size etc. I think we have also made sure that white space in the pre-allocation that is not used when the job ends is recovered and not left as used on the file system. As such (after checking our compatibility lists carefully) if you want to use pre-allocation but want more control then you would need to upgrade to BE 15.