maxdb 7.6.00.35 recovery problem, -24988 and -903 host file I/O error

[Former Member]

I am trying to recover a full file backup taken from our production system to disk.

It is to be recovered to a new server into a newly installed empty DB.

the two servers are identical windows dl360g4s

I have shared the disk with the DB backup from the production machine to the new server

however whether utilising the dbmgui or dbmcli the recover fails with a -903 I/O error on the "shared" backup file.

The dbmcli output is below, can anyone cast any light on the error please?

is the problem due to using a fileshare from another server and if so is there any way around that?

please don't suggest copying the file locally as it is 1.4TB in size and we don't have that available.

dbmcli on sdb>db_connect

OK

---

dbmcli on sdb>db_state

OK

State

ADMIN

---

dbmcli on sdb>medium_getall

OK

filefull M:\MaxDBbackup\full FILE DATA 0 8 NO NO 20110216135349 20110216

135349 NONE

---

dbmcli on sdb>db_activate RECOVER filefull

ERR

-24988,ERR_SQL: SQL error

-903,Host file I/O error

6,Data recovery failed

1,Backupmedium #1 (M:\MaxDBbackup\full) wrong path specified [3]

6,Backup error occured, Errorcode 3700 "hostfile_error"

17,Servertask Info: because Error in backup task occured

10,Job 1 (Backup / Restore Medium Task) [executing] WaitingT69 Result=3700

6,Error in backup task occured, Errorcode 3700 "hostfile_error"

---

dbmcli on sdb>

Thanks in advance

Graham

[markus_doehr2 · Accepted solution]

Is the name of the database backup file "full"?

Markus

[Former Member · Accepted solution]

Hello Markus,

yes the file is called "full" in "M:\MaxDBbackup\"

the medium is called filefull, this is the same naming convention I have used on the other systems in the landscape and my other sapdb/maxdb landscapes so I am sure the name is not a problem as I have recently restored anotehr copy of similar size using that name. the only difference here is taht the disk is not local but a fileshare from another system.

Regards

Graham

[markus_doehr2 · Accepted solution]

> the only difference here is taht the disk is not local but a fileshare from another system.

The user running the database must have access to that share, not the user you're logged on with. That's a common "misunderstanding" in Windows. What you see is NOT what you get. The safe way on Windows is not using drive letters for network drives but UNC names.

If the database is running with the account "local system" it doesn't know drive "M:" and hence can't open the file. It even couldn't use an UNC name.

So you have two options:

- change the user running the MaxDb database kernel to a "real" user who's able to access a network share and use an UNC name instead of a drive letter to connect. The user must also have "act as part of the operating system" right.

- copy the file locally

Markus