How many online probkups can be taken?


Article Number000068748
EnvironmentProduct: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Question/Problem Description
How many online backups can be taken?
Is there a limit to the number of times a database can be backed up online
Will PROBKUP online always be reliable?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement NumberEnhancement PSC00343851
PROBKUP has a limit of 65535 online backups:

The backup counter stored in the database Master Block is 2 bytes which has a maximum value of 65535 .

The backup counter is incremented in the Database Master Block every time a PROBKUP is run (online, offline; full, incremental).  For example, if one PROBKUP is taken every hour (online/offline/incremental), the counter will overflow in ~7 years. An Enhancement has been requested but not been implemented in the product to date.

Once the backup counter overflows:
  1. The logic in the online backup routine, which determines if a block should be backed up, does not consider existing data blocks as their backup counters are higher than the overflow value stored in the master block backup counter. The online backup will initially only backup 'new' database blocks that have never been backed up (ie empty blocks that have been formatted) and from that point on, these database blocks if they qualify and 'new' database blocks resulting in an invalid backup volume.
  2. The offline backup's logic is different and is not affected by the backup counter overflow. In other words, an offline PROBKUP will be complete and a full restored database will result, but subsequent online PROBKUP of this restore will suffer the same online backup counter overflow logic.
To reset database block backup counters:

Once the backup counter has overflowed, neither PROCOPY nor offline backup PROREST will reset block backup counters. The following methods each have their pro's and con's which will need to be mooted per user case:
  1. A dump and load of the database is needed to re-initialise the counters on all database blocks.
  2. Another strategy is to tablemove/indexmove all database objects to new Storage Areas, then remove the existing Areas. This includes using 'PROUTIL -C mvsch' to re-initialise the Schema Area.
Until the database block backup counters can be reset:

An alternative backup strategy will need to be engineered, Options include:
  • Offline PROBKUP
  • Online OS copy (with PROQUIET on Enterprise databases)
  • AI Rollforward
  • OpenEdge Replication Target database online PROBKUP (available since OpenEdge 10.1C)

OpenEdge 10 and later: To determine if the current backup counter value

1.  Examine the value of "bk_incr" in the Master Block approaching 2^16 - 1 = 65535
$  proutil dbname -C truncate bi
$  proutil dbname -C dbrpr

Select the following Menu options, or provide these in an input text file as outlined below.
13. Display Block Contents
3. Select Block Type
C. Clear all types
1. Master Block
R. Return to Display Menu
G. Go

Schema Area (6)  Extent 1  Block 2
0000 bk_dbkey:     0x00000020         32
     bk_type:      0x01               1 (Master Block)
     bk_frchn:     0x7f               127 (NOCHN)
**   bk_incr:      0xFC92             64658

Progress 9 : To determine if the current backup counter value

The DBRPR Menu Options above are not available in Progress 9. Instead, the Master Block needs to be dumped with DBRPR and analysed, where the backup counter value is on the first line offset 06-07

1. The database Master Block for a multi-volume database is the second physical block of the first data extent (Schema Area).
Identify if the Schema Area has 32 or 64 records per blocks (RPB) from the database structure with "prostrct list <dbname>

2. Use DBRPR to dump the Master Block from the Schema Area (6).

By default the DBRPR tool starts in the Schema Area:
Current Working Area: Schema Area

The Master Block is the first Block in this Area:
  • If the Schema Area is 32 RPB then the dbkey for the master block is 32.
  • If the Schema Area is 64 RPB then dbkey for the master block is 64.
$  proutil dbname -C truncate bi
$  proutil <dbname> -C dbrpr <> /dev/null 2>&1

Where contains:

<Substitute with 32 or 64 depending on the RPB value>

Alternatively, navigate the DBRPR CHUI menu manually:
4. Dump Block
Enter dbkey: <32 or 64>

Examine the resulting 32.dmp or 64.dmp file:

The bk_updctr is at HEX offset 06-07

Example: The current backup counter value is 0xFDFE == 65,022  (513 backups remaining)

>0000    4000 0000 017F FDFE 0000 0000 0000 00E6

On Windows, the value is byte swapped: 

Example: The current backup counter value byte swapped is 0xFDFE == 65022 (513 backups remaining)

>0000    4000 0000 017F FEFD 0000 0000 00E6 0000

Other 'tells' that the backup counter has overflown: 

Just because the bk_incr value is not approaching the 65535 limit, it may have already overflown.  Further samples of data blocks will need to be examined through the above DBRPR menu to find if there are any blocks with higher backup counter values. 
a.  The online backup is a lot quicker than usual, as there are less blocks that qualified to be backed up
b.  The online backup volume is smaller than it should have been, provided the same volume is not overwritten by subsequent backups.
c.  The backup volume will also restore faster than usual.
d.  Parsing historic database lg files, the number of "backup blocks" drops dramatically then starts increasing again:
(13625) Wrote a total of 11955 backup blocks using 1.6 GBytes of media
(13625) Wrote a total of 16 backup blocks using 2.1 MBytes of media.
(13625) Wrote a total of 806 backup blocks using 107.1 MBytes of media.
e.  Approximating the HWM from prostrct statistics with the backup blocks written from full online backups will show that online volumes do not include all blocks to the HWM of each Area
This database backup volume should be around 1.6 GB using 11955 backup blocks with a default -bf 34 and database blocksize of 4KB
f. The PROREST (restore) of this online backup will succeed, but the restored database is unlikely to be accessible when blocks that were not backed up are involved with BI redo or undo processing. If the database is accessible, it will crash with block corruption (1124) errors, where the blocks found are empty. 
(9445)  SYSTEM ERROR: read wrong dbkey at offset
(1124)  SYSTEM ERROR: Wrong dbkey in block. Found 0, should be <dbkey> in area <area number>. 
Progress Article: 

000020230, What happens during an online backup of the database?   
Last Modified Date4/17/2019 8:21 AM

Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025