Disaster Recovery Site

[jennid]

Hi All-We are in the process of setting up a hot site at a remote location to be used in the event of a disaster at our local data center. Our database (ERP=Infor's SX.enterprise) is about 180 GB and is on an AIX machine (AIX version 5.3.0.0, OpenEdge version 10.0B05). We have after imaging enabled. What we would like to do is copy the after image files to the remote site as they are full. What I am unsure of is how to go about this in a way that won't cause the ai files to get out of sync. For example, if we create the database on the remote system on 2/1/10 and automatically copy the ai files from the production system to the remote system, won't the after image files get out of sync once the db on the production system gets backed up? We would prefer not to have to copy the 180 GB db or its backup files across the network to the remote system after every production backup. I've been poking around on Progress' support site and haven't found much useful info yet. Anyone know of any info I can read to develop a strategy around this?

Thanks in advance for the help.

Jenni
Jenni Detert
Manager of Application Development
Endries Intl Inc, A Ferguson Subsidiary

 

[RealHeavyDude]

You've noticed the most important thing: The time stamp the databse was last updated must be in sync between the after image and the database your want it to roll forward against.

• Offline backup: You must not do anything other than switch on the after image as soon as the backup is done because otherwise the time stamps will not match.
• Online backup: The database automatically switches to the next after image extent and it is guaranteed that the time stamps will match.

When you start the after image replication you must first restore the database on the disaster recovery site from a backup. After the database is restored you can then roll forward the after images as they come and you will always be in sync. But there's one rule: Don't touch the database on the disaster recovery site. As soon as you do anything other than rolling forward the latest after image extent, for example start the database server an do a report, the databases will be out of sync. As soon as the databases are out of sync there is no other way as to restore from backup and start the process again.

HTH, RealHeavyDude.

 

[TomBascom]

Making another backup does not disrupt the after-image sequence. It just causes an extent switch and adds another potential recovery point. For instance if you have backups from Monday, Tuesday and Wednesday along with all of the archived after-image logs and then you crash Thursday afternoon you can recover starting with any of those backups and the ai files from the selected backup point forward. (It is good to have multiple backups to pick from -- especially if they are on tape because tapes sometimes quietly go bad...)

If you have a "warm spare" running that was "seeded" with Monday's backup it will continue to run with after-image logs forever -- regardless of how many backups you make (ok, not quite "forever" -- there is a limit of 65535 on the sequence number, that's roughly 2 years if you switch extents every 15 minutes, you will probably dump & load or upgrade before you run into that). The warm spare will stop taking new ai logs if you open it by starting a "pro: or "mpro" session -- regardless of whether or not you update data. The mere act of starting a session is all that it takes. Certain utility commands may also result in the warm spare no longer taking ai logs.

SXE's default after-imaging scripts are annoying. They stop and restart after-imaging on Sundays. This is, of course, silly and pointless. It's pretty confusing too. Once you start after-imaging you should not stop it unless you are doing something very special (like dumping & loading or upgrading Progress...)

 

[jennid]

Maybe the SX scripts stopping and starting after imaging are my problem? (You are correct, the default scripts we are running stop and start after imaging). What I am seeing on our system currently is that after image extents are re-used after 7 days. Example:

Using the stnd sx scripts, we back up the db on 1/2/10 and after imaging is stopped/started. After image file nxt.1, nxt.2, nxt.3 etc... are moved to the ai save dir as they become full.

On 1/9/10, the SX scripts do a backup of the db and stop/start after imaging (we do have online backups running throughout the week as well). When that happens, the stnd SX scripts also remove any ai files from the ai save dir that are more than 7 days old.

Because nxt.1, nxt.2, etc... were more than 7 days old, they were removed and now the ai process creates new ai files with the same names....nxt.1, nxt.2, etc...

Am I understanding correctly then that if we remove the stop/start of after imaging from the SX scripts that we should be able to achieve the hot (warm) site as long as we don't start or truncate the remote db?

If so, I have a follow up question: My boss was talking to another SX user at a conference and they said that they had a process in place for their hot site where an automated process was regularly (more than daily) automatically rolling the ai forward so in the event they needed to use the hot site, all they would need to do was bring up the db....not go through the process of rolling forward hundreds or thousands of ai files. The user said that their data center was destroyed in a natural disaster and all they had to do was start up the db on the remote site with no rolling forward of the ai and the only data loss was the transactions that were in the last ai files that weren't full/moved to the remote site yet. I'm having trouble figuring out how one would do this. Thoughts?

Thanks,

Jenni

 

[TomBascom]

Yes, get rid of the default SXE stuff ASAP.

Yes, you can create such a "warm spare". Be aware though that if you do so you will need a "DR" license from Progress. That's 50% of the production license.

You could also implement OE Replication.

In general out of the box SXE is what I call a "target rich environment" for making dramatic improvements in performance and operations. If you need help I know an experienced consultant. Contact info below

 

[jennid]

I spoke with my boss and we do indeed have a DR license from Progress. We've explored OE Replication in the past and at this time aren't going that way for cost reasons.

So, with that in mind, how would one go about the "warm spare" option we've discussed....I understand how to copy the AI files over to the remote machine. But as for automating the rolling forward of the AI files on a regular basis (to avoid having to spend several hours rolling forward hundreds/thousands of files in the event we need the DR system), what's the best way to go about this?

Thanks.

 

[tamhas]

You might want to check with the Progress rep. As I recall, the replication license includes the DR license, so you might be able to trade your plain vanilla DR for replication without it being a big cost issue.