3006027 - HANA Recovery does not fail in spite of empty log directory

Based on a storage snapshot, following HANA Recovery has been done:

RECOVER DATABASE FOR AB1 UNTIL TIMESTAMP
'2020.07.01 00:00:00' CLEAR LOG USING CATALOG PATH ('/hana_log_archive/LM1') USING LOG PATH ('/hana_log_archive/LM1') USING SNAPSHOT.

In that special case, the wrong Log directory has ben used here /hana_log_archive/LM1 used. This directory includes old logs from an older HANA 1.0 release. The correct directory would be /hana_log_archive/DB_BX1.

But the HANA Recovery does not fail and it recovered the Database not to the desired timestamp '2020.07.01 00:00:00', it was recovered to the timestamp '2020.06.30 02:00:00'.
The second timestamp is the timestamp of the storage snapshot.

2020-07-01T16:46:02+02:00 P413710 1730ad7822a INFO RECOVERY RECOVER DATA started [1593614762538]
2020-07-01T16:46:02+02:00 P413710 1730ad7822a INFO RECOVERY command: RECOVER DATABASE FOR AB1 UNTIL TIMESTAMP '2020.07.01 00:00:00' CLEAR LOG USING CATALOG PATH ('/hana_log_archive/LM1') USING LOG PATH ('/hana_log_archive/LM1') USING SNAPSHOT
2020-07-01T16:46:04+02:00 P413710 1730ad7822a INFO RECOVERY using backup catalog 1590125350164 from /hana_log_archive/LM1/log_backup_0_0_0_0.1590125350164
2020-07-01T16:46:04+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryExecuteTopologyRecoveryInProgress
2020-07-01T16:46:05+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryExecuteTopologyAndSSFSRecoveryFinished
2020-07-01T16:46:05+02:00 P413710 1730ad7822a INFO RECOVERY The following strategy is used:
2020-07-01T16:46:05+02:00 P413710 1730ad7822a INFO RECOVERY from snapshot: hdb00003 in /hana/data/LM1/mnt00001
2020-07-01T16:46:05+02:00 P413710 1730ad7822a INFO RECOVERY from snapshot: hdb00004 in /hana/data/LM1/mnt00001
2020-07-01T16:46:05+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 0, RecoveryExecuteTopologyRecoveryInProgress
2020-07-01T16:46:05+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 0, RecoveryExecuteTopologyAndSSFSRecoveryFinished
2020-07-01T16:46:20+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryPrepared
2020-07-01T16:46:20+02:00 P413710 1730ad7822a INFO RECOVERY state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, RecoveryPrepared
2020-07-01T16:46:20+02:00 P413710 1730ad7822a INFO RECOVERY start of progress monitoring, volumes: 2, bytes: 0
2020-07-01T16:46:25+02:00 P413710 1730ad7822a INFO RECOVERY state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, RecoveryExecuteDataRecoveryInProgress
2020-07-01T16:46:25+02:00 P413710 1730ad7822a INFO RECOVERY state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, RecoveryLogReplayStarted
2020-07-01T16:46:25+02:00 P413710 1730ad7822a INFO RECOVERY progress of service: xsengine, hdb11hk1-001-se:31107, volume: 4, 0% 0/1
2020-07-01T16:46:31+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryExecuteDataRecoveryInProgress
2020-07-01T16:46:31+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryLogReplayStarted
2020-07-01T16:46:31+02:00 P413710 1730ad7822a INFO RECOVERY progress of service: indexserver, hdb11hk1-001-se:31140, volume: 3, 0% 0/1
2020-07-01T16:50:34+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryLogReplayFinished
2020-07-01T16:50:35+02:00 P413710 1730ad7822a INFO RECOVERY state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, RecoveryLogReplayFinished
2020-07-01T16:51:47+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoveryRestartCompleted
2020-07-01T16:51:51+02:00 P413710 1730ad7822a INFO RECOVERY state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, RecoveryRestartCompleted
2020-07-01T16:51:57+02:00 P413710 1730adcee63 INFO LOGBCKUP state of service: indexserver, hdb11hk1-001-se:31140, volume: 0, BackupExecuteCatalogBackupInProgress
2020-07-01T16:51:58+02:00 P413710 1730adcee63 INFO LOGBCKUP state of service: indexserver, hdb11hk1-001-se:31140, volume: 0, BackupExecuteCatalogBackupFinished
2020-07-01T16:51:58+02:00 P413710 1730adcf05d INFO LOGBCKUP state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, BackupLogStarted
2020-07-01T16:51:58+02:00 P413710 1730adcf05d INFO LOGBCKUP to file: /usr/sap/HK1/HDB11/backup/log/DB_AB1/log_backup_4_0_1171983360_1171983488.1593615118429
2020-07-01T16:51:58+02:00 P413710 1730ad7822a INFO RECOVERY RECOVER DATA finished successfully
2020-07-01T16:51:58+02:00 P413710 1730ad7822a INFO RECOVERY state of service: indexserver, hdb11hk1-001-se:31140, volume: 3, RecoverySuccess
2020-07-01T16:51:58+02:00 P413710 1730adcf05d INFO LOGBCKUP start of progress monitoring, volumes: 1, bytes: 8192
2020-07-01T16:51:58+02:00 P413710 1730ad7822a INFO RECOVERY state of service: xsengine, hdb11hk1-001-se:31107, volume: 4, RecoverySuccess

It looks, that the recovery have been done for the Data recovery, which was valid for the timestamp of the '2020.06.30 02:00:00'. A log backup was not able to find in the wrong path. This looks to be the cause, why the recovery to '2020.07.01 00:00:00' was not possible.

SAP HANA DB Version 2.0

PIT, point.in-time, point in time , KBA , HAN-DB-BAC , SAP HANA Backup & Recovery , Problem