Neverending story: Backup to network SHARE

[volker_borowski2]

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

[former_member229109 · Accepted solution]

Hello Volker,

If you want to back up data to a data carrier on a remote computer, perform the steps described in Database Administration, Backing Up and Restoring Data with Remote Computers, document.

http://maxdb.sap.com/doc/7_8/44/d7a7baa8f42754e10000000a1553f6/content.htm

Regards, Natalia Khlopina

[volker_borowski2 · Accepted solution]

Hello Natalia,

yes this is exactly how I proceed to create the backup.

Unfortunately, as described, the recover_check procedure does not work.

Allthough the kernel.exe running for the DB I like to verify is running under user j21adm

AND the user running the dbmcli is j21adm as well,

when executing "service_connect" the kernel.exe started fro that session belongs to SYSTEM.

Could this be a bug?

Volker

[thorsten_zielke · Accepted solution]

Hello Volker,

this is not a bug, it works as designed 🙂

MaxDB uses a second 'hidden' database instance for the 'recover_check' to prevent causing performance problems on the original database instance.

You can display that instance via the 'all' switch with 'dbmcli db_enum all'. Every MaxDB installation comes with a second so called 'service' database - its name always starts with a leading '.'.

These service instances do not have any volumes configured, it is just a database kernel, which can only be started to 'admin' state and its only purpose is to perform the 'recover_check'.

You can also find the path to the rundirectory with 'xinstinfo <.dbname>'. There you would find the usual log files like KnlMsg and so on...

This explains why the MaxDB kernel process runs as 'system' when doing the 'recover_check' - it is simply the default owner of the kernel on Windows. I would suggest changing the owner of that service kernel as you did with the standard kernel - then the backup check hopefully works.

One note to the 'recover_check (aka 'backup check)':

This check reads all database pages from the backup file, checks the page integrity and discards them afterwards (no volumes attached, content goes to dev/null). The recover_check does *not* build a database and that is important to keep in mind. Because this check is limited to page integrity. As it does not create a database, it cannot verify beyond each page e.g. it cannot detect damaged B*trees or other meta structures that consist of many single pages. This is what the 'check data' does, because it also verifies that the pointer to neighbouring pages within a B*tree are correct. So the best check strategy imho would be to recover your database to a second database instance on another server and after the recovery perform a 'check data'. This would be 'safest' option we can offer.

Thorsten

[volker_borowski2 · Accepted solution]

Hi Thorsten,

on that Server I have an IDES DB of 250 GB and a related J2EE DB of 5 GB.

Both have their own DB SW set and both are on 7.8.2.23.

I found 4 DOT-MAXDB Servcies belonging to "local system".

MAXDB:  .M780201

MAXDB:  .M780201 (slow)

MAXDB:  .M780223

MAXDB:  .M780223 (slow)

The first two are pointing to binaries in the J21 location, the others to IDES.

I changed the Service Owners one by one, and for J21 it turned out

that the service started was "MAXDB:  .M780201"

when doing the service_connect.

Allthough I am a bit confused, that this appears to be the wrong kernel (version), everything went fine. The backup on the share was accessible and validated successfully. Next problem would be the questinon: What happens when I try to validate the IDES DB which has another sidadm...

Looks at least as if the name for these shadow-services could be chosen in a more telling way 🙂

I do not need to trust this type of validation, it was just a test if the backup would be accessible via LAN at all, which I need esp. for the IDES DB, since I have not enough local spare diskspace to keep a local backup.

Anyway: can you confirm that a "real" restore will be done by the original service, so that I do not need to toggle around Service Users when doing a real restore?

Thanks a lot

Volker

[thorsten_zielke · Accepted solution]

Hi Volker,

yes, I can confirm that a 'real' restore will use the original MaxDB database instance. The service instance can only be used for the 'recover_check' and not for a 'real' restore (because it has no volumes configured...).

Thorsten

PS:

The 'slow' MaxDB kernels you noticed with 'db_enum' are debug versions of the database and are mostly used in development to e.g. locate bugs. The debug kernel can be started with 'db_admin -slow' (if the regular 'fast' kernel is offline). However, the slow kernel runs indeed much slower, so there is no use case for you I can think of - just wanted to elaborate why there are so many different kernel versions...

[volker_borowski2 · Accepted solution]

Hi Thorsten,

thank you very much. Meanwhile I have been able to verify the IDES Backup with the related adjusted shadowservice as well. Only problem is, you need to specify AUTOIGNORE in addition, when the backup was done to a parallel medium.

Just for information for people struggeling along the same path:

If you ever can, use Windows Domain Users and Domain Permissions

When the backup to the share finishes, it re-writes the permissions of the backup target file. In a non domainsetup, you will loose the permissions for the "local" sidadm. Thus a second backup with OVERWRITE will fail, because the Re-Open is done with the LAN credentials and the target files has only the S-Identifier from the source Server attached. So after the first backup, you need to attach local "sidadm" permissions on the target files to enable the next backup to overwrite.

Finally I have everything working now.

My closing test (may be next week) will be a real restore, which I could not schedule right now.

Thanks again

Volker