backup and recovery best practice.

[Anon Anon]

Hi we are proposing a weekly backup using flashcopy and a max 7 day rollfoward for recovery purposes (around 150 journal extracts) to effect a disaster recovery if need be.

Would anyone have any similar setups or observations regarding this scenario (positives, pitfalls) for your organisation.

I need to sell this idea internally and am looking for other organisaitons and what they do.

We presently backup on the daily basis using hotbackup and we are trying to move to a less frequent procedure.

We know the process works in the time frames we need, its just that there is a lack of confidence in abandoning the daily process which has been in place for many many years.

Thanks

[Ivan Ulens]

We use this scenario.
We stop the CV, offloaded the journal, start the Flash Copy and restart the CV's. Afterwards we copy the Flash Copy Disks to Cartridges.

[Anon Anon]

HI thanks

Is this done on a daily or weekly basis?

Can I quote your organisation in a report if need be?

Thanks

[Ivan Ulens]

This is done on a weekly base.
There is no problem to reference to our organization.

[Anon Anon]

Hi Ivan, could you provide your organisation name, address and a suitable contact area. Thanks..

[Ivan Ulens]

Organization: CEGEKA NV
Address: Universiteitslaan 9 3500 Hasselt, Belgium
contact: [e-mail]

[richard.pierce1.1]

We are fortunate to have, in non-technical terms, a shadow drive system where the db files area “shadowed” on another drive.

When it is time for our daily backup, we:

1.) Vary the production db areas retrieval,

2.) “Cut” the connection to the shadow drives,

3.) Vary the production db areas back to update

4.) Back up the shadow drives

5.) Restore the connection to the shadow drives, which synchs up the shadow drives to the production.

6.) Continue on our merry way.

Total time production is “down” – about 5 minutes +/- .

Dick
Richard Pierce
[e-mail]<mailto:[e-mail]>
Office (new) [phone] Cell: [phone]
www.mass.gov/massdot<http://www.mass.gov/massdot>


From: CA IDMS (IUA EIUA) Global User Community [mailto:[e-mail]]
Sent: Monday, January 14, 2013 4:47 AM
To: [e-mail]
Subject: [DBA Issues - Open Forum] RE: backup and recovery best practice.

We use this scenario.
We stop the CV, offloaded the journal, start the Flash Copy and restart the CV's. Afterwards we copy the Flash Copy Disks to Cartridges.
Posted by:ivan.ulens1.1
--
CA Communities Message Boards
100027895
[e-mail]<mailto:[e-mail]>
https://communities.ca.com

[Anon Anon]

HI Dick,


Just of interest , do these "shadow drives" reside inside the same storage box??.., or they reside in a physically different place, perhaps offsite ?
Is this catch up a function of the reconnect procedure software, or do your need IDMS journals to sync everything..?

Thanks

[richard.pierce1.1]

1. The “shadow drives” are, I believe, in the same site as the regular drives.

2. No Journal catch-up necessary. It’s all handled by the device hardware/software.

3. We are in the process of building our own DR site where all of our disks will be connected by SRDF(?) hardware and again no Journal catch-up will be necessary – we should only loose, maximum, of 1 hour switching to the new site. When IDMS comes up, it should (others say it does) roll back properly and everything’s OK. Our business people are OK with the 1 hour of lost data.

Dick
Richard Pierce
[e-mail]<mailto:[e-mail]>
Office (new) [phone] Cell: [phone]
www.mass.gov/massdot<http://www.mass.gov/massdot>


From: CA IDMS (IUA EIUA) Global User Community [mailto:[e-mail]]
Sent: Wednesday, January 30, 2013 1:50 PM
To: [e-mail]
Subject: RE: [DBA Issues - Open Forum] RE: backup and recovery best practice.

HI Dick,


Just of interest , do these "shadow drives" reside inside the same storage box??.., or they reside in a physically different place, perhaps offsite ?
Is this catch up a function of the reconnect procedure software, or do your need IDMS journals to sync everything..?

Thanks
Posted by:acp
--
CA Communities Message Boards
100164099
[e-mail]<mailto:[e-mail]>
https://communities.ca.com

[Anon Anon]

A couple of things to consider:

1) Is the daily backup ever used to recover from batch processing errors?

