Skip to Content

Restoring MaxDB from a Network Drive?


currently we are working on a system refresh (Windows 2008 R2 + MaxDB) with SWPM10 as <SID>adm.

At the moment we are stuck at the restore in the MaxDB Database Studio. At the point when the SWPM tells us to "Use the DBMGUI to perform a database recovery..." we tried to do this.Our backup files are waiting on a network drive.

In DB Studio via Administration Tasks -> Recovery we set up a new parallel backup template. We put the Path "X:\PRDBr\PRD_COM_0" Under "Device/File" in Device 1. Device 2 holds "X:\PRDBr\PRD_COM_1".

See for yourself in this screenshot:

Unfortunately we are being confronted with the error message that you can see in the top left of the screenshot:

-24994 Runtime environment error 1, wrong path

Instead of using drive letters we also tried UNC paths like: \\server\backup\PRDBr\PRD_COM_0 and \\server\backup\PRDBr\PRD_COM_1. This leads to another error message: -24994 Runtime environment error 1, access denied

The UNC path and the network drive are perfectly accessible by the user <SID>adm in Windows Explorer.

Can you give us any support on that issue? We would greatly appreciate that :-)

Thanks so far and regards


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    May 01, 2015 at 10:11 AM

    Update: The restore seemed to work fine. We got it working by using an UNC-Path plus setting the Security Restrictions on that share to "Everyone" temporarily.

    What raises my interest here is: Setting it to Everyone is just not feeling right. What user should have had access to the share?

    Next thing now: Recovery of Log Files. We wanted to restore the DB to 30.04.2015 14:00 h. So we created a corresponding template with this timestamp for point in time recovery. Restore worked great.

    Question here: How can I make sure that the DB has the state from 14:00 h.

    By checking the summary screen in DB studio I can see "Last Commit" was 12:05 h.



    Add comment
    10|10000 characters needed characters exceeded

    • Ah, OK... I see. This was, since we were doing a point in time recovery. Additionally there is a (also copied) BW system and therefore we set the recovery timestamp on both to 14:00 h to get the maximum possible synchronization between the two systems.