We have a W2K3 Server Enterprise with BESR 7.03 After updating the OS last week snapshots didn’t work.
We received error codes EC8F17B7, E7B70001 and EBAB03F1 referencing IOCTL_SNAP_VOLUME_EX. We restarted the server, following Document 298930 (but didn’t add physical memory) and now we get the following error whenever we try to do a backup of a drive other than C:
Error EC8F17B7: Cannot create recovery points for job: Recovery point of E:\.
Error E7B70001: Win32/Win64 API DeviceIoControl (IOCTL_QUERY_SNAP) failed.
Error EBAB03F1: The parameter is incorrect.
We don’t think that the problem is caused by low server resources (because it worked last week on the same hardware), and apparently there is no problem accessing the drives. Any help will be welcome. Thanks in advance.
sorry I didn't answer on time. Finally we had to reinstall Symantec BESR and I forgot this post.
Anyway, the problem was not only with drive E, but with every volume and VSSADMIN doesn't apply, because we are not working with version 8 (running 7.0.3 with no expectations of upgrading in the near future)
I have remembered this post today because we're having similar issues now. The difference is that this time there are no OS updates to blame. Yesterday, suddenly, snapshots began to fail. These are all the facts:
1) Symantec BESR 7.0.3 on W2K3 Server Enterprise working fine since september 26th: it makes regularly recovery points of volumes C, E, X, Q and W
2) BESR makes a base recovery point of volume W last sunday
3) BESR makes a snapshot of volume W on monday, at 10:00 AM. Next snapshots are scheduled at 15:00 and 20:00.
4) At 20:00 BESR registers in the application log the following:
Info 6C8F17E7: An automatic recovery point was not created because an earlier recovery point from the same job was still in progress
(So, the snapshot that should begin at 20:00 can't start because the one from 15:00 is still working... ok, we don't matter as long as the task manages to end)
5) But at 21:30 Backup Exec registers in the App Log:
Error EC8F17B7: Can't create recovery points for W volume (...) Error E7B70001: Win32/Win64 API failed DeviceIoControl(IOCTL_SNAP_VOLUME_EX) . Error EBAB03F1: Insufficient system resources exist to complete the requested service Details: 0xE7B70001
6.) From then on, every attempt of making a snapshot of W fails immediately (entire volume or just one folder, or even just one file, and independently of the destination of the backup) with the following error:
Error EC8F1C50: Can't create recovery point (...). Error E7B70001: Win32/Win64 DeviceIoControl(IOCTL_VSNAP_SET_BEGIN_PREPARE) API failed . Error EBAB03F1: The requested resource is already in use. Details: 0xE7B70001
*BUT* snapshots of all the other volumes available on the server (C, E, V, X, Q) work well. So the problem is only with W.
7.) We have checked server resources, they are not a problem (enough disk, memory; two processors... )
8.) We have followed instructions on Document 293307 ("Scheduled jobs do not run and the Application Event Log shows the message 6C8F17E7") to no avail; we keep on receiving the above error when trying to make a snapshot of W. What is the "requested resource already in use"??? What is using it??? Can't we tell it to stop??? Searching the Symantec KB and forums has shed little light on the problem...
It seems to me now that BESR corrupts periodically, but we'd like to avoid having to reinstall the application once again. Any help will be appreciated, thanks.
An update: we have solved the problem for now repairing the install. We tried this first and worked, so at least we did't have to reinstall the whole app.
I think the information we've gathered with this test is worth being posted:
1) Our W2K3 server (lets call it Server1) is member of a two-node cluster which has only disk and folder resources, and it is the owner of the cluster. It must be the owner because if not, BESR wouldn't have access to Volumes V and W (these are resources of the cluster).
2) When we tried to repair the install we received a BSOD (0x0000007e (0xc0000005, 0x8084014f, 0x8b695c44, 0x8b695940)
3) after restart we gave the ownership of the cluster to the other member, Server2. Then we tried again to repair the installation and this time we succeded.
4) We returned the ownership of the cluster to Server1, scheduled the backup jobs and they have worked OK this weekend. The incremental recovery points are working ok as well for now
...So it seems that the problem is somehow cluster-related. The odd thing about that is that BESR had no problems to backup volume V (a cluster resource too)
Although the problem is solved by now, any information or help will be still welcome. TIA