Veritas Backups on Unix... oh My!!

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
jdmiceli
Premium Member
Premium Member
Posts: 309
Joined: Wed Feb 22, 2006 10:03 am
Location: Urbandale, IA

Veritas Backups on Unix... oh My!!

Post by jdmiceli »

Hello all!

We are preparing to implement our DataStage environment on AIX Unix. We have been doing initial development on a Windows server, but our licenses and everything have come through and one of the Unix boxes is done, so here comes the switch.

What I am looking for here is any pitfalls we need to take into consideration as we set this system up, beginning with our backup strategy. Currently, our corporation utilizes Veritas Tape Backup enterprise wide for backing up the servers. I searched for stuff in DSXchange, but found little to work with. What I did find does not look real fun when backing up DS using Veritas.

My concern is that when we start processing, we already have a bunch of teams that are gearing up for utilizing DS to process data at night. My team will be using a unified series of jobs that process 14 different companies into a data repository (hurrah for parameters! :lol: ) I will be processing over 200 tables nightly by differential with multiple history rows possible per run for each company, and that's just my project. I expect nightly processing to take most of the night for everyone's processes.

The problem comes in at backup time. Veritas backups just hammer the drives and if something is still running, it all drops to the speed of an anvil crawling uphill. I also read that we would have to do something to DataStage before running the backup. I'm looking for more information about this if possible:

1. What needs to be done to safely back up the DataStage directories and the working directories?
2. Can the backups be done while still processing? I would think this would be a resounding 'No' just because the backups may be invalid.
3. Is there an established procedure fitting a similar set up someone/some company is using successfully that we can learn from?
4. I'm sure I'll think of more questions later on this...

As always, thanking you in advance for your help and expertice :D

Bestest!
Bestest!

John Miceli
System Specialist, MCP, MCDBA
Berkley Technology Services


"Good Morning. This is God. I will be handling all your problems today. I will not need your help. So have a great day!"
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

There is a SUSPEND.FILES command (only in the UV account and only for Administrator login) that can be used to quiesce the Repository databases. That handles any connected developers.

Running jobs, though, are a different story entirely. They *should* hang the first time they try to update their status into a quiesced Repository but, even so, the dynamic hashed file header information is in shared memory and not flushed back to disk, so would be inconsistent on the backup.

Best practice, therefore, is to manage the timing of job execution so that none is running when the backups are taken, and to disconnect any connected clients.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
kcbland
Participant
Posts: 5208
Joined: Wed Jan 15, 2003 8:56 am
Location: Lutz, FL
Contact:

Post by kcbland »

Ahhh, an enterprise scheduler would be handy to coordinate things. :wink:
Kenneth Bland

Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Post Reply