MAXDB 7.3 to 7.6 - Where is backup_start migration option?

[Former Member]

I'm upgrading from MAXDB 7.3 to 7.6.  Have relied on using "backup_start mediumname migration" in 7.3.  However, it appears that "migration" is no longer a supported parameter for backup_start in version 7.6.  We need to do a full backup on a database that is in admin mode without invalidating future incremental restores to that same database.  I have not found a way to do that in version 7.6.

[Former Member]

Hi Terry,

I'm not sure if I understood the problem correctly.

When you are doing a software migration from 7.3 to a newer MaxDb version a migration of the system devspace is done -> means the converter located on a seperate system devspace in 7.3 has to be removed and the convter pages will be stored as of version 7.4 directly on the data volumes. Therefore the upgrade tool forces a so called migration backup of 7.3 before the upgrade can go on.

But you are telling about version 7.6 which sounds like your upgrade to 7.6 has been executed sucessfully. So I think you are searching for the option executing a consistent back with a checkpoint, right?

In version 7.6 the before images are no more stored on the log volumes but on the data volumes as well. So if you are executing a 'normal' backup without the option migration a savepoint is triggered before. If you are using this backup for a recovery or a system copy and there are open transactions these open transactions can be rolled back ( before images are stored on the data volume and part of the data backup) without having any information of log backups or log volumes.

Does this answer your question?

Regards, Christiane

[Former Member]

Hi Christiane,

Thank you for the reply.  Our upgrade to 7.6 was indeed successful.

In a nutshell, here is the problem:

1) Perform Full Backup of Server A Database

2) Restore Full backup of Server A database to Server B

3) Perform incremental backup of Server A database

4) Restore incremental to Server B database

Rinse and repeat steps 3 and 4 over and over.  All works perfectly.

5)  At some point, maybe once every 3 months, perform FULL backup on Server B database and copy to a third machine on the same network as Server B for testing purposes.

Resume at step 3 not possible because of error "Incompatible incremental backup".

This was not a problem with Version 7.3 using the "backup_start mediumname MIGRATE" command.   We could pick right back up at step 3 and continue on.

Terry

[Former Member]

Hi Terry,

just for understanding

For the third system you are using a complete data backup and incremental backups of a isntance which is running on 7.6 already and you do not mix backups of system A and system B, right?

Ok you must use for a backup recovery process all backups from the same source system which has to be 7.6. Can you tell me which 7.6 version is used on the source and target system?

Can you attach files to this discussion? dbm.prt and dbm.knl and dbm.utl and if available the knldiag of the failed recovery.

Regards, Christiane

[Former Member]

1) Starting at the bottom of the image, I perform a full restore to Server B from backups taken on Server A.

2) I then perform an incremental restore (PAG_000000052).

3) I then perform another incremental restore (PAG_000000053).

Now that I've shown that the three restore files are fine, I will start over just for demonstration purposes.

4) I will do the full restore again using the same exact file as I did before in step 1 above.

5) I will do the first incremental restore again using the same exact file as I did before in Step 2.

6) Now, I will take a full backup of this same database (DAT_000000053).   (I want to clone the database to a 3rd machine for testing)

7) I then try to restore the 2nd incremental using the same exact file as I used previously in step 3.

The restore which worked previously fails.   This DID NOT happen with version 7.3 of maxdb which offered the "migration" parameter on the backup_start command.  That parameter is not shown to be a valid option on the 7.6 documentation.

Notice that the "Next Log Page" column appears to be intact.

[Former Member]

Let me correct something.  The example I sent actually shows the "Next Log Page" after the full backup "DAT0000000053" showing a 0.  I could look at that and tell right away that the next incremental restore is not going to work.    It's still a good example, but I can also produce an example where the "Next Log Page" does not reset to 0.  I'll send that next.

[Former Member]

For this example, I used the identical steps as prior example, except on the first example, I used "Recovery with Initialization" in Step 1.  For this example, I just used "Recovery".  Notice that this time, the "Next Log Page" does not get reset after step 6.  That is what I would expect to see and is exactly what we see with Version 7.6 of MAXDB.  However, it still does not help with the next incremental restore (Step 7).  I still get the exact same error.

[Former Member]

Hi Terry,

First of all you must know that as of MaxDB Version 7.6

the incremental backup content has been changed.

