Backup advise

Hi,

We are currently using LTO4 with AIX 6 backup scripts to do our offline database backup. A idea pop up to backup to extra space in SAN so the DB can be up asap as compare the slow backup to Tape. However, the backup command in AIX does not allow backup to a disk/vg. Just wonder any better idea to shorten the backup time ?

We are not using probkup. Our system admin is not familiar with Progress.
 

RealHeavyDude

Well-Known Member
You don't tell anything about the Progress/OpenEdge version you are running.

Anyway, Progress provides a backup utility that allows you to backup the database off- or online. And I think most of us would recommend you to use the Progress backup utility to backup the database to a file system - backing up directly to a tape device is, IMHO of course, is not state-of-the-art anymore considering how cheap disk space is. Plus, you don't need to restore from tape because the last backup should be readily available in the file system if it is on a SAN.

Heavy Regards, RealHeavyDude.
 

TomBascom

Curmudgeon
I agree with RHD. Use probkup to disk. Then let the SA do whatever he likes to get it on tape.

Assuming that you have a filesystem that supports large files:

probkup online dbName /path/to/lots/of/disk/space/dbName.pbk -com

(If you have an ancient, obsolete and unsupported release of Progress that is limited to 2GB files you might need to create many backup "extents". But with large files you can just create the single .pbk file...)
 

tamhas

ProgressTalk.com Sponsor
I'm a little surprised Tom didn't say this first, but I *strongly* suggest that, whatever you do, switch to using probkup. Probkup to disk is a great idea and then as convenient, run that to tape to take off site or whatever. You will be shocked at how much faster this is.
 

TomBascom

Curmudgeon
I'm not quite sure why you don't think that I said that... 2nd sentence. The post right above your post ;) RHD said it too.
 

tamhas

ProgressTalk.com Sponsor
It just didn't seem as forcefully said as I would normally expect you to say it! :)
 
Thanks everyone for the quick update.

We are still on 9.1E04 .
Yeah, I was thinking about probkup too. Ran a quick test last night on a 25GB DB online took 11 mins. Large file is working fine too.

Will you run "compress" or "Gzip" on the pbk file before going to tape ?
 

RealHeavyDude

Well-Known Member
Of course you can zip your backup file, but the probkup command also provides an option to compress while creating the backup (-com). IMHO you should think about a disaster recovery strategy which should be centered around to questions:


  • How much data can you afford to loose?
  • How long can the system be down?
.
Then develop a strategy which is sufficient to be compliant with those requirements. Plus, compressing and decompressing the backup are additional steps that bring additional complexity and additional time needed to recover into your strategy. You should also take into account that the disaster might happen just when you are not around - so please, document your disaster backup strategy well. And, last but not least, test, test, test and test it.

And, as already mentioned time and time again, implement After Image.
Heavy Regards, RealHeavyDude.
 

TomBascom

Curmudgeon
The -com option to probkup eliminates empty space in the backup. But it does not compress in the sense that "zip" does.

In my experience you get very good reduction in file size from zipping. It comes out about the same whether you use -com on the probkup or not.

However -- I use -com anyway because it reduces the number of IO ops required to make the backup which, in theory anyway, should speed things up a bit.

Ideally I'd like to see Progress build "zip" style compression into probkup. We bring it up at every "info exchange" and any other chance we get ;)
 

lonegroover

New Member
I'm about to implement some sort of backup strategy myself this is very welcome advice. I do intend to use hard disk space, possibly to a network-mounted filesystem overnight.

I hope I can be forgiven for appending a supplementary question to someone else's thread, but: what would the command line incantation be to perform an incremental backup, assuming that's possible?

Is there a way to direct the backup output to stdout rather than a file? If there is, then you can do the gzip thing inline without having to compress in a second step.

I'm on:

OpenEdge Release 10.1C04


Finally - how to restore from a backup? Grateful if someone could point me in the direction of some information about that.

