ONLINE BACKUP ERROR

Posted by claudemir_santos on 05-Apr-2017 10:00

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

Posted by George Potemkin on 05-Apr-2017 10:09

What is the final size of  srmov.bkp?

Posted by claudemir_santos on 05-Apr-2017 10:13

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

Posted by ChUIMonster on 05-Apr-2017 10:16

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).

Posted by claudemir_santos on 05-Apr-2017 10:26

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

Posted by George Potemkin on 05-Apr-2017 10:31

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.

Posted by claudemir_santos on 05-Apr-2017 13:22

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?

Posted by ChUIMonster on 05-Apr-2017 13:36

Have you tried backing up to multiple extents?

Posted by George Potemkin on 05-Apr-2017 13:46

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.

Posted by Dapeng Wu on 05-Apr-2017 14:37

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

This thread is closed