In MaxDB versions < 7.6 an incremental backup includes all changed data
pages which have not been saved before ( by save data or save pages)
As of MaxDB version 7.6 the incremental backup includes all changed
data pages since the last data backup!!!
So the incremental backup is growing with each time an incremental
backup is executed without a save data in between the save pages.

When you repeat the test szenario then you will observe, that if you
create a data backup of system A and you create eg. 6
incremental backups after the save data then you can do the recovery
on system B with only using the save data backup and the last
incremental backup. It is not necessary anymore to start with the
first incremental backup after the save data. You can use for the
recovery any save pages backup after this complete backup.

This behavior influences the recovery process on the target system as
well if you create a backup on the target system. Because the incremental backu includes all changes pages since
the last complete backup the backup on the target system avoids any
restore pages which include pages which were already restored with a
former restore pages. If this behavior is as designed - I don't know but I will discuss this in our team.

Currently with all MaxDb version >= 7.6 it is not possible to use restore pages on the target system after you executed a data backup on the target.

Regards, Christiane

[Former Member]

Hi Terry,

the reason for the avoided restore pages after the save data on the target is the check of the backupversion which is raised if you execute a backup on the target system.

I check with x_diagnose the restart record of the target db and compared this with the incremental backup which failed:

1. restart record on volume:

RESTART REC  0   Savept: at 2012-10-04 13:25:01 2  [block 1]

00001      restartr.pno: 0                 restartr.pt : data

00006      restartr.pt2: checkpt           restartr.chk: ChecksumLogInfo

00008      restartr.mde: empty

08181      checksum    : 215094            restart2.pno: 0

08189      restart2.pt : data              restart2.pt2: checkpt

08191      restart2.chk: ChecksumLogInfo

08192      restart2.mde: empty

00013      rstLayOutVer: 0                 rstIsConsist: false

00018      rstConfigPha: 0                 rstSetEndRdO: true

00020      rstLstSDOkay: true              rstConvVers : 88

00029      rstPrevConvV: 87                rstCurrBupVs: 88

00037     rstLstBupVs : 88  <----- this is the important counter !!!!!

2. restart record on the backup

RESTART REC  0   Savept: at 2012-10-10 15:14:24 2  [block 9]

00001      restartr.pno: 0                 restartr.pt : data

00006      restartr.pt2: checkpt           restartr.chk: ChecksumLogInfo

00008      restartr.mde: empty

08181      checksum    : 207261            restart2.pno: 0

08189      restart2.pt : data              restart2.pt2: checkpt

08191      restart2.chk: ChecksumLogInfo

08192      restart2.mde: empty

00013      rstLayOutVer: 0                 rstIsConsist: false

00018      rstConfigPha: 0                 rstSetEndRdO: false

00020      rstLstSDOkay: true              rstConvVers : 89

00029      rstPrevConvV: 88                rstCurrBupVs: 89

00037      rstLstBupVs : 87  <------ !!!! this is not the same number anymore

Unfortunately with all current MaxDB Versions your szenario is not possible anymore.

Regards, Christiane

[Former Member]

Christiane.

Thank you so much for checking in to this for me.   I guess it's back to the drawing board for me.  Of more concern is the fact that incremental backups now contain all changes since the last FULL backup.  Wow.  Are you 100% sure about that? If that is true, it would have affected a LOT of people negatively. That is the definition of a DIFFERENTIAL backup.

Terry

[Former Member]

Hello Terry,

yes I'M 100% sure that the incremental backup now saves all changed data pages since the last complete data backup. The incremental is related to the last complete data backup. So if you check your incremental backup you will see that it is growing. And you can check it as I did.. I created a complete data backup. Then I created a new user, and some tables with content. Then I created asave pages. Then I created another user and some tables which belong to this user with content. Then I did the second save pages.

Then I used all 3 backups to create a new database.

First test -> restore + initialize

restore pages 1 + save data on the target -> followed by restore pages 2  -> failed with the error message you have as well

second: resore data + initialize ( to clear the log) -> followed by restore pages 2 without restoring restore pages 1 -> no error message -> and restart of the database to check if all data is available -> it was. This was not possible with Version 7.3

Nevertheless is is working with the restore pages as it was working before - it is possible to restore all created save pages after the save data on the second isntance in sequential order, but this process is not possible anymore if you start a save data on the target system. Then the backup version is raised and this avoids the on going with restore pages.

REgards, Christiane