Thanks,
James
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I'm about to implement some sort of backup strategy myself this is very welcome advice. I do intend to use hard disk space, possibly to a network-mounted filesystem overnight.

I hope I can be forgiven for appending a supplementary question to someone else's thread, but: what would the command line incantation be to perform an incremental backup, assuming that's possible?

It is possible to do incrementals with probkup, however I wouldn't start with the software's capabilities. I think the first step should be devising a strategy that meets your business needs. Then look at the technology and its capabilities to determine how best to (or whether you can) implement your strategy. For example, two important metrics in business continuity are (a) how much data can you afford to lose (i.e. time elapsed/data changed the time of from your last recoverable change to the time of failure, aka "Recovery Point Objective"), and (b) how long you can afford to wait from the time of failure until time of recovery, aka "Recovery Time Objective". Obviously you want to minimize both but nothing comes for free. There was a good session on this topic at Progress Revolution 2011, with Brian Bowman, Adam Backman, Rob Marshall, and Mike McMahon: http://download.psdn.com/media/revolution_2011/oe11/OE1102.wmv.

Like I said, you can do incremental backups in addition to full backups, but that approach may not be best for your needs, especially if your application is performance-sensitive. I had a client whose OLTP performance was mysteriously tanking every afternoon at 14:00. It turned out they were running an automated online backup every afternoon. Incrementals could have a similar impact, especially if you did them often. I suggest you look into OpenEdge Replication/Replication Plus (which is an extra-cost product) and after-imaging (which is a built-in database feature and should be enabled in any production environment). You can read about AI in the Database Admin manual that Tom pointed out, as well as in a presentation he created on the subject: (PDF) (video). AI can give you the recovery capability you want from incrementals, without the impact of frequent backups. Also, read about the After-Image File Management Daemon (AIMD), which helps AI extent management.

Is there a way to direct the backup output to stdout rather than a file? If there is, then you can do the gzip thing inline without having to compress in a second step.

I've never tried that, but it's not much work to add an extra line to your backup script to gzip the backup file. Typically you do this overnight so it shouldn't matter much whether it's one step or two (in a script).
 

tamhas

ProgressTalk.com Sponsor
I should also note that some people are attracted by incrementals in the belief that they will take a lot less time than a full. In the days when the DB was on what is now a relatively slow disk and the backup speed was limited by the speed of the tape device, this made some sense. Now, however, one tends to be doing fast disk to fast disk and, if a tape or other offline storage is involved at all, it is not only way faster but the time it takes is off line from what impacts the DB. An incremental still needs to *read* the whole DB ... there is no magic audit trail that only backs up what is changed (although there are strategies based on after image where that is exactly what is doing), so an incremental disk to disk backup can take nearly as long as a disk to disk full backup because the limit is based on how long it takes to read the whole DB. If that is the case, why mess with incremental because restoring from a full backup will be faster and easier.

Which said, you can't really fully decide on a backup strategy without considering after-imaging.
 
Hi all,

Here's some testing benchmark for our online backup.
Backup 22GB of data online to a new SATA array took about 22mins. ( probkup online db backup.pbk -com). Is that acceptable or slow ? I would assume that backup is I/O intensive, how about CPU ?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
It's not horrible; I've seen comparable times for DBs that size. What type of array is it? Is it direct-attached storage? As for how intensive a probkup is, that is what a "testing benchmark" should tell you. Watch your CPU utilization and I/O bandwidth usage during a backup and get some numbers.

Also, a definition of "intensive" is related to your business needs. A database supporting a business-hours application can spin the CPUs and disks as much as it wants, but if it runs at midnight when the application isn't being used then there is no impact. On the other hand if you run a 24/7/365 OLTP system then your definition of "intensive" is more stringent. Ultimately, I think you have to use your test application and try to simulate a production workload and see if there is any meaningful impact while a backup runs (again, if you intend to use it during backups).
 
Top