ONLINE BACKUP ERROR - Forum - OpenEdge RDBMS - Progress Community
 Forum

ONLINE BACKUP ERROR

This question is not answered

Hi all.

Progress 102B08

Linux Red Hat 64 bits

I'm having trouble running the online backup on a database with approximately 500GB.
No error appears, only says it ended in error.
I ran an idxcheck, and dbrpr and had no problems.
Even though running offline the error also occurs.

[2017/03/30@10:57:24.123-0300] P-108036     T-140533277878016 I BACKUP254: (-----) Login by progress.
[2017/03/30@10:57:24.247-0300] P-108036     T-140533277878016 I BACKUP254: (12850) Backup blocks will be written to /backup/bancos/ems5/srmov.bkp.
[2017/03/30@10:57:24.247-0300] P-108036     T-140533277878016 I BACKUP254: (1362)  Full backup started.
[2017/03/30@10:57:24.247-0300] P-108036     T-140533277878016 I BACKUP254: (6686)  59034980 active blocks out of 59222754 blocks in /dados/bancos/ems5/srmov will be dumped.
[2017/03/30@10:57:24.247-0300] P-108036     T-140533277878016 I BACKUP254: (6688)  20480 BI blocks will be dumped.
[2017/03/30@10:57:24.247-0300] P-108036     T-140533277878016 I BACKUP254: (9285)  Backup requires an estimated 451.2 GBytes of media.
[2017/03/30@10:57:24.247-0300] P-108036     T-140533277878016 I BACKUP254: (9286)  Restore would require an estimated 59136161 db blocks using 450.7 GBytes of media.
[2017/03/30@10:57:24.274-0300] P-108036     T-140533277878016 I BACKUP254: (3777)  Switched to ai extent /ai/ems5/srmov.a2.
[2017/03/30@10:57:24.274-0300] P-108036     T-140533277878016 I BACKUP254: (3778)  This is after-image file number 2 since the last AIMAGE BEGIN
[2017/03/30@10:57:25.290-0300] P-82685      T-139748999698176 I SRV    54: (739)   Logout usernum 768, userid kkuhn, on VDI-W10-FULL-11.
[2017/03/30@10:57:26.425-0300] P-108036     T-140533277878016 I BACKUP254: (5459)  Begin backup of Before Image file(s).
[2017/03/30@10:57:28.552-0300] P-108036     T-140533277878016 I BACKUP254: (5460)  End backup of Before Image file(s).
[2017/03/30@10:57:28.552-0300] P-108036     T-140533277878016 I BACKUP254: (5461)  Begin backup of Data file(s).

[2017/03/30@12:21:35.295-0300] P-108036     T-140533277878016 I BACKUP254: (5462)  End backup of Data file(s).
[2017/03/30@12:21:35.305-0300] P-108036     T-140533277878016 I BACKUP254: (1617)  Backup terminated due to errors.

All Replies
  • What is the final size of  srmov.bkp?

  • Hi George, aprox 264GB, after de error backups ends with 270GB aprox

  • What is your actual backup command?

    Are you perhaps reaching a maximum file size limit?  Or filling a filesystem?  You should check the system log files (probably /var/log/messages).

    --
    Tom Bascom
    tom@wss.com

  • Hi, Tom.

    Yes filesystem is enable for large files. (dabase largefile file enable).

    No erros in /var/log/messages.

    command

    probkup online srmov  /backup/bancos/ems5/srmov.bkp -com

  • You can add the -verbose option to the backup command. It will show you the blocks in database where backup is terminated. So you will be able to check carefully this part of database.

  • George,

    Backed up 56702140 db blocks in 01:36:30

    Backed up 56934922 db blocks in 01:36:40

    Backed up 57166741 db blocks in 01:36:50

    Backed up 57321728 db blocks in 01:37:00

    Backed up 57526398 db blocks in 01:37:10

    Backup terminated due to errors. (1617)

    You have new mail in /var/spool/mail/progress

    57526398  is a block problem?

  • Have you tried backing up to multiple extents?

    --
    Tom Bascom
    tom@wss.com

  • I agree with Tom - the issue seems to be related to the writes to a backup file.

    > 57526398  is a block problem?

    No. Backup was able to read almost the whole database: 57526398 blocks of 59034980 active blocks. Db blocksize seems to be equal 8K. Hence the size of backup file /should be/ at least 460 GB.

  • Another thing you can try is to rerun the backup with "-verbose" but without "-com". If it fails again, check the block number and the actual file size; and compare them with the results with "-com".

    If the whole db is backed up successfully, the one without "-com" should produce a much large file size. This also means something wrong with the compression in this case.

    If it fails at a point where block number is smaller but file sizes are similar, then it's probably an issue with writes to the backup file.

    If it fails at a point where block numbers are similar (should also have larger file size), then it's probably an issue with certain blocks after that block number.  

    Dapeng