Hi Forum (OE 11.7.5)
Playing a bit with incremental backup and the incremental overlap option (-io). I am wondering how Progress can prevent me from restoring an inappropriate incremental backup because I cannot find how/where the incremental overlap is written in the bk file, or how it would refer to an earlier incremental (it always refers to the previous incremental) :
I did 4 backups:
1) a full backup
2) inc1 incremental 1 with -io 0
3) inc2 incremental 2 with -io 1
4) inc3 incremental 3 with -io1
Then I restore the full backup somewhere. If I try to restore inc3 right away on top of it then it gives this expected message:
Incremental restore out of sequence on restoredDb
WARNING: Applying this incremental backup could damage your database. (6774)
Fine so I first restore inc1, then I can restore inc3 because it was done with -io 1 so it includes inc2.
Now I am perplex when I look at the two or three lines of the bk files, because they mention time stamps, the incremental backup number, the timestamp of the previous incremental backup (I've stripped out trailing NUL chars):
1) volume 1 of backup taken Fri Sep 27 17:23:36 2019 for OPENEDGE database:
C:\_rd\local\sports2000\sports2000.db
2) volume 1 of backup taken Fri Sep 27 17:24:08 2019 for OPENEDGE database:
C:\_rd\local\sports2000\sports2000.db
incremental backup 1, taken after full backup of Fri Sep 27 17:23:36 2019
3) volume 1 of backup taken Fri Sep 27 17:24:22 2019 for OPENEDGE database:
C:\_rd\local\sports2000\sports2000.db
incremental backup 2, taken after incremental of Fri Sep 27 17:24:08 2019
4) volume 1 of backup taken Fri Sep 27 17:24:47 2019 for OPENEDGE database:
C:\_rd\local\sports2000\sports2000.db
incremental backup 3, taken after incremental of Fri Sep 27 17:24:22 2019
I would better understand if the header of inc4 was saying taken after incremental of Fri Sep 27 17:24:08 2019, the time stamp of inc2.
The map of backup header in old Progress versions:
# Progress backup header: # # V8 V9 # Offset Offset Len Description # ------ ------ --- ----------- # 0 0 80 Backup volume description # 80 80 80 Full path to the database # 160 160 80 Incremental backup description # 264 264 4 Date/Time of current backup # 268 268 4 Date/Time of previous full backup # 272 272 4 Date/Time of previous incr backup # 276 276 4 Incremental backup number # 280 280 4 Database high water (V8 only) # 284 284 4 Value 0 # 288 288 4 BI blocksize # 293 293 1 Is online (1 - online, 0 - offline) # 296 296 4/8 Backup Volume Size (-vs) divided by blocking factor (-bf) # 300 304 4 Blocking factor (-bf) # 304 308 4 Backup volume number # 308 312 4 First backup block in volume: 1+VolSize*(BkupVolNumr-1) # 312 316 1 Is incremental (2 = Incremental) # 313 317 60/255 Database path # 376 620 4 \07 \07 \07 \07 # 380 624 4 Last transaction number # 384 628 4 Overlap factor (-io) # 391 635 1 Is compressed (-com) (2 = Enable) # 392 636 2 Redundancy (-red) # 396 640 4 Backup header CRC # 400 644 2 Database blocksize
Recent versions have the similar header.
The map of backup header in old Progress versions:
# Progress backup header: # # V8 V9 # Offset Offset Len Description # ------ ------ --- ----------- # 0 0 80 Backup volume description # 80 80 80 Full path to the database # 160 160 80 Incremental backup description # 264 264 4 Date/Time of current backup # 268 268 4 Date/Time of previous full backup # 272 272 4 Date/Time of previous incr backup # 276 276 4 Incremental backup number # 280 280 4 Database high water (V8 only) # 284 284 4 Value 0 # 288 288 4 BI blocksize # 293 293 1 Is online (1 - online, 0 - offline) # 296 296 4/8 Backup Volume Size (-vs) divided by blocking factor (-bf) # 300 304 4 Blocking factor (-bf) # 304 308 4 Backup volume number # 308 312 4 First backup block in volume: 1+VolSize*(BkupVolNumr-1) # 312 316 1 Is incremental (2 = Incremental) # 313 317 60/255 Database path # 376 620 4 \07 \07 \07 \07 # 380 624 4 Last transaction number # 384 628 4 Overlap factor (-io) # 391 635 1 Is compressed (-com) (2 = Enable) # 392 636 2 Redundancy (-red) # 396 640 4 Backup header CRC # 400 644 2 Database blocksize
Recent versions have the similar header.
Thank you sir. I was thinking the answer could indeed come from you
only the timestamp of the last incremental and the timestamp of the last full backup are remembered so it cant do as you wish because it does not know.
Gus, my question was not about a wish of mine, but how the prorest command could possibly know it, and it does indeed since it can raise warning 6774 when appropriate. As George said, prorest knows how to do it, based on this two pieces of info in the backup header itself:
# Progress backup header:
#
# V8 V9
# Offset Offset Len Description
# ------ ------ --- -----------
[...]
# 276 276 4 Incremental backup number
[...]
# 384 628 4 Overlap factor (-io)
Now, as you say, this kind of backup details is not (yet) recorded in the database. We have finally managed that in an additional history file aside the .db file.
in addition to the information in backup header, there is the information in the database master block. that has the incremental backup counters so prorest can compare the counter and overlap number in the backup header with the incremental number in the master block.
with no overlap, the counter in the backup must be 1 greater than the one in the master block.
with overlap, the value must be in the range:
master block counter + 1 to
master block counter + overlap + 1
example with overlap 3:
master backup
5 6
7
8
9