2) If you do any local mode updating, including index rebuilds, do you journal those updates?

Kay Rozeboom
Information Technology Enterprise
Iowa Department of Administrative Services
Telephone: [phone] Fax: [phone]
Email: [e-mail]

From: CA IDMS (IUA EIUA) Global User Community [mailto:[e-mail]]
Sent: Friday, January 11, 2013 3:31 PM
To: [e-mail]
Subject: [DBA Issues - Open Forum] backup and recovery best practice.

Hi we are proposing a weekly backup using flashcopy and a max 7 day rollfoward for recovery purposes (around 150 journal extracts) to effect a disaster recovery if need be.

Would anyone have any similar setups or observations regarding this scenario (positives, pitfalls) for your organisation.

I need to sell this idea internally and am looking for other organisaitons and what they do.

We presently backup on the daily basis using hotbackup and we are trying to move to a less frequent procedure.

We know the process works in the time frames we need, its just that there is a lack of confidence in abandoning the daily process which has been in place for many many years.

Thanks
Posted by:acp
--
CA Communities Message Boards
100022972
[e-mail]<mailto:[e-mail]>
http://communities.ca.com

[Anon Anon]

Hi thanks

In response,

1) Is the daily backup ever used to recover from batch processing errors? - not in my recent memory (3 years) & since its a hotbackup it would need work to ensure integrity.

2) If you do any local mode updating, including index rebuilds, do you journal those updates? - this is not done as far as I can tell.. But the issue does remain that any form of restore would have to
be captured and redone.

3 ) One major issue is the fact that any upgrades performed over the week would have to be redone with the rollforward (reorgs, expand pages, restructures etc and whatever else was changed).
So this remains an issue to ensure these changes are recaptured..

4 ) During Disaster recovery we have changes send to offsite storage, however the last day would be missed since the changes would not have been sent to storage.. so if the failure occured on the same day as an upgrade, we accept that the upgrade needs to be reworked in the future , and the rollforward stopped at this point. . That applies to both a daily and weekly backup scenario.

[Anon Anon]

We do a bi-weekly flashcopy backup. We shutdown the CV, initiate the flash and restart the CV. When the flash completes, the copied volumes are backed up to tape for offsite storage. We do index rebuilds with MAINTAIN INDEX in local mode immediately after selected backups. We have automation in place to keep the segments where index rebuilds are running in retrieval when the CV is restarted after the flash. When you are at DR and restoring, you will have to run any index rebuilds which would have followed the backup before commencing a roll forward. The bi-weekly backup was chosen to reduce the time of a possible restore and roll-forward of a segment. We are running R17 SP1 under z\VSE.

[Anon Anon]

nigel.salway wrote:

We do a bi-weekly flashcopy backup. We shutdown the CV, initiate the flash and restart the CV. When the flash completes, the copied volumes are backed up to tape for offsite storage. We do index rebuilds with MAINTAIN INDEX in local mode immediately after selected backups. We have automation in place to keep the segments where index rebuilds are running in retrieval when the CV is restarted after the flash. When you are at DR and restoring, you will have to run any index rebuilds which would have followed the backup before commencing a roll forward. The bi-weekly backup was chosen to reduce the time of a possible restore and roll-forward of a segment. We are running R17 SP1 under z\VSE.

Hi Nigel, as you indicated you have to reapply any logical/physical changes at the DR site.. We plan to capture the last known physical images and repply them at the DR site..including the dictionaires etc.. from backup media.. to save rerunning processes unless absolutely there is no other way..Its bit complicated to reapply the changes but as you noted totenable the ROLLFORWARD to continue I think that the only way to do it.. otherwise the journals will be out of sync with the new logical/physical view.

We have had success in using EXTRACT files for each journal, and have been able to apply 7 days worth of journals in 20mins on a ROLLFORW mind you this is probably a small system I think ( extract stats indicates 11,000,000 input extract records).. Maybe this may help you in reducing the ROLLFORW timeframe.

[angela matsunaga]

Hi! Anon,
Did you have success on weekly backup using flashcopy and a max 7 day rollfoward for recovery purposes ?
Could you please share how was you using hotbackup ? e.g. Quiesce point, waas application abending  0966 or time out ?
Thanks in advance