image copy validation

Mark McNary

image copy validation

I wondering if anyone could tell me if I am missing something.

At my organization, we have been tasked with 'proving' that our backups are valid. The common consensus seems to be that the image copy files would be used to restore the database, performing this validation. While that is 100% correct in validating that a particular file is usable as a basis for recovery, it ignores the fact that we cannot take the time to restore every image copy file to verify it.

Thus far, we have been able to stave off the auditors by using image copy files as the basis for unloads for data refreshing in non-prod. But sooner or later, they will circle back around and want us to be able to 'prove' that any given file is usable for recovery.

A solution that has been suggested is to perform the image copy as usual, then run a COPYTOCOPY utility to make another copy, thereby validating that the source file was at least readable, and therefore suitable for recovery. This would kill two birds, as it provides the necessary second copy as well as validating file integrity.

I am aware that there are many factors involved in recoverability beyond physical file corruption, and we are addressing those as well, but this is the current focus from the auditors and must be resolved first.

Thanx,

Mark McNary
Database Administrator III

======================================================================
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.
Attachments

  • image001.jpg (<1k)

Phil Grainger

image copy validation
(in response to Mark McNary)
Actually, most likely scenarios for a failed recovery are NOT likely to be because of unreadable copies

They are more likely to be MISSING image copes, missing archive logs or some other flavour of manual challenge/stupidity

Happy for others to correct me if this statement is oversimplifying

Most ISV recovery tools will be able to do a "recovery audit" to prove that all the pieces are PRESENT for recovery

