Question Using -red With Probkup.

ron

Member
OE 10.1C (moving to 11.6 next March.)
Solaris 10

We have multiple production DBs, totaling about 2.3 TB. At present they are backed-up using probkup online - to disc files - and later those files are copied to tape.

The existing scripts specify "-red 9". I understand what the "-red" does but when the output is to RAID 10 storage I rather doubt that "-red" is needed at all - and if it is used I would choose something like "-red 200". By using "-red 9" we are bloating our backup files by about 11%.

What do others think?

Ron.
 

TheMadDBA

Active Member
Everything is a trade off when it comes to backups and performance and errors can still happen (reading or writing). That being said... I haven't use -red in probably 20 years. Assuming you are testing restores and AI roll forwards on a regular basis you should be fine without -red.

Any potential issue is likely to be related to the tape backup itself.. depending on what commands/software is being used you could have some pretty astonishing error rates when writing to tape. Some form of CRC and redundancy needs to happen with the actual tape backup.
 

ron

Member
I appreciate the reliability issues with tape and I'd never write a probkup to tape without including redundancy with -red - although even then I wouldn't choose a value as low as 9 for -red; maybe 50 to 100.

If a backup goes to disc - and then to tape, I wonder whether adding redundancy to the disc backup file actually helps at all when it later goes to tape. Whatever software manages the writing and reading to tape would not "know" about the redundancy in the backup file - because it just sees "a file".

So I come back to the original question - if probkups are written to disc files in a RAID 10 environment - does -red help at all? Or is it just a waste of time and file space?

Ron.
 

cj_brandt

Active Member
I agree with MadDBA, have a process to restore backups from disk and apply an AI or 2 on occasion and drop red, probkup is slow enough already.

I haven' t used probkup for a db larger than 50gb in several years, proquiet and then the SAN tools to get our backups is so much faster and less impact on db.
 

TheMadDBA

Active Member
My point was... although -red is mostly useless when writing with probkup to disk. The concept of CRC blocks and redundancy when writing to tape is still very valid. Tapes are fragile things and the last thing you need is a useless backup.

It really doesn't matter if your probackup file is 100% correct on disk if you have tape block errors because of bad media.
 

TomBascom

Curmudgeon
Agreed.

It's pretty unusual for anyone to actually write a probkup directly to tape these days. I cannot recall the last time I saw someone do that.
 

Cringer

ProgressTalk.com Moderator
Staff member
Tentatively puts hand in the air... I saw it a couple of years ago. Got it changed pretty quick.
 

ron

Member
Thanks for the replies - it's always very helpful getting multiple opinions, especially in the domain of DBA, because "the World is on your shoulders".

I don't see any real variation in opinion. It seems that the consensus is:

* Writing probkup files to disc is so reliable (especially with a good RAID system) that specifying -red is useless.
* Writing probkup to tape is not reliable - therefore specifying -red is "essential".

However - if I write a probkup file to disc - then write it to tape - I am not sure whether -red actually achieves anything. It will create redundant blocks in the file but writing the file to tape and reading it back will not be done by a Progress program. In my (unfortunately) extensive experience with tapes is that if there is a bad read you generally end-up with irrepairable rubbish where adjacent blocks get merged or missed. I would be really surprised if prorest would be able to make any sense out of the situation - with or without redundant blocks.
 

TheMadDBA

Active Member
I think we are going in a bit of a circle here :) Writing to tape in general is not reliable.

- In your exact scenario (probkup to disk then copying those files to tape) -red makes no sense at all.
- Depending on your OS, backup software and tape drive model you do have a variety of options (that have nothing to do with probkup) to make the tape more reliable by using CRC, logical block checking, duplicate blocks, etc.
 

pinne65

Member
LOL - just came across this thread and remembered that our backup script uses a 1/10 redundancy. We backup to SAN so I quickly bumped it to 1/200. But I'd like to keep it since we verify with crc check.

I'm thinking the crc would be faster than the block to block verification, or?

CJ, if I may ask, what strategy / tools are you using for your SAN backups. We are using both Zerto and Veeam for full vm backups and cloning, but we still run an online progress backup, just to have as many recovery options as possible.

With so much other activity on the backup SAN the progress backup has been getting slower and slower. Remains to see how much lowering the red factor will help in this case.
 

pinne65

Member
Lowering the red by a factor of 20 made no difference to the time the backup took. It took a little bit less disk space but that difference is negligable in our environment.
 

cj_brandt

Active Member
Funny - Zerto is now being used as well.

proquiet the db at night before batch processing begins.
I think we snooze a minute here
OS Snap of database using SAN tools.
proquiet disable

OS Snap of database is restored once a week and AI's are applied to make sure db backup is valid.

this process has been used nightly for years against multiple dbs.

important - you will need to use the aisequence option of proutil to update the AI Sequence number if you stop using probkup. There is a kb article about this.
 
Top