Where I disagree is when you compare a "backup with air gap" to a "replicated copy". A replicated copy is corrupted at the same time that primary is corrupted. A "backup with air gap" is not. Now, can you create a "backup with air gap" on DASD - yes, I believe you can now. However, a "backup on DASD with air gap" means having the backup on expensive MF-DASD while "backup on virtual-tape" implies both the air-gap and usage of cheaper DASD. Plus, replicated virtual-tape means the air-gap backup is both a local copy and a remote copy.
Sorry, but for backups I still believe that tape is the superior solution. Now, granted the new HSM-archive to the cloud is wonderful and will further decrease the usage of tape in most data centers; but many of the production sites I have reviewed show that HSM-archive data is only about 25% of their overall tape usage. Still, a large chunk - no question. Russell -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, December 7, 2018 2:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS IMHO, the air gap for tape in ATL or even more for virtual tape is as (in)secure as copy on DASD. Disclaimer: I understand "air gap" as "physical separation" backup from the system, just to be sure the backup cannot be destroyed by human mistake or any other error. I hope I understood this idiom correctly. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-12-05 o 14:39, Russell Witt pisze: > So very true. And the concept of an "air-gap" backup has become a real issue > and shows one of the problems with replication. And nothing is better for an > "air-gap" backup than tape, including Virtual Tape. > > The other point is that while dasd-management products (HSM, FDR/ABR, > CA-Disk) are one of the biggest users, and together with backup-solutions > like DFDSS and FDR account for the majority of tape usage there are other > uses as well. I have seen some production sites where DB2 backups from the > DB2 utility use as much tape (measured in Mb of data) as either one. > > Russell Witt > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joel C. Ewing > Sent: Tuesday, December 4, 2018 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Another IBM tape not for z/OS > > On 12/02/2018 07:55 PM, Rugen, Len wrote: >> Batch tape should be dead, even if batch JCL still looks like tape is used. >> One of my last SMS projects was to manage tape, redirecting almost all to >> SMS disk. >> >> >> > Before employing any technique to convert all tape data sets to DASD, one > should I hope first consider whether replacing a tape data set with a DASD > data set is a reasonable act based on the application design. The one logical > capability of a tape data set, even one using virtual tape, that is not > normally associated with a DASD data set is the innate ability to continue > to exist for hours, days, or even longer after a new data set with identical > name has been created, depending on how tapes volumes are scratched. The > use of tape could mean the application is depending on that retention as an > implicit and essential part of recovery should programming errors or other > disasters occur during application processing, especially if the problem is a > subtle one that isn't caught immediately. Throwing out that capability > without providing a suitable substitute is something you may live to regret. > > Joel C. Ewing > > -- > ====================================================================== Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
