Hi,
I am on W2K3, MaxDB 7.8.02.23.
After using note 85736 I am able to create a backup on a windows network share.
Unlike a Linux samba share, where you can disable the security descriptor check, this setup is somewhat anoying because if you are not in a domain, you need to keep users an passwords in sync manually and so on. Anyway, switching the MAXDB Service to sidadm results in a successfull backup to a network share.
OK, now I like to verify my backup, but:
dbmcli on J21> recover_check J21_DB_STD DATA
-24988,ERR_SQL: SQL error
-903,Host file I/O error
6,Data recovery failed
113,Open medium on \\SERVER\SHARE\J21\DATA\STD\X\J21_DB_FULL.BACKUP for READ failed
Servertask Info: because Error in backup task occured
Job 1 (Backup / Restore Medium Task) [executing] WaitingT15 Result=3700
Error in backup task occured, Error code 3700 "hostfile_error"
1,Open file \\\SERVER\SHARE\J21\DATA\STD\X\J21_DB_FULL.BACKUPfailed, CreateFile(READ,EXISTING) returned 'Access is denied. ' (5)
When checking the taskmanager while trying this out, I suddenly noticed, that when executing
dbmcli on J21> service_connect
A new kernel.exe process did appear, which was owned by user SYSTEM, which now has the very same problem reading the backup-file as the DB had, before I did change the service owner to sidadm, for writing the backup..
Now the share-backup itself is valid. When I copy it back to a local drive and define a corresponding medium to the new location the check executes fine. You can watch the new kernel.exe owned by SYSTEM eating CPU in the check, so I am sure that this is really the guy executing the backup check.
Questions:
1) Did anybody, backing up to a share, ever tried to restore from the share?
2) May be a real restore (which I did not try for verification yet) is not executed with a seperate kernel.exe, so it might work, because the "real" one is running with the sidadm user. Can anyone confirm that?
Thanks for feedback
Volker