BMC also does something called RECOVERY SIMULATION which does this audit and ALSO reads all the copies/logs to be 100% sure objects are recoverable - WITHOUT overwriting the target objects, of course
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: McNary, Mark [mailto:[login to unmask email]
Sent: 17 September 2018 18:59
To: [login to unmask email]
Cc: McNary, Mark <[login to unmask email]>
Subject: [DB2-L] - image copy validation

I wondering if anyone could tell me if I am missing something.

At my organization, we have been tasked with 'proving' that our backups are valid. The common consensus seems to be that the image copy files would be used to restore the database, performing this validation. While that is 100% correct in validating that a particular file is usable as a basis for recovery, it ignores the fact that we cannot take the time to restore every image copy file to verify it.

Thus far, we have been able to stave off the auditors by using image copy files as the basis for unloads for data refreshing in non-prod. But sooner or later, they will circle back around and want us to be able to 'prove' that any given file is usable for recovery.

A solution that has been suggested is to perform the image copy as usual, then run a COPYTOCOPY utility to make another copy, thereby validating that the source file was at least readable, and therefore suitable for recovery. This would kill two birds, as it provides the necessary second copy as well as validating file integrity.

I am aware that there are many factors involved in recoverability beyond physical file corruption, and we are addressing those as well, but this is the current focus from the auditors and must be resolved first.

Thanx,

Mark McNary
Database Administrator III
-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image002.jpg (8k)
  • image003.png (9.3k)

Jim Tonchick

image copy validation
(in response to Mark McNary)
You are not "missing" anything.  Welcome to the new world of nontechnical auditors working from scripts.  They deal with theoricical situations, and expect us to deliver the "proof" with nonbudgeted man hours and resources.
I've had auditors ask me for a list of user sign on ids and focus on my documentation of how I obtained the list (screen shots, job listings and commands) and not question which ids attempted to access data that they did not have privilage to access.  They were happy because they were able to check off a box on their script.

-----Original Message-----
From: McNary, Mark <[login to unmask email]>
To: [login to unmask email] <[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]>
Sent: Mon, Sep 17, 2018 03:08 PM
Subject: [DB2-L] - image copy validation


&lt;!-- #yiv1280579274 _filtered #yiv1280579274 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv1280579274 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv1280579274 {font-family:"Trebuchet MS";panose-1:2 11 6 3 2 2 2 2 2 4;} #yiv1280579274 #yiv1280579274 p.yiv1280579274MsoNormal, #yiv1280579274 li.yiv1280579274MsoNormal, #yiv1280579274 div.yiv1280579274MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 h1 {margin-top:12.0pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:16.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 h2 {margin-top:2.0pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:14.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;font-weight:normal;} #yiv1280579274 h3 {margin-top:2.0pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:13.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;font-weight:normal;} #yiv1280579274 h4 {margin-top:2.0pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:14.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;font-weight:normal;} #yiv1280579274 h5 {margin-top:2.0pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:13.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;font-weight:normal;} #yiv1280579274 h6 {margin-top:2.0pt;margin-right:0in;margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Trebuchet MS", sans-serif;color:#663300;font-weight:normal;} #yiv1280579274 a:link, #yiv1280579274 span.yiv1280579274MsoHyperlink {color:#990066;text-decoration:underline;} #yiv1280579274 a:visited, #yiv1280579274 span.yiv1280579274MsoHyperlinkFollowed {color:#CC6633;text-decoration:underline;} #yiv1280579274 span.yiv1280579274EmailStyle17 {color:#663300;} #yiv1280579274 span.yiv1280579274Heading1Char {font-family:"Trebuchet MS", sans-serif;color:#663300;font-weight:bold;} #yiv1280579274 span.yiv1280579274Heading2Char {font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 span.yiv1280579274Heading3Char {font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 span.yiv1280579274Heading4Char {font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 span.yiv1280579274Heading5Char {font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 span.yiv1280579274Heading6Char {font-family:"Trebuchet MS", sans-serif;color:#663300;} #yiv1280579274 .yiv1280579274MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered #yiv1280579274 {margin:1.0in 1.0in 1.0in 1.0in;} #yiv1280579274 div.yiv1280579274WordSection1 {} --&gt;
I wondering if anyone could tell me if I am missing something.

 

At my organization, we have been tasked with ‘proving’ that our backups are valid.  The common consensus seems to be that the image copy files would be used to restore the database, performing this validation.  While that is 100% correct in validating that a particular file is usable as a basis for recovery, it ignores the fact that we cannot take the time to restore every image copy file to verify it.

 

Thus far, we have been able to stave off the auditors by using image copy files as the basis for unloads for data refreshing in non-prod.  But sooner or later, they will circle back around and want us to be able to ‘prove’ that any given file is usable for recovery.

 

A solution that has been suggested is to perform the image copy as usual, then run a COPYTOCOPY utility to make another copy, thereby validating that the source file was at least readable, and therefore suitable for recovery.  This would kill two birds, as it provides the necessary second copy as well as validating file integrity.

 

I am aware that there are many factors involved in recoverability beyond physical file corruption, and we are addressing those as well, but this is the current focus from the auditors and must be resolved first.

 

Thanx,

 

Mark McNary

Database Administrator III
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.

Attachment Links: image001.jpg (1 k)  
Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription  

This email has been sent to: [login to unmask email]
Faster data refresh is here! The long waits and babysitting of unload/load jobs is over. Contact
ESAi to learn about BCV5 & XDM. Be a hero to users with fast on-demand test/QA data provisioning.See
http://www.ESAIGroup.com/idug



Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2

Mark McNary

image copy validation
(in response to Mark McNary)
You are correct in you assessment of what actually influences the recoverability of a DB2 system. I feel that if we to experience a disaster requiring a full DB2 recovery, we would be up and running well within our RTO and RPO parameters.

However, the auditors have read a book from 1998 that says that file corruption in a backup file prevents recovery and so they are concentrating on that aspect of the process. Hence my question concerning whether or not performing a COPYTOCOPY utility on an existing image copy would be considered a validation of the file.

Thanx,

Mark McNary
Database Administrator III

From: Grainger, Phil [mailto:[login to unmask email]
Sent: Monday, September 17, 2018 3:18 PM
To: [login to unmask email]
Cc: McNary, Mark <[login to unmask email]>
Subject: RE: image copy validation

This is an EXTERNAL email. Do not open attachments or click on links unless you have confirmed the identity of the sender.
________________________________
Actually, most likely scenarios for a failed recovery are NOT likely to be because of unreadable copies

They are more likely to be MISSING image copes, missing archive logs or some other flavour of manual challenge/stupidity

Happy for others to correct me if this statement is oversimplifying

Most ISV recovery tools will be able to do a "recovery audit" to prove that all the pieces are PRESENT for recovery

BMC also does something called RECOVERY SIMULATION which does this audit and ALSO reads all the copies/logs to be 100% sure objects are recoverable - WITHOUT overwriting the target objects, of course
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]<mailto:[login to unmask email]>

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: McNary, Mark [mailto:[login to unmask email]
Sent: 17 September 2018 18:59
To: [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: [DB2-L] - image copy validation

I wondering if anyone could tell me if I am missing something.

At my organization, we have been tasked with 'proving' that our backups are valid. The common consensus seems to be that the image copy files would be used to restore the database, performing this validation. While that is 100% correct in validating that a particular file is usable as a basis for recovery, it ignores the fact that we cannot take the time to restore every image copy file to verify it.

Thus far, we have been able to stave off the auditors by using image copy files as the basis for unloads for data refreshing in non-prod. But sooner or later, they will circle back around and want us to be able to 'prove' that any given file is usable for recovery.

A solution that has been suggested is to perform the image copy as usual, then run a COPYTOCOPY utility to make another copy, thereby validating that the source file was at least readable, and therefore suitable for recovery. This would kill two birds, as it provides the necessary second copy as well as validating file integrity.

I am aware that there are many factors involved in recoverability beyond physical file corruption, and we are addressing those as well, but this is the current focus from the auditors and must be resolved first.

Thanx,

Mark McNary
Database Administrator III
-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.

======================================================================
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.
Attachments

  • image001.jpg (8k)
  • image002.png (9.3k)

Phil Grainger

image copy validation
(in response to Mark McNary)
COPYTOCOPY will indeed prove that the copy is READABLE

But that may not imply that the table is recoverable from the copy - a lot of other things are in play (such as "was the copy made at the same version as the table")

If you want to help audit put tick in their box, then COPYTOCOPY is fine

So long as you understand that this doesn't necessarily mean what they think it means
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: McNary, Mark [mailto:[login to unmask email]
Sent: 18 September 2018 15:10
To: Grainger, Phil <[login to unmask email]>; [login to unmask email]
Cc: McNary, Mark <[login to unmask email]>
Subject: RE: image copy validation

You are correct in you assessment of what actually influences the recoverability of a DB2 system. I feel that if we to experience a disaster requiring a full DB2 recovery, we would be up and running well within our RTO and RPO parameters.

However, the auditors have read a book from 1998 that says that file corruption in a backup file prevents recovery and so they are concentrating on that aspect of the process. Hence my question concerning whether or not performing a COPYTOCOPY utility on an existing image copy would be considered a validation of the file.

Thanx,

Mark McNary
Database Administrator III

From: Grainger, Phil [mailto:[login to unmask email]
Sent: Monday, September 17, 2018 3:18 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: RE: image copy validation

This is an EXTERNAL email. Do not open attachments or click on links unless you have confirmed the identity of the sender.
________________________________
Actually, most likely scenarios for a failed recovery are NOT likely to be because of unreadable copies

They are more likely to be MISSING image copes, missing archive logs or some other flavour of manual challenge/stupidity

Happy for others to correct me if this statement is oversimplifying

Most ISV recovery tools will be able to do a "recovery audit" to prove that all the pieces are PRESENT for recovery

BMC also does something called RECOVERY SIMULATION which does this audit and ALSO reads all the copies/logs to be 100% sure objects are recoverable - WITHOUT overwriting the target objects, of course
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]<mailto:[login to unmask email]>

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: McNary, Mark [mailto:[login to unmask email]
Sent: 17 September 2018 18:59
To: [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: [DB2-L] - image copy validation

I wondering if anyone could tell me if I am missing something.

At my organization, we have been tasked with 'proving' that our backups are valid. The common consensus seems to be that the image copy files would be used to restore the database, performing this validation. While that is 100% correct in validating that a particular file is usable as a basis for recovery, it ignores the fact that we cannot take the time to restore every image copy file to verify it.

Thus far, we have been able to stave off the auditors by using image copy files as the basis for unloads for data refreshing in non-prod. But sooner or later, they will circle back around and want us to be able to 'prove' that any given file is usable for recovery.

A solution that has been suggested is to perform the image copy as usual, then run a COPYTOCOPY utility to make another copy, thereby validating that the source file was at least readable, and therefore suitable for recovery. This would kill two birds, as it provides the necessary second copy as well as validating file integrity.

I am aware that there are many factors involved in recoverability beyond physical file corruption, and we are addressing those as well, but this is the current focus from the auditors and must be resolved first.

Thanx,

Mark McNary
Database Administrator III
-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
________________________________
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image001.jpg (8k)
  • image003.png (9.3k)
  • image004.png (9.3k)

Mark McNary

image copy validation
(in response to Mark McNary)
At this point, I am just looking for a way to tell the auditors that the file is readable, and therefor potentially usable for a recovery.

Our auditors LOVE reports, and I can produce a report from the job that shows that the database was backed up AND the files validated, which checks off TWO boxes. I win.

Thanx,

Mark McNary
Database Administrator III
Enterprise Technology Services
UMB Bank
1008 Oak Street
Kansas City, MO 64106
816.860.1934 Office
314.497.5850 Mobile
816.860.3182 Fax
[login to unmask email]
http://www.umb.com
Count on more.

From: Grainger, Phil [mailto:[login to unmask email]
Sent: Tuesday, September 18, 2018 9:34 AM
To: McNary, Mark <[login to unmask email]>; [login to unmask email]
Subject: RE: image copy validation

This is an EXTERNAL email. Do not open attachments or click on links unless you have confirmed the identity of the sender.
________________________________
COPYTOCOPY will indeed prove that the copy is READABLE

But that may not imply that the table is recoverable from the copy - a lot of other things are in play (such as "was the copy made at the same version as the table")

If you want to help audit put tick in their box, then COPYTOCOPY is fine

So long as you understand that this doesn't necessarily mean what they think it means
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]<mailto:[login to unmask email]>

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: McNary, Mark [mailto:[login to unmask email]
Sent: 18 September 2018 15:10
To: Grainger, Phil <[login to unmask email]<mailto:[login to unmask email]>>; [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: RE: image copy validation

You are correct in you assessment of what actually influences the recoverability of a DB2 system. I feel that if we to experience a disaster requiring a full DB2 recovery, we would be up and running well within our RTO and RPO parameters.

However, the auditors have read a book from 1998 that says that file corruption in a backup file prevents recovery and so they are concentrating on that aspect of the process. Hence my question concerning whether or not performing a COPYTOCOPY utility on an existing image copy would be considered a validation of the file.

Thanx,

Mark McNary
Database Administrator III

From: Grainger, Phil [mailto:[login to unmask email]
Sent: Monday, September 17, 2018 3:18 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: RE: image copy validation

This is an EXTERNAL email. Do not open attachments or click on links unless you have confirmed the identity of the sender.
________________________________
Actually, most likely scenarios for a failed recovery are NOT likely to be because of unreadable copies

They are more likely to be MISSING image copes, missing archive logs or some other flavour of manual challenge/stupidity

Happy for others to correct me if this statement is oversimplifying

Most ISV recovery tools will be able to do a "recovery audit" to prove that all the pieces are PRESENT for recovery

BMC also does something called RECOVERY SIMULATION which does this audit and ALSO reads all the copies/logs to be 100% sure objects are recoverable - WITHOUT overwriting the target objects, of course
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]<mailto:[login to unmask email]>

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: McNary, Mark [mailto:[login to unmask email]
Sent: 17 September 2018 18:59
To: [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: [DB2-L] - image copy validation

I wondering if anyone could tell me if I am missing something.

At my organization, we have been tasked with 'proving' that our backups are valid. The common consensus seems to be that the image copy files would be used to restore the database, performing this validation. While that is 100% correct in validating that a particular file is usable as a basis for recovery, it ignores the fact that we cannot take the time to restore every image copy file to verify it.

Thus far, we have been able to stave off the auditors by using image copy files as the basis for unloads for data refreshing in non-prod. But sooner or later, they will circle back around and want us to be able to 'prove' that any given file is usable for recovery.

A solution that has been suggested is to perform the image copy as usual, then run a COPYTOCOPY utility to make another copy, thereby validating that the source file was at least readable, and therefore suitable for recovery. This would kill two birds, as it provides the necessary second copy as well as validating file integrity.

I am aware that there are many factors involved in recoverability beyond physical file corruption, and we are addressing those as well, but this is the current focus from the auditors and must be resolved first.

Thanx,

Mark McNary
Database Administrator III
-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
________________________________
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.

======================================================================
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.
Attachments

  • image001.jpg (8k)
  • image002.png (9.3k)
  • image003.png (9.3k)

Alan Gredell

RE: image copy validation
(in response to Mark McNary)

In my experience, auditors don't require that you validate every single backup made.  We wrote a script, I forget if we run it on DEV, or maybe on PROD (using a table specifically designed for the purpose), that proves via SELECT, COPY, UPDATE, SELECT, RECOVER, SELECT that the data IS updated, and that the RECOVERY step puts it back in it's original state.  One small test proves that the DB2 process is valid and working, and that suffices for all audit requirements.

David Baldon

image copy validation
(in response to Mark McNary)
Hmm, relying on a recovery book from 1998. Is there any chance these comments were made in a chapter dealing with hardware copies? Are you making hardware base copies? If not, HW errors wouldn't apply to you. At any rate IBM has implemented lots of changes to improve reliability. What version of Db2 will this validation be performed on?

Back to Phil's comment (I think he meant the COPY IMAGECOPY command) "COPYTOCOPY will indeed prove that the copy is READABLE" is quite true.
However, when the source copy is being made there are several different levels of sanity checking that you can select to ensure that the copy is actually usable to perform a RECOVER from. What that means is that copy made from a copy with a "high" level of checking would also be usable to the same degree and there is additional sanity checking done of the image copy when using the COPY IMAGECOPY command. So this isn't a simple byte-by-byte file copy.

As always one must weigh the cost of error checking and decide if the cost is justified. Often times it comes down to management (above the DBA) discussing it and making the decision the DBA follows even if it isn't your fault when copies start taking "too long".

Hope this helps.

...David

From: McNary, Mark [mailto:[login to unmask email]
Sent: Tuesday, September 18, 2018 9:10 AM
To: Grainger, Phil <[login to unmask email]>; [login to unmask email]
Cc: McNary, Mark <[login to unmask email]>
Subject: [DB2-L] - RE: image copy validation

You are correct in you assessment of what actually influences the recoverability of a DB2 system. I feel that if we to experience a disaster requiring a full DB2 recovery, we would be up and running well within our RTO and RPO parameters.

However, the auditors have read a book from 1998 that says that file corruption in a backup file prevents recovery and so they are concentrating on that aspect of the process. Hence my question concerning whether or not performing a COPYTOCOPY utility on an existing image copy would be considered a validation of the file.

Thanx,

Mark McNary
Database Administrator III

From: Grainger, Phil [mailto:[login to unmask email]
Sent: Monday, September 17, 2018 3:18 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Cc: McNary, Mark <[login to unmask email]<mailto:[login to unmask email]>>
Subject: RE: image copy validation

This is an EXTERNAL email. Do not open attachments or click on links unless you have confirmed the identity of the sender.
________________________________
Actually, most likely scenarios for a failed recovery are NOT likely to be because of unreadable copies

They are more likely to be MISSING image copes, missing archive logs or some other flavour of manual challenge/stupidity

Happy for others to correct me if this statement is oversimplifying

Most ISV recovery tools will be able to do a "recovery audit" to prove that all the pieces are PRESENT for recovery

BMC also does something called RECOVERY SIMULATION which does this audit and ALSO reads all the copies/logs to be 100% sure objects are recoverable - WITHOUT overwriting the target objects, of course
-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
-----End Original Message-----