Re: Storage & tape question
On 7/13/20 5:25 AM, Joe Monk wrote: My point is, once you rent that computer and put your stuff on it, it is no longer "someone else's computer". It is now YOUR computer. YOU are responsible for it. My understanding is that union of the computer owner(s) /and/ the contracted user(s) are collectively culpable for things that happen on the computer. Where the division lies between the two groups is highly dependent on the contract between them. But I don't believe that the computer owner(s) are absolved of any and all responsibility. I believe that some responsibility / culpability remains with the owner(s). -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
t;> > >>>> > >>>> W dniu 09.07.2020 o 16:22, Joe Monk pisze: > >>>>> Im sure that Kim Dotcom would love your legal theory... > >>>>> > >>>>> Joe > >>>>> > >>>>> On Thu, Jul 9, 2020 at 7:51 AM R.S. > >>>> wrote: > >>>>>> Azure? Cloud? > >>>>>> There is no cloud. It is just someone else's computer. ;-) > >>>>>> > >>>>>> -- > >>>>>> Radoslaw Skorupka > >>>>>> Lodz, Poland > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> W dniu 08.07.2020 o 17:46, Joe Monk pisze: > >>>>>>> I do a backup to spinning storage, then a copy of that backup to > >> Azure > >>>>>> for > >>>>>>> long term. > >>>>>>> > >>>>>>> Joe > >>>>>>> > >>>>>>> On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz > >> wrote: > >>>>>>>> I've always gone with dual* backups, with one copy off site. > Remote > >>>>>>>> mirroring is a good option where policy permits, and even if > >>>>>> retensioning > >>>>>>>> is no longer relevant, rereading backups periodically will give > you > >> a > >>>>>> heads > >>>>>>>> up if one copy goes south. I would consider even correctable > errors > >> to > >>>>>> be > >>>>>>>> red flags. > >>>>>>>> > >>>>>>>> Any medium you use will have failure modes. > >>>>>>>> > >>>>>>>> Multiple PiT recovery is good for "whoops!" moments and possibly > for > >>>>>>>> audits. > >>>>>>>> > >>>>>>>> Large or small, each shop must do it's own risk assessments in the > >>>>>> context > >>>>>>>> of its own obligations and priorities. > >>>>>>>> > >>>>>>>> * Depending on the value of the data, you might want more than 2. > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Shmuel (Seymour J.) Metz > >>>>>>>> http://mason.gmu.edu/~smetz3 > >>>>>>>> > >>>>>>>> > >>>>>>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >>>>>> behalf > >>>>>>>> of Bill Ogden [og...@us.ibm.com] > >>>>>>>> Sent: Wednesday, July 8, 2020 9:27 AM > >>>>>>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>>>>>> Subject: Re: Storage & tape question > >>>>>>>> > >>>>>>>> Probably many others will chime in on this. I have lost RAID 5 > >> arrays > >>>>>> with > >>>>>>>> two disk failures within an hour of each other. RAID is nice, but > >> one > >>>>>> must > >>>>>>>> allow for failures. > >>>>>>>> > >>>>>>>> Long ago I was involved with reading archived tapes and > transferring > >>>> the > >>>>>>>> data to CDs. The programs involved were home-written and the > project > >>>>>> ended > >>>>>>>> up going nowhere. However, we discovered that tapes kept too long > >>>>>> started > >>>>>>>> having errors. (At that point, for the CD copy, we just logged the > >>>> error > >>>>>>>> and accepted the corrupt data; what else could we do?) How long is > >>>> "too > >>>>>>>> long"?? It was variable, but measured in a few years. The advice > >> then > >>>>>> was > >>>>>>>> to minimally read the tapes every year or so to "retension" them. > >>>> Don't > >>>>>>>> know if this would apply to more modern tape media. (We also > >>>> discovered > >>>>>>>> that locally "burned" CDs are not expected last forever.) > >>>>>>>> > >>>>>>>> IMHO, the key point for tape backups are (1) off-site storage, (2) > >>>>>>>> multiple PiT recovery, (3) logical error recovery. All this can be > >>>> done > >>>>>>>> with disk-only environments involving remote copy and lots of disk > >>>>>> space, > >>>>>>>> but all that becomes expensive for smaller shops. > >>>>>>>> > >>>>>>>> Bill Ogden > >>>>>>>> > >>>>>>>> > >> > >> > > > == > > 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 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > -- > 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
Re: Storage & tape question
I'm not Kim's fan, nor fan of piracy, etc. However he is still free. After 8 years. Yes, in New Zealand, not in US. But he lives in New Zealand not in North Korea or Cuba, or Biafra. And he has new business named MEGA, similar to Megaupload. MEGA started 7 years ago and since then it is still working. My pictures are still lost, damaged by someone who decided. I'm still not going to sue anybody for that damage. ;-) Note: this is far from discussion about disks and tapes. This is my last message in this sub-thread. -- Radoslaw Skorupka Lodz, Poland W dniu 13.07.2020 o 16:21, Joe Monk pisze: "Regarding Kim - AFAIK he was was found innocent. I'm talking about Megaupload case, not several former cases." Nope.He's still in New Zealand, fighting extradition to the USA for criminal charges for the megaupload case. Joe On Mon, Jul 13, 2020 at 6:50 AM R.S. wrote: OK, now I understand the legal aspect. I also disgree with that, but this is completely off-topic (and related to Kim's problems). However "something" as a service could mean colocation, PaaS, SaaS, etc. In some scenarios you buy working solution, not software license. In such case you are not responsible for the licenses. That's like cloud backup - I pay for backup, I'm not aware what backup software was used and wether it was licensed. I also don't check driver licence in a taxi, nor insurance policy. I pay for transfer to airport. Regarding Kim - AFAIK he was was found innocent. I'm talking about Megaupload case, not several former cases. BTW: interesting issue with data in a cloud. I did really use Megaupload. I don't feel uncomfortable with that, because I used it for transfer my photographs to a person who asked me for. My pictures from some tour. My selection of pictures with this guy and his wife (their camere failed, so I helped them). I uploaded it to Megaupload. Used password for privacy and sent password and link to this guy. Files were safe - everthing was in a cloud. Suddenly someone decided to destroy the service. Was he right? Not in case of my pictures. However he didn't care. More: legal court sentence was it wasn't right. What about my pictures? They gone. What can I do? Fortunately I have my own backup, so I had to repeat selection of the pictures and send it using other method. -- Radoslaw Skorupka Lodz, Poland W dniu 13.07.2020 o 13:25, Joe Monk pisze: My point is, once you rent that computer and put your stuff on it, it is no longer "someone else's computer". It is now YOUR computer. YOU are responsible for it. Joe On Mon, Jul 13, 2020 at 5:35 AM R.S. wrote: I heard about Kim Dotcom, but I don't understand what you mean. I'm not talking here about legal issues, so there is nothing to love. And the cloud is still someone else's computer, isn't it? Keeping data in cloud is still keeping data on someone else's media like disk or tape. Usually tape for large amounts and reasonable prices (with horrible access times). The main difference is you don't know where is your data. (off topic drift) Of course cloud is valuable in man cases, especially for smal and medium businesses. Sometimes "don't do it, use our services" is true. You don't buy brewery to have a beer to a dinner or you don't buy taxi car to get to airport. However many companies still have their own truck fleet. -- Radoslaw Skorupka Lodz, Poland W dniu 09.07.2020 o 16:22, Joe Monk pisze: Im sure that Kim Dotcom would love your legal theory... Joe On Thu, Jul 9, 2020 at 7:51 AM R.S. wrote: Azure? Cloud? There is no cloud. It is just someone else's computer. ;-) -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 17:46, Joe Monk pisze: I do a backup to spinning storage, then a copy of that backup to Azure for long term. Joe On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: I've always gone with dual* backups, with one copy off site. Remote mirroring is a good option where policy permits, and even if retensioning is no longer relevant, rereading backups periodically will give you a heads up if one copy goes south. I would consider even correctable errors to be red flags. Any medium you use will have failure modes. Multiple PiT recovery is good for "whoops!" moments and possibly for audits. Large or small, each shop must do it's own risk assessments in the context of its own obligations and priorities. * Depending on the value of the data, you might want more than 2. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Ogden [og...@us.ibm.com] Sent: Wednesday, July 8, 2020 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on
Re: Storage & tape question
"Regarding Kim - AFAIK he was was found innocent. I'm talking about Megaupload case, not several former cases." Nope.He's still in New Zealand, fighting extradition to the USA for criminal charges for the megaupload case. Joe On Mon, Jul 13, 2020 at 6:50 AM R.S. wrote: > OK, now I understand the legal aspect. I also disgree with that, but > this is completely off-topic (and related to Kim's problems). > However "something" as a service could mean colocation, PaaS, SaaS, etc. > In some scenarios you buy working solution, not software license. In > such case you are not responsible for the licenses. That's like cloud > backup - I pay for backup, I'm not aware what backup software was used > and wether it was licensed. I also don't check driver licence in a taxi, > nor insurance policy. I pay for transfer to airport. > > Regarding Kim - AFAIK he was was found innocent. I'm talking about > Megaupload case, not several former cases. > > BTW: interesting issue with data in a cloud. I did really use > Megaupload. I don't feel uncomfortable with that, because I used it for > transfer my photographs to a person who asked me for. My pictures from > some tour. My selection of pictures with this guy and his wife (their > camere failed, so I helped them). I uploaded it to Megaupload. Used > password for privacy and sent password and link to this guy. Files were > safe - everthing was in a cloud. Suddenly someone decided to destroy the > service. Was he right? Not in case of my pictures. However he didn't > care. More: legal court sentence was it wasn't right. What about my > pictures? They gone. > What can I do? Fortunately I have my own backup, so I had to repeat > selection of the pictures and send it using other method. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 13.07.2020 o 13:25, Joe Monk pisze: > > My point is, once you rent that computer and put your stuff on it, it is > no > > longer "someone else's computer". It is now YOUR computer. YOU are > > responsible for it. > > > > Joe > > > > On Mon, Jul 13, 2020 at 5:35 AM R.S. > wrote: > > > >> I heard about Kim Dotcom, but I don't understand what you mean. > >> I'm not talking here about legal issues, so there is nothing to love. > >> And the cloud is still someone else's computer, isn't it? > >> Keeping data in cloud is still keeping data on someone else's media like > >> disk or tape. Usually tape for large amounts and reasonable prices (with > >> horrible access times). The main difference is you don't know where is > >> your data. > >> > >> (off topic drift) > >> Of course cloud is valuable in man cases, especially for smal and medium > >> businesses. Sometimes "don't do it, use our services" is true. You don't > >> buy brewery to have a beer to a dinner or you don't buy taxi car to get > >> to airport. However many companies still have their own truck fleet. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > >> W dniu 09.07.2020 o 16:22, Joe Monk pisze: > >>> Im sure that Kim Dotcom would love your legal theory... > >>> > >>> Joe > >>> > >>> On Thu, Jul 9, 2020 at 7:51 AM R.S. > >> wrote: > >>>> Azure? Cloud? > >>>> There is no cloud. It is just someone else's computer. ;-) > >>>> > >>>> -- > >>>> Radoslaw Skorupka > >>>> Lodz, Poland > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> W dniu 08.07.2020 o 17:46, Joe Monk pisze: > >>>>> I do a backup to spinning storage, then a copy of that backup to > Azure > >>>> for > >>>>> long term. > >>>>> > >>>>> Joe > >>>>> > >>>>> On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz > wrote: > >>>>> > >>>>>> I've always gone with dual* backups, with one copy off site. Remote > >>>>>> mirroring is a good option where policy permits, and even if > >>>> retensioning > >>>>>> is no longer relevant, rereading backups periodically will give you > a > >>>> heads > >>>>>> up if one copy goes south. I would consider even correctable errors > t
Re: Storage & tape question
OK, now I understand the legal aspect. I also disgree with that, but this is completely off-topic (and related to Kim's problems). However "something" as a service could mean colocation, PaaS, SaaS, etc. In some scenarios you buy working solution, not software license. In such case you are not responsible for the licenses. That's like cloud backup - I pay for backup, I'm not aware what backup software was used and wether it was licensed. I also don't check driver licence in a taxi, nor insurance policy. I pay for transfer to airport. Regarding Kim - AFAIK he was was found innocent. I'm talking about Megaupload case, not several former cases. BTW: interesting issue with data in a cloud. I did really use Megaupload. I don't feel uncomfortable with that, because I used it for transfer my photographs to a person who asked me for. My pictures from some tour. My selection of pictures with this guy and his wife (their camere failed, so I helped them). I uploaded it to Megaupload. Used password for privacy and sent password and link to this guy. Files were safe - everthing was in a cloud. Suddenly someone decided to destroy the service. Was he right? Not in case of my pictures. However he didn't care. More: legal court sentence was it wasn't right. What about my pictures? They gone. What can I do? Fortunately I have my own backup, so I had to repeat selection of the pictures and send it using other method. -- Radoslaw Skorupka Lodz, Poland W dniu 13.07.2020 o 13:25, Joe Monk pisze: My point is, once you rent that computer and put your stuff on it, it is no longer "someone else's computer". It is now YOUR computer. YOU are responsible for it. Joe On Mon, Jul 13, 2020 at 5:35 AM R.S. wrote: I heard about Kim Dotcom, but I don't understand what you mean. I'm not talking here about legal issues, so there is nothing to love. And the cloud is still someone else's computer, isn't it? Keeping data in cloud is still keeping data on someone else's media like disk or tape. Usually tape for large amounts and reasonable prices (with horrible access times). The main difference is you don't know where is your data. (off topic drift) Of course cloud is valuable in man cases, especially for smal and medium businesses. Sometimes "don't do it, use our services" is true. You don't buy brewery to have a beer to a dinner or you don't buy taxi car to get to airport. However many companies still have their own truck fleet. -- Radoslaw Skorupka Lodz, Poland W dniu 09.07.2020 o 16:22, Joe Monk pisze: Im sure that Kim Dotcom would love your legal theory... Joe On Thu, Jul 9, 2020 at 7:51 AM R.S. wrote: Azure? Cloud? There is no cloud. It is just someone else's computer. ;-) -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 17:46, Joe Monk pisze: I do a backup to spinning storage, then a copy of that backup to Azure for long term. Joe On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: I've always gone with dual* backups, with one copy off site. Remote mirroring is a good option where policy permits, and even if retensioning is no longer relevant, rereading backups periodically will give you a heads up if one copy goes south. I would consider even correctable errors to be red flags. Any medium you use will have failure modes. Multiple PiT recovery is good for "whoops!" moments and possibly for audits. Large or small, each shop must do it's own risk assessments in the context of its own obligations and priorities. * Depending on the value of the data, you might want more than 2. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Ogden [og...@us.ibm.com] Sent: Wednesday, July 8, 2020 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple
Re: Storage & tape question
My point is, once you rent that computer and put your stuff on it, it is no longer "someone else's computer". It is now YOUR computer. YOU are responsible for it. Joe On Mon, Jul 13, 2020 at 5:35 AM R.S. wrote: > I heard about Kim Dotcom, but I don't understand what you mean. > I'm not talking here about legal issues, so there is nothing to love. > And the cloud is still someone else's computer, isn't it? > Keeping data in cloud is still keeping data on someone else's media like > disk or tape. Usually tape for large amounts and reasonable prices (with > horrible access times). The main difference is you don't know where is > your data. > > (off topic drift) > Of course cloud is valuable in man cases, especially for smal and medium > businesses. Sometimes "don't do it, use our services" is true. You don't > buy brewery to have a beer to a dinner or you don't buy taxi car to get > to airport. However many companies still have their own truck fleet. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 09.07.2020 o 16:22, Joe Monk pisze: > > Im sure that Kim Dotcom would love your legal theory... > > > > Joe > > > > On Thu, Jul 9, 2020 at 7:51 AM R.S. > wrote: > > > >> Azure? Cloud? > >> There is no cloud. It is just someone else's computer. ;-) > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > >> > >> W dniu 08.07.2020 o 17:46, Joe Monk pisze: > >>> I do a backup to spinning storage, then a copy of that backup to Azure > >> for > >>> long term. > >>> > >>> Joe > >>> > >>> On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: > >>> > >>>> I've always gone with dual* backups, with one copy off site. Remote > >>>> mirroring is a good option where policy permits, and even if > >> retensioning > >>>> is no longer relevant, rereading backups periodically will give you a > >> heads > >>>> up if one copy goes south. I would consider even correctable errors to > >> be > >>>> red flags. > >>>> > >>>> Any medium you use will have failure modes. > >>>> > >>>> Multiple PiT recovery is good for "whoops!" moments and possibly for > >>>> audits. > >>>> > >>>> Large or small, each shop must do it's own risk assessments in the > >> context > >>>> of its own obligations and priorities. > >>>> > >>>> * Depending on the value of the data, you might want more than 2. > >>>> > >>>> > >>>> -- > >>>> Shmuel (Seymour J.) Metz > >>>> http://mason.gmu.edu/~smetz3 > >>>> > >>>> > >>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >> behalf > >>>> of Bill Ogden [og...@us.ibm.com] > >>>> Sent: Wednesday, July 8, 2020 9:27 AM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Re: Storage & tape question > >>>> > >>>> Probably many others will chime in on this. I have lost RAID 5 arrays > >> with > >>>> two disk failures within an hour of each other. RAID is nice, but one > >> must > >>>> allow for failures. > >>>> > >>>> Long ago I was involved with reading archived tapes and transferring > the > >>>> data to CDs. The programs involved were home-written and the project > >> ended > >>>> up going nowhere. However, we discovered that tapes kept too long > >> started > >>>> having errors. (At that point, for the CD copy, we just logged the > error > >>>> and accepted the corrupt data; what else could we do?) How long is > "too > >>>> long"?? It was variable, but measured in a few years. The advice then > >> was > >>>> to minimally read the tapes every year or so to "retension" them. > Don't > >>>> know if this would apply to more modern tape media. (We also > discovered > >>>> that locally "burned" CDs are not expected last forever.) > >>>> > >>>> IMHO, the key point for tape backups are (1) off-site storage, (2) > >>>> multiple PiT recov
Re: Storage & tape question
I heard about Kim Dotcom, but I don't understand what you mean. I'm not talking here about legal issues, so there is nothing to love. And the cloud is still someone else's computer, isn't it? Keeping data in cloud is still keeping data on someone else's media like disk or tape. Usually tape for large amounts and reasonable prices (with horrible access times). The main difference is you don't know where is your data. (off topic drift) Of course cloud is valuable in man cases, especially for smal and medium businesses. Sometimes "don't do it, use our services" is true. You don't buy brewery to have a beer to a dinner or you don't buy taxi car to get to airport. However many companies still have their own truck fleet. -- Radoslaw Skorupka Lodz, Poland W dniu 09.07.2020 o 16:22, Joe Monk pisze: Im sure that Kim Dotcom would love your legal theory... Joe On Thu, Jul 9, 2020 at 7:51 AM R.S. wrote: Azure? Cloud? There is no cloud. It is just someone else's computer. ;-) -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 17:46, Joe Monk pisze: I do a backup to spinning storage, then a copy of that backup to Azure for long term. Joe On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: I've always gone with dual* backups, with one copy off site. Remote mirroring is a good option where policy permits, and even if retensioning is no longer relevant, rereading backups periodically will give you a heads up if one copy goes south. I would consider even correctable errors to be red flags. Any medium you use will have failure modes. Multiple PiT recovery is good for "whoops!" moments and possibly for audits. Large or small, each shop must do it's own risk assessments in the context of its own obligations and priorities. * Depending on the value of the data, you might want more than 2. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Ogden [og...@us.ibm.com] Sent: Wednesday, July 8, 2020 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple PiT recovery, (3) logical error recovery. All this can be done with disk-only environments involving remote copy and lots of disk space, but all that becomes expensive for smaller shops. Bill Ogden == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 Regist
Re: Storage & tape question
Im sure that Kim Dotcom would love your legal theory... Joe On Thu, Jul 9, 2020 at 7:51 AM R.S. wrote: > Azure? Cloud? > There is no cloud. It is just someone else's computer. ;-) > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 08.07.2020 o 17:46, Joe Monk pisze: > > I do a backup to spinning storage, then a copy of that backup to Azure > for > > long term. > > > > Joe > > > > On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: > > > >> I've always gone with dual* backups, with one copy off site. Remote > >> mirroring is a good option where policy permits, and even if > retensioning > >> is no longer relevant, rereading backups periodically will give you a > heads > >> up if one copy goes south. I would consider even correctable errors to > be > >> red flags. > >> > >> Any medium you use will have failure modes. > >> > >> Multiple PiT recovery is good for "whoops!" moments and possibly for > >> audits. > >> > >> Large or small, each shop must do it's own risk assessments in the > context > >> of its own obligations and priorities. > >> > >> * Depending on the value of the data, you might want more than 2. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf > >> of Bill Ogden [og...@us.ibm.com] > >> Sent: Wednesday, July 8, 2020 9:27 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Storage & tape question > >> > >> Probably many others will chime in on this. I have lost RAID 5 arrays > with > >> two disk failures within an hour of each other. RAID is nice, but one > must > >> allow for failures. > >> > >> Long ago I was involved with reading archived tapes and transferring the > >> data to CDs. The programs involved were home-written and the project > ended > >> up going nowhere. However, we discovered that tapes kept too long > started > >> having errors. (At that point, for the CD copy, we just logged the error > >> and accepted the corrupt data; what else could we do?) How long is "too > >> long"?? It was variable, but measured in a few years. The advice then > was > >> to minimally read the tapes every year or so to "retension" them. Don't > >> know if this would apply to more modern tape media. (We also discovered > >> that locally "burned" CDs are not expected last forever.) > >> > >> IMHO, the key point for tape backups are (1) off-site storage, (2) > >> multiple PiT recovery, (3) logical error recovery. All this can be done > >> with disk-only environments involving remote copy and lots of disk > space, > >> but all that becomes expensive for smaller shops. > >> > >> Bill Ogden > >> > >> > > > == > > 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 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > -- > 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
Re: Storage & tape question
And of course HSM duplexing for ML2 and Backup tapes automatically covers the requirement to use different drives. Since the two copies are made concurrently, that guarantees they have to be on different drives. It should be obvious enough to not need saying, but you also don't make two copies of critical tape data by running a copy step to make a copy of the first tape: a drive failure or some physical accident to the media during the copy process may destroy the one and only copy of the data before the copy process completes. The original DASD-based data should be used to generate all tape copies. With modern tape technologies, actual failures due to the tape media itself tend to be gradual and correctable: during writing, data blocks are verified as they are written and marginal spots on the media skipped, and error-correction encoding provides redundancy and correction when reading data if surface damage occurs later. In a properly maintained tape library where cartidges that start to show issues from age and use are replaced, data loss from a media issue should be exceedingly rare to non-existent. That said, catastrophic tape failure can always be induced by a device failure that causes physical damage to the media; or by some accident, mis-handling of a cartridge, or environment disaster that results in physical damage to the cartridge & media. Logical failures are also always possible, where a series of operational mis-steps results in a valuable tape being marked for deletion and re-used before its time. Joel C Ewing On 7/9/20 7:49 AM, R.S. wrote: > Regarding tapes: this is one of the advantages of using HSM and > physical tapes. It's quite easy to manage that even very old backup is > on quite recently recorded tape. Migration from older tape system to > new one is piece of cake. For VTS things are a bit more complex but > still it is possible. "Fresh" tapes are better than 15-years old cart, > last mounted 10 years ago. Not to mention weared drives. > > And of course always use two physical tapes. Preferrably in two > locations. Even the best tape may fail. Two cart also may fail, but it > is less likely. Three tapes (in three ATLs, in three locations) are > even more unlikely to fail concurrently, etc. And it is your decision > to say "n copies is enough safety for me". And I'm sorry, I don't > believe in any support from business side. > > BTW: two tapes, but avoid to write or read them in same drive. Drive > failure may somehow destroy the tape. I know a guy who tried to > recover data from backup, but the tape was faulty. He had two copies. > Second reel was also faulty. Actually both tapes were mounted in same > faulty drive which destroyed both copies. In that scenario even dozen > of copies would not help (assuming still same drive). > -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Charles, Were you prepared of coronavirus? Were your company prepared for that 3 years ago? No. Are your company prepared for terrorist attack at all datacenters at the time? It depends on the sword being used, but generally no. Unlikely things do happen. More unlikely things do happen. Even more unlikely things may happen. However there is no solution which protect against everything. A copy on disk or tape may fail. Two copies may fail. Three copies may fail, Four copies... By adding copies we minimize the risk, but not zeroize it. And sometimes other factors become important. Example: many copies inside one building. For one copy the issue was not applicable. For three copies it is important. Not because it is less safe than one copy, but because safety became being limited by number of locations. -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 18:13, Charles Mills pisze: Unlikely? Black swans do happen. How unlikely is a world-wide pandemic that cripples economies around the world? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 8, 2020 2:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Regarding eggs and backets. This is english proverb, not used in Poland. I rather use electricity example: serial and parallel connection of light bulbs. The idea of two datacenters is to have bulbs in parallel - one may fail, but the other will work. However sometimes (especially in Windows world) it is deviated to serial connection - both datacenter have to work, otherwise you have business outage. Of course if your system consist of three elements (eggs) and all of them have to be working, then single basket (dc) is good choice. And it is good idea to think about another basket with copies of the eggs. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 21:05, Jesse 1 Robinson pisze: The biggest off-color swan on the West Coast by far is earthquake. Wildfire is also on the list as well as tsunami. Some years ago (the old) Bank of America came close to shutting down their downtown LA data center because of civil unrest. In the age of climate change, flooding is not out of the question. As to probabilities, I like to question the 'all eggs in one basket' trope. If you have a dozen eggs *every one of which is vital*, you might as put them all in one basket and resolve to take very good care of it. If some of the eggs are dispensable, then distribute them in multiple baskets. The more baskets you have to take care of, the greater the risk that one or more will fail. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, July 8, 2020 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Storage & tape question CAUTION EXTERNAL EMAIL Unlikely? Black swans do happen. How unlikely is a world-wide pandemic that cripples economies around the world? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 8, 2020 2:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital am
Re: Storage & tape question
IMHO no and there is no reason. Is the backup OK? Just read it. Any error will be reported. Physical errors are reported by the hardware. Is backup altered by hostile user? Protect it using RACF or else. However educated and authorized user may alter backup and re-create hash. Do you want to sleep safely? Then don't think about backup ;-) Or just make your backup safe enough for your needs. It may mean two copies, two copies in two locations, 4 copies in two location, 6 copies in 3 locations, one really far. Or 8 copies in 4 locations... However you will never be 100% safe. It is hard to imagine an flood with diameter of 2000 miles, but terrorist attack against YOUR COMPANY can cover all your datacenters at the time. It is unlikely, but adding datacenters will not help you in that case. Keeping addresses in secret is rather hard and will become useless after first disclosure. This is important and sometimes hard to explain: we are not talking about two or three random attacks which accidentally happened one day and accidentally covered our datacenters. This is about ONE terrorist action with two or three threads. -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 17:54, kekronbekron pisze: Dumb question - can integrity checks for backups be done with dump hashes/signatures, either in software or in the storage array (if the array maintains metadata about files/objects) ? If there's an automated flow for this, many teams could sleep peacefully, knowing that backups are in good condition, without having to actually pick one and test the flow. - KB ‐‐‐ Original Message ‐‐‐ On Wednesday, July 8, 2020 8:56 PM, Glenn Wilcock wrote: Hi All, I want to give another perspective on the need for backup copies. The focus here is on physical loss of storage. With replication, and many clients having 2, 3 and even 4 sites, the probability of needing a backup copy to recover from a physical loss of data really has decreased. (Still there, none the less). BUT, the probability for logical data corruption has INCREASED. Accidental and malicious data corruption is instantly mirrored to all replication copies, making them useless. Working in HSM, I regularly see calls requesting assistance in recovering large amounts of data from backup copies. We're all human and we all make mistakes. Some of those mistakes result in data loss. Also, all products have programming defects and some of those defects result in data loss. This speaks nothing to the current environment where governments are mandating policies and procedures for protecting against malicious data destruction. Your only hope for recovery is a PiT backup prior to the data loss/corruption. Not all loss/corruption will be found immediately. So, your ability to recover is a factor of how long it takes you to determine that there was corruption/loss and how much your willing to invest in keeping backup copies for at least that long. Glenn Wilcock DFSMS Chief Product Owner == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Azure? Cloud? There is no cloud. It is just someone else's computer. ;-) -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 17:46, Joe Monk pisze: I do a backup to spinning storage, then a copy of that backup to Azure for long term. Joe On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: I've always gone with dual* backups, with one copy off site. Remote mirroring is a good option where policy permits, and even if retensioning is no longer relevant, rereading backups periodically will give you a heads up if one copy goes south. I would consider even correctable errors to be red flags. Any medium you use will have failure modes. Multiple PiT recovery is good for "whoops!" moments and possibly for audits. Large or small, each shop must do it's own risk assessments in the context of its own obligations and priorities. * Depending on the value of the data, you might want more than 2. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Ogden [og...@us.ibm.com] Sent: Wednesday, July 8, 2020 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple PiT recovery, (3) logical error recovery. All this can be done with disk-only environments involving remote copy and lots of disk space, but all that becomes expensive for smaller shops. Bill Ogden == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Regarding tapes: this is one of the advantages of using HSM and physical tapes. It's quite easy to manage that even very old backup is on quite recently recorded tape. Migration from older tape system to new one is piece of cake. For VTS things are a bit more complex but still it is possible. "Fresh" tapes are better than 15-years old cart, last mounted 10 years ago. Not to mention weared drives. And of course always use two physical tapes. Preferrably in two locations. Even the best tape may fail. Two cart also may fail, but it is less likely. Three tapes (in three ATLs, in three locations) are even more unlikely to fail concurrently, etc. And it is your decision to say "n copies is enough safety for me". And I'm sorry, I don't believe in any support from business side. BTW: two tapes, but avoid to write or read them in same drive. Drive failure may somehow destroy the tape. I know a guy who tried to recover data from backup, but the tape was faulty. He had two copies. Second reel was also faulty. Actually both tapes were mounted in same faulty drive which destroyed both copies. In that scenario even dozen of copies would not help (assuming still same drive). -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 16:07, Vernooij, Kees (ITOP NM) - KLM pisze: I agree with your findings. At one time, one headlight of my car failed. Since it has two headlights, I did not make much hurry to replace it, but 2 days later the other one failed. Then I was left in almost complete darkness. A SPOF is a SPOF and is subject to Murphy's law, which means it will hit you at the most inconvenient momemt. The TS7740 has several selection criteria for physical tape reclaims: one is the period a tape has not been mounted. The max period you can set here was 365 days (or not do it at all). There must be a good reason to limit this period to 1 year, not more. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Ogden Sent: 08 July 2020 15:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple PiT recovery, (3) logical error recovery. All this can be done with disk-only environments involving remote copy and lots of disk space, but all that becomes expensive for smaller shops. Bill Ogden == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For
Re: Storage & tape question
The biggest off-color swan on the West Coast by far is earthquake. Wildfire is also on the list as well as tsunami. Some years ago (the old) Bank of America came close to shutting down their downtown LA data center because of civil unrest. In the age of climate change, flooding is not out of the question. As to probabilities, I like to question the 'all eggs in one basket' trope. If you have a dozen eggs *every one of which is vital*, you might as put them all in one basket and resolve to take very good care of it. If some of the eggs are dispensable, then distribute them in multiple baskets. The more baskets you have to take care of, the greater the risk that one or more will fail. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, July 8, 2020 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Storage & tape question CAUTION EXTERNAL EMAIL Unlikely? Black swans do happen. How unlikely is a world-wide pandemic that cripples economies around the world? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 8, 2020 2:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Unlikely? Black swans do happen. How unlikely is a world-wide pandemic that cripples economies around the world? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 8, 2020 2:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
In the case of the NotPetya malware attack that crippled Maersk Lines, I believe they did not have backup for their router configuration files on the theory they had multiple routers and each backed the others up via replication. Of course when one got corrupted it happily replicated to all the others. A much greater disaster was averted only because they had one router in Ghana which was offline at the time due to a power outage. I wrote the above from memory; nitpicking may be possible. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Glenn Wilcock Sent: Wednesday, July 8, 2020 8:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Hi All, I want to give another perspective on the need for backup copies. The focus here is on physical loss of storage. With replication, and many clients having 2, 3 and even 4 sites, the probability of needing a backup copy to recover from a physical loss of data really has decreased. (Still there, none the less). BUT, the probability for logical data corruption has INCREASED. Accidental and malicious data corruption is instantly mirrored to all replication copies, making them useless. Working in HSM, I regularly see calls requesting assistance in recovering large amounts of data from backup copies. We're all human and we all make mistakes. Some of those mistakes result in data loss. Also, all products have programming defects and some of those defects result in data loss. This speaks nothing to the current environment where governments are mandating policies and procedures for protecting against malicious data destruction. Your only hope for recovery is a PiT backup prior to the data loss/corruption. Not all loss/corruption will be found immediately. So, your ability to recover is a factor of how long it takes you to determine that there was corruption/loss and how much your willing to invest in keeping backup copies for at least that long. Glenn Wilcock DFSMS Chief Product Owner -- 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
Re: Storage & tape question
Dumb question - can integrity checks for backups be done with dump hashes/signatures, either in software or in the storage array (if the array maintains metadata about files/objects) ? If there's an automated flow for this, many teams could sleep peacefully, knowing that backups are in good condition, without having to actually pick one and test the flow. - KB ‐‐‐ Original Message ‐‐‐ On Wednesday, July 8, 2020 8:56 PM, Glenn Wilcock wrote: > Hi All, > > I want to give another perspective on the need for backup copies. The focus > here is on physical loss of storage. With replication, and many clients > having 2, 3 and even 4 sites, the probability of needing a backup copy to > recover from a physical loss of data really has decreased. (Still there, none > the less). BUT, the probability for logical data corruption has INCREASED. > Accidental and malicious data corruption is instantly mirrored to all > replication copies, making them useless. Working in HSM, I regularly see > calls requesting assistance in recovering large amounts of data from backup > copies. We're all human and we all make mistakes. Some of those mistakes > result in data loss. Also, all products have programming defects and some of > those defects result in data loss. This speaks nothing to the current > environment where governments are mandating policies and procedures for > protecting against malicious data destruction. Your only hope for recovery is > a PiT backup prior to the data loss/corruption. Not all loss/corruption will > be found immediately. So, your ability to recover is a factor of how long it > takes you to determine that there was corruption/loss and how much your > willing to invest in keeping backup copies for at least that long. > > Glenn Wilcock > DFSMS Chief Product Owner > > --- > > 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
Re: Storage & tape question
I do a backup to spinning storage, then a copy of that backup to Azure for long term. Joe On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz wrote: > I've always gone with dual* backups, with one copy off site. Remote > mirroring is a good option where policy permits, and even if retensioning > is no longer relevant, rereading backups periodically will give you a heads > up if one copy goes south. I would consider even correctable errors to be > red flags. > > Any medium you use will have failure modes. > > Multiple PiT recovery is good for "whoops!" moments and possibly for > audits. > > Large or small, each shop must do it's own risk assessments in the context > of its own obligations and priorities. > > * Depending on the value of the data, you might want more than 2. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Bill Ogden [og...@us.ibm.com] > Sent: Wednesday, July 8, 2020 9:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > Probably many others will chime in on this. I have lost RAID 5 arrays with > two disk failures within an hour of each other. RAID is nice, but one must > allow for failures. > > Long ago I was involved with reading archived tapes and transferring the > data to CDs. The programs involved were home-written and the project ended > up going nowhere. However, we discovered that tapes kept too long started > having errors. (At that point, for the CD copy, we just logged the error > and accepted the corrupt data; what else could we do?) How long is "too > long"?? It was variable, but measured in a few years. The advice then was > to minimally read the tapes every year or so to "retension" them. Don't > know if this would apply to more modern tape media. (We also discovered > that locally "burned" CDs are not expected last forever.) > > IMHO, the key point for tape backups are (1) off-site storage, (2) > multiple PiT recovery, (3) logical error recovery. All this can be done > with disk-only environments involving remote copy and lots of disk space, > but all that becomes expensive for smaller shops. > > Bill Ogden > > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Hi All, I want to give another perspective on the need for backup copies. The focus here is on physical loss of storage. With replication, and many clients having 2, 3 and even 4 sites, the probability of needing a backup copy to recover from a physical loss of data really has decreased. (Still there, none the less). BUT, the probability for logical data corruption has INCREASED. Accidental and malicious data corruption is instantly mirrored to all replication copies, making them useless. Working in HSM, I regularly see calls requesting assistance in recovering large amounts of data from backup copies. We're all human and we all make mistakes. Some of those mistakes result in data loss. Also, all products have programming defects and some of those defects result in data loss. This speaks nothing to the current environment where governments are mandating policies and procedures for protecting against malicious data destruction. Your only hope for recovery is a PiT backup prior to the data loss/corruption. Not all loss/corruption will be found immediately. So, your ability to recover is a factor of how long it takes you to determine that there was corruption/loss and how much your willing to invest in keeping backup copies for at least that long. Glenn Wilcock DFSMS Chief Product Owner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
I've always gone with dual* backups, with one copy off site. Remote mirroring is a good option where policy permits, and even if retensioning is no longer relevant, rereading backups periodically will give you a heads up if one copy goes south. I would consider even correctable errors to be red flags. Any medium you use will have failure modes. Multiple PiT recovery is good for "whoops!" moments and possibly for audits. Large or small, each shop must do it's own risk assessments in the context of its own obligations and priorities. * Depending on the value of the data, you might want more than 2. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Ogden [og...@us.ibm.com] Sent: Wednesday, July 8, 2020 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple PiT recovery, (3) logical error recovery. All this can be done with disk-only environments involving remote copy and lots of disk space, but all that becomes expensive for smaller shops. Bill Ogden -- 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
Re: Storage & tape question
I agree with your findings. At one time, one headlight of my car failed. Since it has two headlights, I did not make much hurry to replace it, but 2 days later the other one failed. Then I was left in almost complete darkness. A SPOF is a SPOF and is subject to Murphy's law, which means it will hit you at the most inconvenient momemt. The TS7740 has several selection criteria for physical tape reclaims: one is the period a tape has not been mounted. The max period you can set here was 365 days (or not do it at all). There must be a good reason to limit this period to 1 year, not more. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Ogden Sent: 08 July 2020 15:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple PiT recovery, (3) logical error recovery. All this can be done with disk-only environments involving remote copy and lots of disk space, but all that becomes expensive for smaller shops. Bill Ogden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Probably many others will chime in on this. I have lost RAID 5 arrays with two disk failures within an hour of each other. RAID is nice, but one must allow for failures. Long ago I was involved with reading archived tapes and transferring the data to CDs. The programs involved were home-written and the project ended up going nowhere. However, we discovered that tapes kept too long started having errors. (At that point, for the CD copy, we just logged the error and accepted the corrupt data; what else could we do?) How long is "too long"?? It was variable, but measured in a few years. The advice then was to minimally read the tapes every year or so to "retension" them. Don't know if this would apply to more modern tape media. (We also discovered that locally "burned" CDs are not expected last forever.) IMHO, the key point for tape backups are (1) off-site storage, (2) multiple PiT recovery, (3) logical error recovery. All this can be done with disk-only environments involving remote copy and lots of disk space, but all that becomes expensive for smaller shops. Bill Ogden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
First off, STOP Second off, disaster recovery is a question of risk mitigation for a business. The business (NOT I.T.) must make the decision as to what level of risk mitigation they are willing to pay for. You can preach at them til their blue in the face, and it wont matter until something happens like a ransomware attack and they go down for a week or so. Joe On Wed, Jul 8, 2020 at 7:21 AM R.S. wrote: > No, you answered off topic. You initiate quarrels. Not only here. > You have a of time for trolling. And you always want to say "no, you're > wrong". > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 08.07.2020 o 14:17, Seymour J Metz pisze: > > No thanks, I'll leave that sort of thing to you; you're much better at > it than I am. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of R.S. [r.skoru...@bremultibank.com.pl] > > Sent: Wednesday, July 8, 2020 7:58 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Storage & tape question > > > > Feel free to answer off-topic, criticize unsaid sentences and be > > self-concvinced you are right while rest of the world is wrong. Have a > fun. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > > > W dniu 08.07.2020 o 13:53, Seymour J Metz pisze: > >> Whoosh! You're completely missing the point. It's a matter of basic > probability theory. Given N independent adverse scenarios with > probabilities Pn, the probability that none of them will happen is > (1-P1)(1-P2)...(1-PN). > >> > >> But it's not my dog. Feel free to run without backups, as long as you > don't ask for sympathy when the balloon goes up. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of R.S. [r.skoru...@bremultibank.com.pl] > >> Sent: Wednesday, July 8, 2020 5:32 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Storage & tape question > >> > >> It has no value. > >> Terrorist attack is unlikely, but two terrorist attacks at the time are > >> more unlikely. Thousand terrorist attacks at the tima are even more > >> unlikely. > >> A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. > >> When you have two datacenters and tapes in shelter off-site ...it is > >> still just unlikely to have coordinated attack on all the locations at > >> the time, and it is just unlikely to have shelters strong enough. > >> More data locations? Fine, more bombs. > >> And it is quite likely some malevolent people would know the adresses of > >> the locations. > >> > >> If you think you can protect your data against unlikely events > >> (disaster, etc.)... > >> Or rather: if you think you know how to do it, despite of the costs - > >> you're simply WRONG. > >> There is always some level of protection. The level is not infinite and > >> *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably > >> high". > >> > >> > >> Side note: there are scenarios when achieving higher level of protection > >> is pointless. Let's assume ticket system for metro transportation > >> (buses) and ...war. Or ticket system for buses in Biloxi. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > >> > >> W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: > >>> A terrorist attack is unlikely. > >>> > >>> An earthquake is unlikely. > >>> > >>> A tornado is unlikely. > >>> > >>> A flood is unlikely. > >>> > >>> ... > >>> > >>> The more unlikely risks there are, the greater the odds that one of > them will happen. If you don't have off site backups then your data are at > risk, and when the balloon goes up it won't matter how unlikely the > particular failure mode was. > >>> > >>> > >>> -- > >>> Shmuel (Seymour J.) Metz > >>> http://mason.gmu.edu/~smetz3 > >>> > &
Re: Storage & tape question
No, you answered off topic. You initiate quarrels. Not only here. You have a of time for trolling. And you always want to say "no, you're wrong". -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 14:17, Seymour J Metz pisze: No thanks, I'll leave that sort of thing to you; you're much better at it than I am. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, July 8, 2020 7:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Feel free to answer off-topic, criticize unsaid sentences and be self-concvinced you are right while rest of the world is wrong. Have a fun. -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 13:53, Seymour J Metz pisze: Whoosh! You're completely missing the point. It's a matter of basic probability theory. Given N independent adverse scenarios with probabilities Pn, the probability that none of them will happen is (1-P1)(1-P2)...(1-PN). But it's not my dog. Feel free to run without backups, as long as you don't ask for sympathy when the balloon goes up. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, July 8, 2020 5:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: A terrorist attack is unlikely. An earthquake is unlikely. A tornado is unlikely. A flood is unlikely. ... The more unlikely risks there are, the greater the odds that one of them will happen. If you don't have off site backups then your data are at risk, and when the balloon goes up it won't matter how unlikely the particular failure mode was. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Tuesday, July 7, 2020 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question W dniu 07.07.2020 o 16:52, Edward Finnell pisze: 1200lbs Semtex make you realize what backups are for and where is your cold site? In a message dated 7/7/2020 9:37:20 AM Central Standard Time, rwjack...@firsthorizon.com writes: R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. I had serious discussion with some VIPs about it, approx 20 years ago (WTC attack). I had to explain we are starting DR centre with remote copy to protect against many disasters, BUT... Dedicated terrorist attack is unlikely, but when considered you cannot exclude coordinated attack on two (three) datacenters at the time. If you want to be safe you have to protect your datacenter well enough. And of course there is bigger bomb for bigger shelter. -- Radoslaw Skorupka Lodz, Poland == 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,http://secur
Re: Storage & tape question
No thanks, I'll leave that sort of thing to you; you're much better at it than I am. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, July 8, 2020 7:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question Feel free to answer off-topic, criticize unsaid sentences and be self-concvinced you are right while rest of the world is wrong. Have a fun. -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 13:53, Seymour J Metz pisze: > Whoosh! You're completely missing the point. It's a matter of basic > probability theory. Given N independent adverse scenarios with probabilities > Pn, the probability that none of them will happen is (1-P1)(1-P2)...(1-PN). > > But it's not my dog. Feel free to run without backups, as long as you don't > ask for sympathy when the balloon goes up. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > R.S. [r.skoru...@bremultibank.com.pl] > Sent: Wednesday, July 8, 2020 5:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > It has no value. > Terrorist attack is unlikely, but two terrorist attacks at the time are > more unlikely. Thousand terrorist attacks at the tima are even more > unlikely. > A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. > When you have two datacenters and tapes in shelter off-site ...it is > still just unlikely to have coordinated attack on all the locations at > the time, and it is just unlikely to have shelters strong enough. > More data locations? Fine, more bombs. > And it is quite likely some malevolent people would know the adresses of > the locations. > > If you think you can protect your data against unlikely events > (disaster, etc.)... > Or rather: if you think you know how to do it, despite of the costs - > you're simply WRONG. > There is always some level of protection. The level is not infinite and > *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably > high". > > > Side note: there are scenarios when achieving higher level of protection > is pointless. Let's assume ticket system for metro transportation > (buses) and ...war. Or ticket system for buses in Biloxi. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: >> A terrorist attack is unlikely. >> >> An earthquake is unlikely. >> >> A tornado is unlikely. >> >> A flood is unlikely. >> >> ... >> >> The more unlikely risks there are, the greater the odds that one of them >> will happen. If you don't have off site backups then your data are at risk, >> and when the balloon goes up it won't matter how unlikely the particular >> failure mode was. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> R.S. [r.skoru...@bremultibank.com.pl] >> Sent: Tuesday, July 7, 2020 10:59 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Storage & tape question >> >> W dniu 07.07.2020 o 16:52, Edward Finnell pisze: >>> 1200lbs Semtex make you realize what backups are for and where is your cold >>> site? >>> >>> In a message dated 7/7/2020 9:37:20 AM Central Standard Time, >>> rwjack...@firsthorizon.com writes: >>> R.S. is spot on: make backups. Because of the trauma from this one event, >>> we now have a three-way VTS grid, synchronous-mirrored SANs, and two >>> mainframes on the floor. >> I had serious discussion with some VIPs about it, approx 20 years ago >> (WTC attack). >> I had to explain we are starting DR centre with remote copy to protect >> against many disasters, BUT... >> Dedicated terrorist attack is unlikely, but when considered you cannot >> exclude coordinated attack on two (three) datacenters at the time. >> If you want to be safe you have to protect your datacenter well enough. >> And of course there is bigger bomb for bigger shelter. >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> > == Jeśli nie jesteś adresatem tej wiadomości: - powi
Re: Storage & tape question
Feel free to answer off-topic, criticize unsaid sentences and be self-concvinced you are right while rest of the world is wrong. Have a fun. -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 13:53, Seymour J Metz pisze: Whoosh! You're completely missing the point. It's a matter of basic probability theory. Given N independent adverse scenarios with probabilities Pn, the probability that none of them will happen is (1-P1)(1-P2)...(1-PN). But it's not my dog. Feel free to run without backups, as long as you don't ask for sympathy when the balloon goes up. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, July 8, 2020 5:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: A terrorist attack is unlikely. An earthquake is unlikely. A tornado is unlikely. A flood is unlikely. ... The more unlikely risks there are, the greater the odds that one of them will happen. If you don't have off site backups then your data are at risk, and when the balloon goes up it won't matter how unlikely the particular failure mode was. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Tuesday, July 7, 2020 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question W dniu 07.07.2020 o 16:52, Edward Finnell pisze: 1200lbs Semtex make you realize what backups are for and where is your cold site? In a message dated 7/7/2020 9:37:20 AM Central Standard Time, rwjack...@firsthorizon.com writes: R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. I had serious discussion with some VIPs about it, approx 20 years ago (WTC attack). I had to explain we are starting DR centre with remote copy to protect against many disasters, BUT... Dedicated terrorist attack is unlikely, but when considered you cannot exclude coordinated attack on two (three) datacenters at the time. If you want to be safe you have to protect your datacenter well enough. And of course there is bigger bomb for bigger shelter. -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 t
Re: [External] Re: Storage & tape question
Many times a new box is populated with back-end drives from the same "batch" of hardware, with the same MTBF. The result is that many drives will tend to fail about the same time. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Wednesday, July 8, 2020 3:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Storage & tape question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I would say it is not because of extra workload, but rather result of some "epidemic" - the reason which caused first drive failure also somehow affect other drives. Last, but not least array controler (electronics) is also suspected. My €0.02 -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 20:41, Pommier, Rex pisze: > Regarding the second disk failing while the first was rebuilding, I've heard > more than once that a second failure in a RAID array shortly after the first, > while the rebuild is happening is not that uncommon. Something about the > sudden extra stress on the rest of the drives in the RAID set due to their > ultra high utilization trying to get the failed drive rebuilt. Has anybody > else heard this? Is there documented validity to this assertion? > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of John McKown > Sent: Tuesday, July 7, 2020 8:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: Storage & tape question > > > > We had a similar problem occurs, long ago, with an actual SAN dasd array (for > Windows, not MVS). Weekend backup to physical tape aborted on a Sunday. The > Windows admin said "No problem, it's a RAID-5 array, I can fix it Monday > morning." A few hours later, a disk in the array failed. No problem, right? > Unfortunately, while the CE was on his way in to replace it, a second disk > failed. The array was destroyed. Management said to repair it and reload from > the Sunday backup and we'd be good. When the admin admitted that the backup > failed and he didn't go in, he was immediately terminated. * Now, > what are the chances that 2 drives in an array will fail within hours? I > don't know, but one thing many don't think about with a "new array" is that > all the drives are likely the same age and will start to fail (if they are) > about the same time. * > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == 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,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2F&data=02%7C01%7Callan.staller%40HCL.COM%7C9185a0f9c91e436167ad08d8231a382c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637297943541125481&sdata=5NBusdnjQN75qFgUXCmbyen4jlOXmnfPUSoQKxI98eY%3D&reserved=0, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 protec
Re: Storage & tape question
Improvements in technology do not mean that you should abandon good operational sense! You should always do backups. Using raid arrays to improve performance and uptime has nothing to do with prudent operational procedures. Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jul 8, 2020, at 7:53 AM, Seymour J Metz wrote: > > Whoosh! You're completely missing the point. It's a matter of basic > probability theory. Given N independent adverse scenarios with probabilities > Pn, the probability that none of them will happen is (1-P1)(1-P2)...(1-PN). > > But it's not my dog. Feel free to run without backups, as long as you don't > ask for sympathy when the balloon goes up. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > R.S. [r.skoru...@bremultibank.com.pl] > Sent: Wednesday, July 8, 2020 5:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > It has no value. > Terrorist attack is unlikely, but two terrorist attacks at the time are > more unlikely. Thousand terrorist attacks at the tima are even more > unlikely. > A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. > When you have two datacenters and tapes in shelter off-site ...it is > still just unlikely to have coordinated attack on all the locations at > the time, and it is just unlikely to have shelters strong enough. > More data locations? Fine, more bombs. > And it is quite likely some malevolent people would know the adresses of > the locations. > > If you think you can protect your data against unlikely events > (disaster, etc.)... > Or rather: if you think you know how to do it, despite of the costs - > you're simply WRONG. > There is always some level of protection. The level is not infinite and > *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably > high". > > > Side note: there are scenarios when achieving higher level of protection > is pointless. Let's assume ticket system for metro transportation > (buses) and ...war. Or ticket system for buses in Biloxi. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: >> A terrorist attack is unlikely. >> >> An earthquake is unlikely. >> >> A tornado is unlikely. >> >> A flood is unlikely. >> >> ... >> >> The more unlikely risks there are, the greater the odds that one of them >> will happen. If you don't have off site backups then your data are at risk, >> and when the balloon goes up it won't matter how unlikely the particular >> failure mode was. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> R.S. [r.skoru...@bremultibank.com.pl] >> Sent: Tuesday, July 7, 2020 10:59 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Storage & tape question >> >> W dniu 07.07.2020 o 16:52, Edward Finnell pisze: >>> 1200lbs Semtex make you realize what backups are for and where is your cold >>> site? >>> >>> In a message dated 7/7/2020 9:37:20 AM Central Standard Time, >>> rwjack...@firsthorizon.com writes: >>> R.S. is spot on: make backups. Because of the trauma from this one event, >>> we now have a three-way VTS grid, synchronous-mirrored SANs, and two >>> mainframes on the floor. >> I had serious discussion with some VIPs about it, approx 20 years ago >> (WTC attack). >> I had to explain we are starting DR centre with remote copy to protect >> against many disasters, BUT... >> Dedicated terrorist attack is unlikely, but when considered you cannot >> exclude coordinated attack on two (three) datacenters at the time. >> If you want to be safe you have to protect your datacenter well enough. >> And of course there is bigger bomb for bigger shelter. >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> > > > == > > 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 >
Re: Storage & tape question
Whoosh! You're completely missing the point. It's a matter of basic probability theory. Given N independent adverse scenarios with probabilities Pn, the probability that none of them will happen is (1-P1)(1-P2)...(1-PN). But it's not my dog. Feel free to run without backups, as long as you don't ask for sympathy when the balloon goes up. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Wednesday, July 8, 2020 5:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: > A terrorist attack is unlikely. > > An earthquake is unlikely. > > A tornado is unlikely. > > A flood is unlikely. > > ... > > The more unlikely risks there are, the greater the odds that one of them will > happen. If you don't have off site backups then your data are at risk, and > when the balloon goes up it won't matter how unlikely the particular failure > mode was. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > R.S. [r.skoru...@bremultibank.com.pl] > Sent: Tuesday, July 7, 2020 10:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > W dniu 07.07.2020 o 16:52, Edward Finnell pisze: >> 1200lbs Semtex make you realize what backups are for and where is your cold >> site? >> >> In a message dated 7/7/2020 9:37:20 AM Central Standard Time, >> rwjack...@firsthorizon.com writes: >> R.S. is spot on: make backups. Because of the trauma from this one event, >> we now have a three-way VTS grid, synchronous-mirrored SANs, and two >> mainframes on the floor. > I had serious discussion with some VIPs about it, approx 20 years ago > (WTC attack). > I had to explain we are starting DR centre with remote copy to protect > against many disasters, BUT... > Dedicated terrorist attack is unlikely, but when considered you cannot > exclude coordinated attack on two (three) datacenters at the time. > If you want to be safe you have to protect your datacenter well enough. > And of course there is bigger bomb for bigger shelter. > > -- > Radoslaw Skorupka > Lodz, Poland > == 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,http://secure-web.cisco.com/13KX_lN3BX68hjDkz_p4n7d0fTv9Fp_ITBuWYv8DIBKpGgFkMagtM8wSpgHfPmq6tk88sFd-uIGqeIL2MBsSvpMaK5ImTxrgLisXthU_q_390uLcCYUBOT6sK-6mWiT4OKa-g3LbB0DPvbYP5fIq0XfOV9G_J-Fa1_pJ2Du7c5bRNyxrv4lUoGXxZiaZkkaUZUIkQxXX-JwxaIJ0Rua7uDGfy5O_Sv8cZ5rAorWESCuH0xw05ipcwxhdAARehD2V_FmURK2Rl3dVTEXVU7_fnfk32zCAO0l0lO5T2Gvg_PlHMyVKgI3iioxxxNfYMCFCldUeX0K6TOYQdSTdkYKoIbG9BPC6YpLIQ1vpRF8F-GGVlsIRba_q9zEh96IgBWKeS-SNKIkPRuXNRyX6rRJpqQqE0V2kCzJ0r_EWi2V84kCLt-jxPnPD77rOV2-r2fOm6/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał za
Re: Storage & tape question
It has no value. Terrorist attack is unlikely, but two terrorist attacks at the time are more unlikely. Thousand terrorist attacks at the tima are even more unlikely. A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely. When you have two datacenters and tapes in shelter off-site ...it is still just unlikely to have coordinated attack on all the locations at the time, and it is just unlikely to have shelters strong enough. More data locations? Fine, more bombs. And it is quite likely some malevolent people would know the adresses of the locations. If you think you can protect your data against unlikely events (disaster, etc.)... Or rather: if you think you know how to do it, despite of the costs - you're simply WRONG. There is always some level of protection. The level is not infinite and *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably high". Side note: there are scenarios when achieving higher level of protection is pointless. Let's assume ticket system for metro transportation (buses) and ...war. Or ticket system for buses in Biloxi. -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 17:27, Seymour J Metz pisze: A terrorist attack is unlikely. An earthquake is unlikely. A tornado is unlikely. A flood is unlikely. ... The more unlikely risks there are, the greater the odds that one of them will happen. If you don't have off site backups then your data are at risk, and when the balloon goes up it won't matter how unlikely the particular failure mode was. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Tuesday, July 7, 2020 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question W dniu 07.07.2020 o 16:52, Edward Finnell pisze: 1200lbs Semtex make you realize what backups are for and where is your cold site? In a message dated 7/7/2020 9:37:20 AM Central Standard Time, rwjack...@firsthorizon.com writes: R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. I had serious discussion with some VIPs about it, approx 20 years ago (WTC attack). I had to explain we are starting DR centre with remote copy to protect against many disasters, BUT... Dedicated terrorist attack is unlikely, but when considered you cannot exclude coordinated attack on two (three) datacenters at the time. If you want to be safe you have to protect your datacenter well enough. And of course there is bigger bomb for bigger shelter. -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
W dniu 08.07.2020 o 00:40, Grant Taylor pisze: On 7/7/20 8:52 AM, R.S. wrote: Few words about RAID: RAID is more reliable than single disk. Assuming same reliablity of disk used in RAID. That starts to get questionable when you have more and more disks in a RAID array. That's why you DON'T HAVE more and more disks in RAID group. Note: dasd box is not single array. Usually it is group of arrays. Not to mention specific arrays made by Moshe Ianai, like XIV. Those arrays are more reliable with more disks. Typical dasd boxes use RAID5 4+1 or 7+1, so more disks mean more such groups, not more disks in the group. And again: single drive is less reliable than RAID5 composed from such disks. Note: a system consisting of N elements and probability of each element failiure is 1/N. Failure of any element cause system failure. Let's say N=100. Many people thinks such system will fail for sure. It is not true. For large values on N the probability of working system strives toward 1/e. It's a numbers game of how likely is it to have two drives fail in a RAID 5 or three drives fail in a RAID 6. I think somewhere around twenty drives and you're back down to, or below, the reliability of a single drive. See above. [snipped] -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
That was the case with HP SSDs, which I mentioned. SSD had error in microcode and all of them failed at the same moment. Link: https://www.bleepingcomputer.com/news/hardware/hp-warns-that-some-ssd-drives-will-fail-at-32-768-hours-of-use/ -- Radoslaw Skorupka Lodz, Poland W dniu 08.07.2020 o 00:25, Mike Schwab pisze: RAID with SSD is very susceptible to failure. The SSDs from the same batch will die at about the same number of writes. So be sure to check the number of bad blocks and do proactive replacement. Maybe space a week apart so the next set will give you some time. On Tue, Jul 7, 2020 at 2:52 PM R.S. wrote: Disclaimer: I HAVE NEVER SAID THAT. RAID is fallible. Everything is fallible. I used RAID rhetorically, just as example of "pretty good". And even then I urged to make backups. Few words about RAID: RAID is more reliable than single disk. Assuming same reliablity of disk used in RAID. RAID is more reliable when it has spare drives inside. No waiting for CE. Less time needed to start rebuild process. RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive failure of 2 drives within a group. The second reason is time to rebuild. The more capacious disk the more time is needed to rebuild. At this time there is no protection. Remote copy (PPRC, XRC, SRDF, HRC) is yet another level of protection. Disk failure will not be replicated. ;-) Side notes: Sometimes disk failure is not just isolated case. Sometimes it is a symptom of epidemic. What kind? Some of them: disk came form same lot, which is bad. Earthquake or just some accident in server room (someone hit the cabinet by accident ...and didn't reported it). Or microcode problem (search for HP SSD - horror story). Conclusion: when you observer disk failure, pay attention. It may be isolated case or FIRST failure you observe. Poor quality of the array. It is rather problem of entry level home devices, but it does happen. Some guy bought "cheap" raid box, there disks and ...one day the array failed. No data, accessible, similar raid box does not recognize anything on disks. Everything looks like new and working, but there is no data. Of course that person did not make any backup for obvious reason: he has RAID. This is real story. After that I observed more cases like this one. Obviously no support available. Just warranty, but "c'mon guy, ligths are blinking, you can format disks and used it - no failure". -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 15:18, Jackson, Rob pisze: Fun little note on RAID: it is fallible. The last Sunday of October 2016 I got a call bright and early because our VTS (TS7740) had shut down. Turns out we had a "cache" HDD failure at around 4 AM, and then a second one failed at around 7 AM, before the first one had been rebuilt on a spare. RAID-5 could not accommodate it. Because of IBM politics, we had no tape until Monday at 16:00. I am ashamed to say that I sort of took tape for granted. It was astonishing how much of our processing depended on it. R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, July 7, 2020 4:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Yes, it is possible to have VTS without real tapes on backend. Some vendors do offer only "tapeless tapes", with no option to connect real tape library. However from OS point of view there is difference between disk (DASD) and tape (offline storage). Price difference is also worth to consider, however I mean the logic. Even the biggest, cheapest and really huge DASD will not protect you form human and application (and other) errors. But backup will do it. That's why we do backups. We don't afraid of disk failure, because we have RAID, spare modules and possibly remote copy. However we do backups. If you insist on DASD, you may (theoretically) connect another DASD box dedicated for backups only. And even (logically) disconnect it between backup sessions. However it is IMHO worse version of VTS. Note: I do not discuss here things like price (initial, per terabyte), compression, thruput, scalability, RAID, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 06.07.2020 o 16:46, kekronbekron pisze: Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: I forgot something obvious for me: NEVER USE TAPES
Re: Storage & tape question
Rob, No problem. I just wanted to explain things. My english is far from fluent, so don't feel all the nuances. BTW: I was using RVA. Yes, it was RAID6. And we almost lost data ...not because of drive failure. It was some weird problem with controller. In short words, one disk "failed" (see below). No spare was used. No clear message was issued. Then second disk failed. The problem was "failure" was like Schrodingers cat: neither alive, nor dead. The disks were not on the list of healthy devices, but no disk was on the list of failed devices. Somehow permanent transient state. CE replaced disks. Took "failed" disks for analysis. After that she told me both disk look good and work OK. BTW2: RVA was very strange machine. I didn't like it. We had 18GB disk, but RVA used them as 4,5GB. It was sold as 500GB "effective capacity", but real capacity netto (after RAID) was 140GB. 500GB assumed compression ratio. However my coworker put there some non-compressible data and we got error when MVS data reached 140GB. So, your free space was somehow fictitious. Some manager wanted to check our storage and he counted disks. Of course multiplication number of disk x disk capacity gave something very different from official array parameters. And the IODF definitions were unusal. Nowadays every DASD box has single CU attached to devices with some redundancy under the cover. RVA had dual CU, like some old SLEDs. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 17:09, Jackson, Rob pisze: Settle down, R.S. I was agreeing with you, and I certainly wasn't putting words in your mouth. TS7740 definitely wasn't "cheap." Obviously it was flawed. I _think_ our TS7760s are described as RAID-S. I forget how that differs from RAID-6, though I know it's supposed to tolerate more than two disk failures per array. At risk of devolving into a long tangential thread, does anyone remember the RVA/SVA disk boxes? I believe they were RAID-6. I _know_ for a fact they were the first storage subsystems we had that didn't require a separate control unit. They were awesome. I want to say they were like 600 GB each. Wow, how times have changed. :) First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, July 7, 2020 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Disclaimer: I HAVE NEVER SAID THAT. RAID is fallible. Everything is fallible. I used RAID rhetorically, just as example of "pretty good". And even then I urged to make backups. Few words about RAID: RAID is more reliable than single disk. Assuming same reliablity of disk used in RAID. RAID is more reliable when it has spare drives inside. No waiting for CE. Less time needed to start rebuild process. RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive failure of 2 drives within a group. The second reason is time to rebuild. The more capacious disk the more time is needed to rebuild. At this time there is no protection. Remote copy (PPRC, XRC, SRDF, HRC) is yet another level of protection. Disk failure will not be replicated. ;-) Side notes: Sometimes disk failure is not just isolated case. Sometimes it is a symptom of epidemic. What kind? Some of them: disk came form same lot, which is bad. Earthquake or just some accident in server room (someone hit the cabinet by accident ...and didn't reported it). Or microcode problem (search for HP SSD - horror story). Conclusion: when you observer disk failure, pay attention. It may be isolated case or FIRST failure you observe. Poor quality of the array. It is rather problem of entry level home devices, but it does happen. Some guy bought "cheap" raid box, there disks and ...one day the array failed. No data, accessible, similar raid box does not recognize anything on disks. Everything looks like new and working, but there is no data. Of course that person did not make any backup for obvious reason: he has RAID. This is real story. After that I observed more cases like this one. Obviously no support available. Just warranty, but "c'mon guy, ligths are blinking, you can format disks and used it - no failure". -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 15:18, Jackson, Rob pisze: Fun little note on RAID: it is fallible. The last Sunday of October 2016 I got a call bright and early because our VTS (TS7740) had shut down. Turns out we had a "cache" HDD failure at around 4 AM, and then a second one failed at around 7 AM, before the first one had been rebuilt on a spare. RAID-5 could not accommodate it. Because of IBM politics, we had no tape until Monday at 16:00. I am ashamed to say that I sort of t
Re: [External] Re: Storage & tape question
I would say it is not because of extra workload, but rather result of some "epidemic" - the reason which caused first drive failure also somehow affect other drives. Last, but not least array controler (electronics) is also suspected. My €0.02 -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 20:41, Pommier, Rex pisze: Regarding the second disk failing while the first was rebuilding, I've heard more than once that a second failure in a RAID array shortly after the first, while the rebuild is happening is not that uncommon. Something about the sudden extra stress on the rest of the drives in the RAID set due to their ultra high utilization trying to get the failed drive rebuilt. Has anybody else heard this? Is there documented validity to this assertion? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, July 7, 2020 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Storage & tape question We had a similar problem occurs, long ago, with an actual SAN dasd array (for Windows, not MVS). Weekend backup to physical tape aborted on a Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix it Monday morning." A few hours later, a disk in the array failed. No problem, right? Unfortunately, while the CE was on his way in to replace it, a second disk failed. The array was destroyed. Management said to repair it and reload from the Sunday backup and we'd be good. When the admin admitted that the backup failed and he didn't go in, he was immediately terminated. * Now, what are the chances that 2 drives in an array will fail within hours? I don't know, but one thing many don't think about with a "new array" is that all the drives are likely the same age and will start to fail (if they are) about the same time. * The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Agreedwas just indicating that you could only do 2 at a time but that does leave you exposed. In reality, with raid 6 I would not replace anything until it failed, but would certainly not wait once the failure it notified. Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jul 7, 2020, at 7:08 PM, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 7/7/20 4:40 PM, Ken Bloom wrote: >> Side note, if you want to be proactive And replace drives preventatively, >> remember that for raid 5 you can only do one drive at a time, raid 6 2 >> drives, > > I would *STRONGLY* *DISCOURAGE* replacing two drives in a RAID 6 at the same > time. Doing so renders the array subject to a single drive failure causing > total loss. > > I *strongly* *suggest* only replacing one drive at a time in any given array. > Period. End of story. > > After all, if it's proactive, why do you /need/ to do it faster than one > drive at a time? > >> but you need to have insertable Hot spares Or you lose data and you can’t >> do the next set of drives until the new ones are rebuiltbottom line, >> it’s not efficient to do this. > > I would suggest that you not use your (cold|hot) spares pool for this > proactive drive replacement. Instead, purchase the new drive(s) when you are > ready to do the swap. > > > > -- > Grant. . . . > unix || die > > -- > 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
Re: Storage & tape question
On 7/7/20 4:40 PM, Ken Bloom wrote: Side note, if you want to be proactive And replace drives preventatively, remember that for raid 5 you can only do one drive at a time, raid 6 2 drives, I would *STRONGLY* *DISCOURAGE* replacing two drives in a RAID 6 at the same time. Doing so renders the array subject to a single drive failure causing total loss. I *strongly* *suggest* only replacing one drive at a time in any given array. Period. End of story. After all, if it's proactive, why do you /need/ to do it faster than one drive at a time? but you need to have insertable Hot spares Or you lose data and you can’t do the next set of drives until the new ones are rebuiltbottom line, it’s not efficient to do this. I would suggest that you not use your (cold|hot) spares pool for this proactive drive replacement. Instead, purchase the new drive(s) when you are ready to do the swap. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Storage & tape question
We have never seen that. We always use raid 6 for both our VTL AND DASD products with multiple hot spares. Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jul 7, 2020, at 6:31 PM, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 7/7/20 12:41 PM, Pommier, Rex wrote: >> Has anybody else heard this? > > I've heard of and have experienced this multiple times. > > The stress of rebuilding can push other marginal drives over the edge. > > This is why RAID with multiple parity drives is now critical. Especially with > larger and larger drives taking longer and longer to recover. > > I usually have two, sometimes three, parity drives. > > I know that they aren't dedicated parity drives any more and that the parity > and data is mixed on multiple drives. But calling them parity drives is > convenient. > > > > -- > Grant. . . . > unix || die > > -- > 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
Re: Storage & tape question
On 7/7/20 8:52 AM, R.S. wrote: Few words about RAID: RAID is more reliable than single disk. Assuming same reliablity of disk used in RAID. That starts to get questionable when you have more and more disks in a RAID array. It's a numbers game of how likely is it to have two drives fail in a RAID 5 or three drives fail in a RAID 6. I think somewhere around twenty drives and you're back down to, or below, the reliability of a single drive. RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive failure of 2 drives within a group. The second reason is time to rebuild. The more capacious disk the more time is needed to rebuild. At this time there is no protection. This is why I like RAID 6. I like to always have another unused safety net, even when one drive has failed and we're relying on the 1st safety. Side notes: Sometimes disk failure is not just isolated case. Sometimes it is a symptom of epidemic. What kind? Some of them: disk came form same lot, which is bad. Earthquake or just some accident in server room (someone hit the cabinet by accident ...and didn't reported it). Or microcode problem (search for HP SSD - horror story). Or very loud noises within specific frequency ranges. Fire suppression systems come to mind. Conclusion: when you observer disk failure, pay attention. It may be isolated case or FIRST failure you observe. Yep. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Mike It depends on the size of the Arrays and the type of SSD’s being used. Enterprise level SSD’s Are mixed read / Write with at least 3DRPD (disk writes per day) performance should last at least 5 years or more. We have not seen other than sporadic failures in both HDD AND SSD and certainly not mass failures within a few weeks time of the first failure. The real issue is to make sure you have enough hot spares that are auto inserted into the array, use RAID 6 that can tolerate multiple drive failures and have diagnostics that report a drive failure quickly and DO NOT IGNOR the report of a failure with a quick replacement. Side note, if you want to be proactive And replace drives preventatively, remember that for raid 5 you can only do one drive at a time, raid 6 2 drives, but you need to have insertable Hot spares Or you lose data and you can’t do the next set of drives until the new ones are rebuiltbottom line, it’s not efficient to do this. Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jul 7, 2020, at 6:25 PM, Mike Schwab wrote: > > RAID with SSD is very susceptible to failure. The SSDs from the same > batch will die at about the same number of writes. So be sure to > check the number of bad blocks and do proactive replacement. Maybe > space a week apart so the next set will give you some time. > >> On Tue, Jul 7, 2020 at 2:52 PM R.S. wrote: >> >> Disclaimer: I HAVE NEVER SAID THAT. >> RAID is fallible. Everything is fallible. >> I used RAID rhetorically, just as example of "pretty good". >> And even then I urged to make backups. >> >> Few words about RAID: >> RAID is more reliable than single disk. Assuming same reliablity of disk >> used in RAID. >> >> RAID is more reliable when it has spare drives inside. No waiting for >> CE. Less time needed to start rebuild process. >> >> RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive >> failure of 2 drives within a group. The second reason is time to >> rebuild. The more capacious disk the more time is needed to rebuild. At >> this time there is no protection. >> >> Remote copy (PPRC, XRC, SRDF, HRC) is yet another level of protection. >> Disk failure will not be replicated. ;-) >> >> Side notes: >> Sometimes disk failure is not just isolated case. Sometimes it is a >> symptom of epidemic. What kind? Some of them: disk came form same lot, >> which is bad. Earthquake or just some accident in server room (someone >> hit the cabinet by accident ...and didn't reported it). Or microcode >> problem (search for HP SSD - horror story). >> Conclusion: when you observer disk failure, pay attention. It may be >> isolated case or FIRST failure you observe. >> >> Poor quality of the array. It is rather problem of entry level home >> devices, but it does happen. Some guy bought "cheap" raid box, there >> disks and ...one day the array failed. No data, accessible, similar raid >> box does not recognize anything on disks. Everything looks like new and >> working, but there is no data. Of course that person did not make any >> backup for obvious reason: he has RAID. This is real story. After that I >> observed more cases like this one. Obviously no support available. Just >> warranty, but "c'mon guy, ligths are blinking, you can format disks and >> used it - no failure". >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> >> >> >> >> >> >> W dniu 07.07.2020 o 15:18, Jackson, Rob pisze: >>> Fun little note on RAID: it is fallible. The last Sunday of October 2016 >>> I got a call bright and early because our VTS (TS7740) had shut down. >>> Turns out we had a "cache" HDD failure at around 4 AM, and then a second >>> one failed at around 7 AM, before the first one had been rebuilt on a >>> spare. RAID-5 could not accommodate it. Because of IBM politics, we had >>> no tape until Monday at 16:00. I am ashamed to say that I sort of took >>> tape for granted. It was astonishing how much of our processing depended >>> on it. >>> >>> R.S. is spot on: make backups. Because of the trauma from this one event, >>> we now have a three-way VTS grid, synchronous-mirrored SANs, and two >>> mainframes on the floor. >>> >>> First Horizon Bank >>> Mainframe Technical Support >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On Behalf Of >>> R.S. >>> Sent:
Re: [External] Re: Storage & tape question
On 7/7/20 12:41 PM, Pommier, Rex wrote: Has anybody else heard this? I've heard of and have experienced this multiple times. The stress of rebuilding can push other marginal drives over the edge. This is why RAID with multiple parity drives is now critical. Especially with larger and larger drives taking longer and longer to recover. I usually have two, sometimes three, parity drives. I know that they aren't dedicated parity drives any more and that the parity and data is mixed on multiple drives. But calling them parity drives is convenient. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
RAID with SSD is very susceptible to failure. The SSDs from the same batch will die at about the same number of writes. So be sure to check the number of bad blocks and do proactive replacement. Maybe space a week apart so the next set will give you some time. On Tue, Jul 7, 2020 at 2:52 PM R.S. wrote: > > Disclaimer: I HAVE NEVER SAID THAT. > RAID is fallible. Everything is fallible. > I used RAID rhetorically, just as example of "pretty good". > And even then I urged to make backups. > > Few words about RAID: > RAID is more reliable than single disk. Assuming same reliablity of disk > used in RAID. > > RAID is more reliable when it has spare drives inside. No waiting for > CE. Less time needed to start rebuild process. > > RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive > failure of 2 drives within a group. The second reason is time to > rebuild. The more capacious disk the more time is needed to rebuild. At > this time there is no protection. > > Remote copy (PPRC, XRC, SRDF, HRC) is yet another level of protection. > Disk failure will not be replicated. ;-) > > Side notes: > Sometimes disk failure is not just isolated case. Sometimes it is a > symptom of epidemic. What kind? Some of them: disk came form same lot, > which is bad. Earthquake or just some accident in server room (someone > hit the cabinet by accident ...and didn't reported it). Or microcode > problem (search for HP SSD - horror story). > Conclusion: when you observer disk failure, pay attention. It may be > isolated case or FIRST failure you observe. > > Poor quality of the array. It is rather problem of entry level home > devices, but it does happen. Some guy bought "cheap" raid box, there > disks and ...one day the array failed. No data, accessible, similar raid > box does not recognize anything on disks. Everything looks like new and > working, but there is no data. Of course that person did not make any > backup for obvious reason: he has RAID. This is real story. After that I > observed more cases like this one. Obviously no support available. Just > warranty, but "c'mon guy, ligths are blinking, you can format disks and > used it - no failure". > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 07.07.2020 o 15:18, Jackson, Rob pisze: > > Fun little note on RAID: it is fallible. The last Sunday of October 2016 > > I got a call bright and early because our VTS (TS7740) had shut down. > > Turns out we had a "cache" HDD failure at around 4 AM, and then a second > > one failed at around 7 AM, before the first one had been rebuilt on a > > spare. RAID-5 could not accommodate it. Because of IBM politics, we had > > no tape until Monday at 16:00. I am ashamed to say that I sort of took > > tape for granted. It was astonishing how much of our processing depended > > on it. > > > > R.S. is spot on: make backups. Because of the trauma from this one event, > > we now have a three-way VTS grid, synchronous-mirrored SANs, and two > > mainframes on the floor. > > > > First Horizon Bank > > Mainframe Technical Support > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > R.S. > > Sent: Tuesday, July 7, 2020 4:36 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Storage & tape question > > > > [External Email. Exercise caution when clicking links or opening > > attachments.] > > > > Yes, it is possible to have VTS without real tapes on backend. Some vendors > > do offer only "tapeless tapes", with no option to connect real tape library. > > However from OS point of view there is difference between disk (DASD) and > > tape (offline storage). > > Price difference is also worth to consider, however I mean the logic. > > Even the biggest, cheapest and really huge DASD will not protect you form > > human and application (and other) errors. But backup will do it. > > That's why we do backups. We don't afraid of disk failure, because we have > > RAID, spare modules and possibly remote copy. However we do backups. > > If you insist on DASD, you may (theoretically) connect another DASD box > > dedicated for backups only. And even (logically) disconnect it between > > backup sessions. However it is IMHO worse version of VTS. > > > > Note: I do not discuss here things like price (initial, per terabyte), > > compression, thruput, scalability, RAID, etc. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > > &
Re: Storage & tape question
One company had computer centers in two cities. Hurricane Katrina was coming, so the work was transferred from Miami to New Orleans. Miami took quite a while to come back up. On Tue, Jul 7, 2020 at 3:28 PM Joe Monk wrote: > > In Houston, Texas, a hurricane is VERY likely. > > Joe > > On Tue, Jul 7, 2020 at 10:27 AM Seymour J Metz wrote: > > > A terrorist attack is unlikely. > > > > An earthquake is unlikely. > > > > A tornado is unlikely. > > > > A flood is unlikely. > > > > ... > > > > The more unlikely risks there are, the greater the odds that one of them > > will happen. If you don't have off site backups then your data are at risk, > > and when the balloon goes up it won't matter how unlikely the particular > > failure mode was. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of R.S. [r.skoru...@bremultibank.com.pl] > > Sent: Tuesday, July 7, 2020 10:59 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Storage & tape question > > > > W dniu 07.07.2020 o 16:52, Edward Finnell pisze: > > > 1200lbs Semtex make you realize what backups are for and where is your > > cold site? > > > > > > In a message dated 7/7/2020 9:37:20 AM Central Standard Time, > > rwjack...@firsthorizon.com writes: > > > R.S. is spot on: make backups. Because of the trauma from this one > > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two > > mainframes on the floor. > > > > I had serious discussion with some VIPs about it, approx 20 years ago > > (WTC attack). > > I had to explain we are starting DR centre with remote copy to protect > > against many disasters, BUT... > > Dedicated terrorist attack is unlikely, but when considered you cannot > > exclude coordinated attack on two (three) datacenters at the time. > > If you want to be safe you have to protect your datacenter well enough. > > And of course there is bigger bomb for bigger shelter. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > == > > > > 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, > > http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, > > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > > 01.01.2020 r. wynosi 169.401.468 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, > > http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONR
Re: [External] Re: Storage & tape question
Regarding the second disk failing while the first was rebuilding, I've heard more than once that a second failure in a RAID array shortly after the first, while the rebuild is happening is not that uncommon. Something about the sudden extra stress on the rest of the drives in the RAID set due to their ultra high utilization trying to get the failed drive rebuilt. Has anybody else heard this? Is there documented validity to this assertion? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, July 7, 2020 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Storage & tape question We had a similar problem occurs, long ago, with an actual SAN dasd array (for Windows, not MVS). Weekend backup to physical tape aborted on a Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix it Monday morning." A few hours later, a disk in the array failed. No problem, right? Unfortunately, while the CE was on his way in to replace it, a second disk failed. The array was destroyed. Management said to repair it and reload from the Sunday backup and we'd be good. When the admin admitted that the backup failed and he didn't go in, he was immediately terminated. * Now, what are the chances that 2 drives in an array will fail within hours? I don't know, but one thing many don't think about with a "new array" is that all the drives are likely the same age and will start to fail (if they are) about the same time. * The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
On Tue, Jul 7, 2020 at 10:33 AM Seymour J Metz wrote: > Indeed, but data centers have also been taken down by events that were > unlikely. Even paranoids have real enemies when it comes to backup > strategies. > Surely we all remember when this list was down due to a "suicide squarrel" attack on the transformer near the university. > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
The biggest whomp I heard about was at Midwestern data-center. Highway department dropped a load of ammonium nitrate to widen the Interstate. Over the weekend lightning hit the trailer and kaboom-ed 32k lbs. It was about halfway between primary and secondary data centers. Knocked out the bearings on all their SLEDs at both sites. Saw them at a tuning conference a few weeks later and they still looked like zombies. There was a neat presentation at SHARE by one of the paint companies in the Susquehanna Valley about single point of failure. I forget all the details but again highway department knocked off the side of a cliff. It had their freshly run fiber between Headquarters, data center and backup. Nothing was damaged but the fiber. They just couldn't talk to each other. Ended up running fiber over an abandoned railroad trestle. One of the sysprogs was a climber and had him upside down repelling over the river. In a message dated 7/7/2020 9:59:38 AM Central Standard Time, r.skoru...@bremultibank.com.pl writes: Dedicated terrorist attack is unlikely, but when considered you cannot exclude coordinated attack on two (three) datacenters at the time. If you want to be safe you have to protect your datacenter well enough. And of course there is bigger bomb for bigger shelter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Indeed, but data centers have also been taken down by events that were unlikely. Even paranoids have real enemies when it comes to backup strategies. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Tuesday, July 7, 2020 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question In Houston, Texas, a hurricane is VERY likely. Joe On Tue, Jul 7, 2020 at 10:27 AM Seymour J Metz wrote: > A terrorist attack is unlikely. > > An earthquake is unlikely. > > A tornado is unlikely. > > A flood is unlikely. > > ... > > The more unlikely risks there are, the greater the odds that one of them > will happen. If you don't have off site backups then your data are at risk, > and when the balloon goes up it won't matter how unlikely the particular > failure mode was. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of R.S. [r.skoru...@bremultibank.com.pl] > Sent: Tuesday, July 7, 2020 10:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > W dniu 07.07.2020 o 16:52, Edward Finnell pisze: > > 1200lbs Semtex make you realize what backups are for and where is your > cold site? > > > > In a message dated 7/7/2020 9:37:20 AM Central Standard Time, > rwjack...@firsthorizon.com writes: > > R.S. is spot on: make backups. Because of the trauma from this one > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two > mainframes on the floor. > > I had serious discussion with some VIPs about it, approx 20 years ago > (WTC attack). > I had to explain we are starting DR centre with remote copy to protect > against many disasters, BUT... > Dedicated terrorist attack is unlikely, but when considered you cannot > exclude coordinated attack on two (three) datacenters at the time. > If you want to be safe you have to protect your datacenter well enough. > And of course there is bigger bomb for bigger shelter. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > 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, > http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 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, > http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. District Court
Re: Storage & tape question
In Houston, Texas, a hurricane is VERY likely. Joe On Tue, Jul 7, 2020 at 10:27 AM Seymour J Metz wrote: > A terrorist attack is unlikely. > > An earthquake is unlikely. > > A tornado is unlikely. > > A flood is unlikely. > > ... > > The more unlikely risks there are, the greater the odds that one of them > will happen. If you don't have off site backups then your data are at risk, > and when the balloon goes up it won't matter how unlikely the particular > failure mode was. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of R.S. [r.skoru...@bremultibank.com.pl] > Sent: Tuesday, July 7, 2020 10:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > W dniu 07.07.2020 o 16:52, Edward Finnell pisze: > > 1200lbs Semtex make you realize what backups are for and where is your > cold site? > > > > In a message dated 7/7/2020 9:37:20 AM Central Standard Time, > rwjack...@firsthorizon.com writes: > > R.S. is spot on: make backups. Because of the trauma from this one > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two > mainframes on the floor. > > I had serious discussion with some VIPs about it, approx 20 years ago > (WTC attack). > I had to explain we are starting DR centre with remote copy to protect > against many disasters, BUT... > Dedicated terrorist attack is unlikely, but when considered you cannot > exclude coordinated attack on two (three) datacenters at the time. > If you want to be safe you have to protect your datacenter well enough. > And of course there is bigger bomb for bigger shelter. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > 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, > http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 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, > http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, > 12th Commercial Division of the National Court Register, KRS 025237, > NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN > 169.401.468 as at 1 January 2020. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >
Re: Storage & tape question
A terrorist attack is unlikely. An earthquake is unlikely. A tornado is unlikely. A flood is unlikely. ... The more unlikely risks there are, the greater the odds that one of them will happen. If you don't have off site backups then your data are at risk, and when the balloon goes up it won't matter how unlikely the particular failure mode was. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Tuesday, July 7, 2020 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question W dniu 07.07.2020 o 16:52, Edward Finnell pisze: > 1200lbs Semtex make you realize what backups are for and where is your cold > site? > > In a message dated 7/7/2020 9:37:20 AM Central Standard Time, > rwjack...@firsthorizon.com writes: > R.S. is spot on: make backups. Because of the trauma from this one event, > we now have a three-way VTS grid, synchronous-mirrored SANs, and two > mainframes on the floor. I had serious discussion with some VIPs about it, approx 20 years ago (WTC attack). I had to explain we are starting DR centre with remote copy to protect against many disasters, BUT... Dedicated terrorist attack is unlikely, but when considered you cannot exclude coordinated attack on two (three) datacenters at the time. If you want to be safe you have to protect your datacenter well enough. And of course there is bigger bomb for bigger shelter. -- Radoslaw Skorupka Lodz, Poland == 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,http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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,http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- 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
Re: Storage & tape question
Settle down, R.S. I was agreeing with you, and I certainly wasn't putting words in your mouth. TS7740 definitely wasn't "cheap." Obviously it was flawed. I _think_ our TS7760s are described as RAID-S. I forget how that differs from RAID-6, though I know it's supposed to tolerate more than two disk failures per array. At risk of devolving into a long tangential thread, does anyone remember the RVA/SVA disk boxes? I believe they were RAID-6. I _know_ for a fact they were the first storage subsystems we had that didn't require a separate control unit. They were awesome. I want to say they were like 600 GB each. Wow, how times have changed. :) First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, July 7, 2020 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Disclaimer: I HAVE NEVER SAID THAT. RAID is fallible. Everything is fallible. I used RAID rhetorically, just as example of "pretty good". And even then I urged to make backups. Few words about RAID: RAID is more reliable than single disk. Assuming same reliablity of disk used in RAID. RAID is more reliable when it has spare drives inside. No waiting for CE. Less time needed to start rebuild process. RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive failure of 2 drives within a group. The second reason is time to rebuild. The more capacious disk the more time is needed to rebuild. At this time there is no protection. Remote copy (PPRC, XRC, SRDF, HRC) is yet another level of protection. Disk failure will not be replicated. ;-) Side notes: Sometimes disk failure is not just isolated case. Sometimes it is a symptom of epidemic. What kind? Some of them: disk came form same lot, which is bad. Earthquake or just some accident in server room (someone hit the cabinet by accident ...and didn't reported it). Or microcode problem (search for HP SSD - horror story). Conclusion: when you observer disk failure, pay attention. It may be isolated case or FIRST failure you observe. Poor quality of the array. It is rather problem of entry level home devices, but it does happen. Some guy bought "cheap" raid box, there disks and ...one day the array failed. No data, accessible, similar raid box does not recognize anything on disks. Everything looks like new and working, but there is no data. Of course that person did not make any backup for obvious reason: he has RAID. This is real story. After that I observed more cases like this one. Obviously no support available. Just warranty, but "c'mon guy, ligths are blinking, you can format disks and used it - no failure". -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 15:18, Jackson, Rob pisze: > Fun little note on RAID: it is fallible. The last Sunday of October 2016 I > got a call bright and early because our VTS (TS7740) had shut down. Turns > out we had a "cache" HDD failure at around 4 AM, and then a second one failed > at around 7 AM, before the first one had been rebuilt on a spare. RAID-5 > could not accommodate it. Because of IBM politics, we had no tape until > Monday at 16:00. I am ashamed to say that I sort of took tape for granted. > It was astonishing how much of our processing depended on it. > > R.S. is spot on: make backups. Because of the trauma from this one event, > we now have a three-way VTS grid, synchronous-mirrored SANs, and two > mainframes on the floor. > > First Horizon Bank > Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: Tuesday, July 7, 2020 4:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > [External Email. Exercise caution when clicking links or opening > attachments.] > > Yes, it is possible to have VTS without real tapes on backend. Some vendors > do offer only "tapeless tapes", with no option to connect real tape library. > However from OS point of view there is difference between disk (DASD) and > tape (offline storage). > Price difference is also worth to consider, however I mean the logic. > Even the biggest, cheapest and really huge DASD will not protect you form > human and application (and other) errors. But backup will do it. > That's why we do backups. We don't afraid of disk failure, because we have > RAID, spare modules and possibly remote copy. However we do backups. > If you insist on DASD, you may (theoretically) connect another DASD box > dedicated for backups only. And even (logically) disconnect it between backup > sessions. However it is IMHO worse ve
Re: Storage & tape question
W dniu 07.07.2020 o 16:52, Edward Finnell pisze: 1200lbs Semtex make you realize what backups are for and where is your cold site? In a message dated 7/7/2020 9:37:20 AM Central Standard Time, rwjack...@firsthorizon.com writes: R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. I had serious discussion with some VIPs about it, approx 20 years ago (WTC attack). I had to explain we are starting DR centre with remote copy to protect against many disasters, BUT... Dedicated terrorist attack is unlikely, but when considered you cannot exclude coordinated attack on two (three) datacenters at the time. If you want to be safe you have to protect your datacenter well enough. And of course there is bigger bomb for bigger shelter. -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
1200lbs Semtex make you realize what backups are for and where is your cold site? In a message dated 7/7/2020 9:37:20 AM Central Standard Time, rwjack...@firsthorizon.com writes: R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Disclaimer: I HAVE NEVER SAID THAT. RAID is fallible. Everything is fallible. I used RAID rhetorically, just as example of "pretty good". And even then I urged to make backups. Few words about RAID: RAID is more reliable than single disk. Assuming same reliablity of disk used in RAID. RAID is more reliable when it has spare drives inside. No waiting for CE. Less time needed to start rebuild process. RAID6 is more reliable than RAID5. Reasons: Data on RAID6 will survive failure of 2 drives within a group. The second reason is time to rebuild. The more capacious disk the more time is needed to rebuild. At this time there is no protection. Remote copy (PPRC, XRC, SRDF, HRC) is yet another level of protection. Disk failure will not be replicated. ;-) Side notes: Sometimes disk failure is not just isolated case. Sometimes it is a symptom of epidemic. What kind? Some of them: disk came form same lot, which is bad. Earthquake or just some accident in server room (someone hit the cabinet by accident ...and didn't reported it). Or microcode problem (search for HP SSD - horror story). Conclusion: when you observer disk failure, pay attention. It may be isolated case or FIRST failure you observe. Poor quality of the array. It is rather problem of entry level home devices, but it does happen. Some guy bought "cheap" raid box, there disks and ...one day the array failed. No data, accessible, similar raid box does not recognize anything on disks. Everything looks like new and working, but there is no data. Of course that person did not make any backup for obvious reason: he has RAID. This is real story. After that I observed more cases like this one. Obviously no support available. Just warranty, but "c'mon guy, ligths are blinking, you can format disks and used it - no failure". -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 15:18, Jackson, Rob pisze: Fun little note on RAID: it is fallible. The last Sunday of October 2016 I got a call bright and early because our VTS (TS7740) had shut down. Turns out we had a "cache" HDD failure at around 4 AM, and then a second one failed at around 7 AM, before the first one had been rebuilt on a spare. RAID-5 could not accommodate it. Because of IBM politics, we had no tape until Monday at 16:00. I am ashamed to say that I sort of took tape for granted. It was astonishing how much of our processing depended on it. R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, July 7, 2020 4:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Yes, it is possible to have VTS without real tapes on backend. Some vendors do offer only "tapeless tapes", with no option to connect real tape library. However from OS point of view there is difference between disk (DASD) and tape (offline storage). Price difference is also worth to consider, however I mean the logic. Even the biggest, cheapest and really huge DASD will not protect you form human and application (and other) errors. But backup will do it. That's why we do backups. We don't afraid of disk failure, because we have RAID, spare modules and possibly remote copy. However we do backups. If you insist on DASD, you may (theoretically) connect another DASD box dedicated for backups only. And even (logically) disconnect it between backup sessions. However it is IMHO worse version of VTS. Note: I do not discuss here things like price (initial, per terabyte), compression, thruput, scalability, RAID, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 06.07.2020 o 16:46, kekronbekron pisze: Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. No jobs should write or read tapes. Nothing except backup and restore and (optionally) ML2. Managed by HSM or FDR. Some excepions for archive copies are worth to consider. Note: you may have 15 years old backup
Re: Storage & tape question
On Tue, Jul 7, 2020 at 9:05 AM Joe Monk wrote: > Most ORGs are abandoning RAID-5 in favor of better like RAID-6. Any DASD > array should be engineered with two hot spares and call home service to the > vendor for drive replacement. > I agree. But our z/OS DASD is a very old 2105(?) which I doubt implements RAID-6. We have, and still are, going away very soon (10+ years so far) so management doesn't consider it reasonable to invest any money in any z/OS related hardware or software (we're z/OS 1.12 on a z9BC) > Joe > > On Tue, Jul 7, 2020 at 8:58 AM John McKown > wrote: > > > On Tue, Jul 7, 2020 at 8:19 AM Jackson, Rob > > wrote: > > > > > Fun little note on RAID: it is fallible. The last Sunday of October > > 2016 > > > I got a call bright and early because our VTS (TS7740) had shut down. > > > Turns out we had a "cache" HDD failure at around 4 AM, and then a > second > > > one failed at around 7 AM, before the first one had been rebuilt on a > > > spare. RAID-5 could not accommodate it. Because of IBM politics, we > had > > > no tape until Monday at 16:00. I am ashamed to say that I sort of took > > > tape for granted. It was astonishing how much of our processing > depended > > > on it. > > > > > > > We had a similar problem occurs, long ago, with an actual SAN dasd array > > (for Windows, not MVS). Weekend backup to physical tape aborted on a > > Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can > fix > > it Monday morning." A few hours later, a disk in the array failed. No > > problem, right? Unfortunately, while the CE was on his way in to replace > > it, a second disk failed. The array was destroyed. Management said to > > repair it and reload from the Sunday backup and we'd be good. When the > > admin admitted that the backup failed and he didn't go in, he was > > immediately terminated. Now, what are the chances that 2 drives in an > array > > will fail within hours? I don't know, but one thing many don't think > about > > with a "new array" is that all the drives are likely the same age and > will > > start to fail (if they are) about the same time. > > > > IMO, given my paranoia, I firmly believe that the disks in an array > should > > be replaced on a scheduled basis. I also believe in dual tape copies of > > important tapes. And also, that tapes in "long term" retention (we have > > tapes which have been at Iron Mountain for over 10 years!) should be > > brought in and the data copied to a new (not reused) tape annually. Of > > course, the bean counters will have an apoplectic fit and scream about > how > > much it costs to do this. They only understand cost, not value. I > consider > > them the bane of existence. Likely auditors, they take on too much > > authority. Or as I have heard: Fire is a good servant but a terrible > > master. > > > > > > > > > > > > R.S. is spot on: make backups. Because of the trauma from this one > > > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and > > two > > > mainframes on the floor. > > > > > > First Horizon Bank > > > Mainframe Technical Support > > > > > > > > -- > > People in sleeping bags are the soft tacos of the bear world. > > Maranatha! <>< > > John McKown > > > > -- > > 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 > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Hi KB, IBM-MAIN is great. There are shops that are all primary disk. Just make sure that you are aware of all of the considerations before going down that route. (The ones that I'm aware of are still HSM users to take advantage of ML1, class transitions, and backup). A few responses to your follow-on questions... Hi, Thank you for the detailed response Glenn, IBM-MAIN is truly amazing. > Migrate/Archive > The three purposes of HSM migration are to 1) compress the data so that the > footprint is smaller, 2) move it to a lower cost media so that the TCO is > lower and 3) move the data to an offline media that doesn't consume online > UCBs. When considering bringing all of your data back online, you need to > consider the impact of all three. 1) Assuming 3:1 compaction, you'll need 3x > the online storage. With zEDC, that will vary on both what you can get on the > primary storage and the ML2 storage. 3) For larger shops, the number on > online UCBs is a factor. It's not a factor for smaller shops. - 1) Compression - wouldn't it be enough to rely on z15 on-chip compression + the compression/dedupe done by the storage array itself? Sure, it may not be 3:1.. but worth evaluating? If the array itself is doing C+D, then "rehydrating" the data isn't a problem I believe? >> Glenn: z15 compression can be utilized for nonVSAM, not VSAM. >> Compression/Dedup are generally provided by offline storage systems or those >> that emulate them (like virtual tape). Dedupe is generally too slow for >> primary storage. I'm not aware of compression capabilities on primary >> storage. If you are currently deduping your backup copies, then they will >> take even more storage when they are moved to primary disk unless you can >> utilize a backup solution that does software based dedup and targets disk. 2) It's not just the storage cost though right.. (cost of a bunch of disk, S&S) vs (cost of tape emulation, physical carts, bandwidth, S&S, HSM's direct & indirect costs) >>Glenn: agreed. TCO has to be considered 3) Ok, the UCB thing can be problematic for big shops, agreed. There's only so much you can do with 3390-54 (are bigger volumes coming anytime soon?). >>Glenn. DFSMS currently supports EAV 1TB volumes. > Another thing to consider with an all disk environment is your 'relief > valve'. It's simple to migrate data to tape as a means of ensuring that you > always have enough space on your primary storage for growth. If you only have > primary storage, what is your exception handling case when you have > unexpected growth and no migration tiers to which to move your inactive data? > How quickly can you bring more primary storage online? Sorry, I know it sounds silly when I keep saying 'assume x/y/z is already catered to', but ... assuming primary storage provisioning is no longer a problem (apart from the UCBs mentioned above). > Another option is DS8000 transparent cloud tiering. This enables you to > migrate inactive data to cloud object storage, with minimal cpu since the > DS8K is doing the data movement. If not a primary means of migrating data, it > is a very good option for a 'relief valve'. Hmm... the two whole approaches (all-primary vs standard procedure) need to costed out and compared to be impartial to either case. > Backup > Regardless of the replication technique that you are using > (synchronous/asynchronous), you need point-in-time copies of your data for > logical corruption protection. If a data set is accidentally or maliciously > deleted, replication quickly deletes it from all copies. Also, if data > becomes logically corrupted, it is instantly corrupted in all copies. So, you > have to have a point-in-time backup technique for all of your data. You need > as many copies as you want recovery points. One copy doesn't give you much > security. Keeping n copies on disk can get pricey and consume alot of > storage. Also, you need to replicate the n PiT copies to all of your sites so > that you can do a logical recovery after a physical fail over. This makes the > cost add up even more quickly. TCT is another good option for this. You can > keep 1 or 2 copies on disk and then have HSM migrate/expire the older backup > copies to cloud object storage which is then available at all of your > recovery sites. If we consider that the storage array has *proper* support for multi-site, snapshots/PiTs, etc. ... again not problematic. Fully understand I may be dreaming about such a primary storage, it's good to know the technical constraints against it. - KB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Storage & tape question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, July 7, 2020 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Storage & tape question On Tue, Jul 7, 2020 at 8:19 AM Jackson, Rob wrote: > Fun little note on RAID: it is fallible. The last Sunday of October > 2016 I got a call bright and early because our VTS (TS7740) had shut down. > Turns out we had a "cache" HDD failure at around 4 AM, and then a > second one failed at around 7 AM, before the first one had been > rebuilt on a spare. RAID-5 could not accommodate it. Because of IBM > politics, we had no tape until Monday at 16:00. I am ashamed to say > that I sort of took tape for granted. It was astonishing how much of > our processing depended on it. > We had a similar problem occurs, long ago, with an actual SAN dasd array (for Windows, not MVS). Weekend backup to physical tape aborted on a Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix it Monday morning." A few hours later, a disk in the array failed. No problem, right? Unfortunately, while the CE was on his way in to replace it, a second disk failed. The array was destroyed. Management said to repair it and reload from the Sunday backup and we'd be good. When the admin admitted that the backup failed and he didn't go in, he was immediately terminated. Now, what are the chances that 2 drives in an array will fail within hours? I don't know, but one thing many don't think about with a "new array" is that all the drives are likely the same age and will start to fail (if they are) about the same time. IMO, given my paranoia, I firmly believe that the disks in an array should be replaced on a scheduled basis. I also believe in dual tape copies of important tapes. And also, that tapes in "long term" retention (we have tapes which have been at Iron Mountain for over 10 years!) should be brought in and the data copied to a new (not reused) tape annually. Of course, the bean counters will have an apoplectic fit and scream about how much it costs to do this. They only understand cost, not value. I consider them the bane of existence. Likely auditors, they take on too much authority. Or as I have heard: Fire is a good servant but a terrible master. That was one of the features of the old RVA/SVA array and why I wish IBM would have followed through on the ?rumor? that the XIV was going to have FICON and CKD emulation added to it. The scatter loading of data allowed for very fast rebuilds of failed HDAs to minimize the potential for a second HDA failing taking either the entire array or a cluster of disks out. Alas it didn't happen, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Most ORGs are abandoning RAID-5 in favor of better like RAID-6. Any DASD array should be engineered with two hot spares and call home service to the vendor for drive replacement. Joe On Tue, Jul 7, 2020 at 8:58 AM John McKown wrote: > On Tue, Jul 7, 2020 at 8:19 AM Jackson, Rob > wrote: > > > Fun little note on RAID: it is fallible. The last Sunday of October > 2016 > > I got a call bright and early because our VTS (TS7740) had shut down. > > Turns out we had a "cache" HDD failure at around 4 AM, and then a second > > one failed at around 7 AM, before the first one had been rebuilt on a > > spare. RAID-5 could not accommodate it. Because of IBM politics, we had > > no tape until Monday at 16:00. I am ashamed to say that I sort of took > > tape for granted. It was astonishing how much of our processing depended > > on it. > > > > We had a similar problem occurs, long ago, with an actual SAN dasd array > (for Windows, not MVS). Weekend backup to physical tape aborted on a > Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix > it Monday morning." A few hours later, a disk in the array failed. No > problem, right? Unfortunately, while the CE was on his way in to replace > it, a second disk failed. The array was destroyed. Management said to > repair it and reload from the Sunday backup and we'd be good. When the > admin admitted that the backup failed and he didn't go in, he was > immediately terminated. Now, what are the chances that 2 drives in an array > will fail within hours? I don't know, but one thing many don't think about > with a "new array" is that all the drives are likely the same age and will > start to fail (if they are) about the same time. > > IMO, given my paranoia, I firmly believe that the disks in an array should > be replaced on a scheduled basis. I also believe in dual tape copies of > important tapes. And also, that tapes in "long term" retention (we have > tapes which have been at Iron Mountain for over 10 years!) should be > brought in and the data copied to a new (not reused) tape annually. Of > course, the bean counters will have an apoplectic fit and scream about how > much it costs to do this. They only understand cost, not value. I consider > them the bane of existence. Likely auditors, they take on too much > authority. Or as I have heard: Fire is a good servant but a terrible > master. > > > > > > > R.S. is spot on: make backups. Because of the trauma from this one > > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and > two > > mainframes on the floor. > > > > First Horizon Bank > > Mainframe Technical Support > > > > > -- > People in sleeping bags are the soft tacos of the bear world. > Maranatha! <>< > John McKown > > -- > 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
Re: Storage & tape question
A very good point. In all of our storage products that we produce (dasd and vtl) we use Raid 6 which can tolerate 2 drive failures and always have at least 1 hot spare that is inserted into the array automatically. Additionally, our online diagnostics send out an alert email indicating a drive failure and which drive it is. So the probability of a failure escalating to a complete system failure is extremely small. Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jul 7, 2020, at 9:58 AM, John McKown wrote: > > On Tue, Jul 7, 2020 at 8:19 AM Jackson, Rob > wrote: > >> Fun little note on RAID: it is fallible. The last Sunday of October 2016 >> I got a call bright and early because our VTS (TS7740) had shut down. >> Turns out we had a "cache" HDD failure at around 4 AM, and then a second >> one failed at around 7 AM, before the first one had been rebuilt on a >> spare. RAID-5 could not accommodate it. Because of IBM politics, we had >> no tape until Monday at 16:00. I am ashamed to say that I sort of took >> tape for granted. It was astonishing how much of our processing depended >> on it. >> > > We had a similar problem occurs, long ago, with an actual SAN dasd array > (for Windows, not MVS). Weekend backup to physical tape aborted on a > Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix > it Monday morning." A few hours later, a disk in the array failed. No > problem, right? Unfortunately, while the CE was on his way in to replace > it, a second disk failed. The array was destroyed. Management said to > repair it and reload from the Sunday backup and we'd be good. When the > admin admitted that the backup failed and he didn't go in, he was > immediately terminated. Now, what are the chances that 2 drives in an array > will fail within hours? I don't know, but one thing many don't think about > with a "new array" is that all the drives are likely the same age and will > start to fail (if they are) about the same time. > > IMO, given my paranoia, I firmly believe that the disks in an array should > be replaced on a scheduled basis. I also believe in dual tape copies of > important tapes. And also, that tapes in "long term" retention (we have > tapes which have been at Iron Mountain for over 10 years!) should be > brought in and the data copied to a new (not reused) tape annually. Of > course, the bean counters will have an apoplectic fit and scream about how > much it costs to do this. They only understand cost, not value. I consider > them the bane of existence. Likely auditors, they take on too much > authority. Or as I have heard: Fire is a good servant but a terrible > master. > > > >> >> R.S. is spot on: make backups. Because of the trauma from this one >> event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two >> mainframes on the floor. >> >> First Horizon Bank >> Mainframe Technical Support >> >> > -- > People in sleeping bags are the soft tacos of the bear world. > Maranatha! <>< > John McKown > > -- > 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
Re: Storage & tape question
On Tue, Jul 7, 2020 at 8:19 AM Jackson, Rob wrote: > Fun little note on RAID: it is fallible. The last Sunday of October 2016 > I got a call bright and early because our VTS (TS7740) had shut down. > Turns out we had a "cache" HDD failure at around 4 AM, and then a second > one failed at around 7 AM, before the first one had been rebuilt on a > spare. RAID-5 could not accommodate it. Because of IBM politics, we had > no tape until Monday at 16:00. I am ashamed to say that I sort of took > tape for granted. It was astonishing how much of our processing depended > on it. > We had a similar problem occurs, long ago, with an actual SAN dasd array (for Windows, not MVS). Weekend backup to physical tape aborted on a Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix it Monday morning." A few hours later, a disk in the array failed. No problem, right? Unfortunately, while the CE was on his way in to replace it, a second disk failed. The array was destroyed. Management said to repair it and reload from the Sunday backup and we'd be good. When the admin admitted that the backup failed and he didn't go in, he was immediately terminated. Now, what are the chances that 2 drives in an array will fail within hours? I don't know, but one thing many don't think about with a "new array" is that all the drives are likely the same age and will start to fail (if they are) about the same time. IMO, given my paranoia, I firmly believe that the disks in an array should be replaced on a scheduled basis. I also believe in dual tape copies of important tapes. And also, that tapes in "long term" retention (we have tapes which have been at Iron Mountain for over 10 years!) should be brought in and the data copied to a new (not reused) tape annually. Of course, the bean counters will have an apoplectic fit and scream about how much it costs to do this. They only understand cost, not value. I consider them the bane of existence. Likely auditors, they take on too much authority. Or as I have heard: Fire is a good servant but a terrible master. > > R.S. is spot on: make backups. Because of the trauma from this one > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two > mainframes on the floor. > > First Horizon Bank > Mainframe Technical Support > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Fun little note on RAID: it is fallible. The last Sunday of October 2016 I got a call bright and early because our VTS (TS7740) had shut down. Turns out we had a "cache" HDD failure at around 4 AM, and then a second one failed at around 7 AM, before the first one had been rebuilt on a spare. RAID-5 could not accommodate it. Because of IBM politics, we had no tape until Monday at 16:00. I am ashamed to say that I sort of took tape for granted. It was astonishing how much of our processing depended on it. R.S. is spot on: make backups. Because of the trauma from this one event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two mainframes on the floor. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, July 7, 2020 4:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Yes, it is possible to have VTS without real tapes on backend. Some vendors do offer only "tapeless tapes", with no option to connect real tape library. However from OS point of view there is difference between disk (DASD) and tape (offline storage). Price difference is also worth to consider, however I mean the logic. Even the biggest, cheapest and really huge DASD will not protect you form human and application (and other) errors. But backup will do it. That's why we do backups. We don't afraid of disk failure, because we have RAID, spare modules and possibly remote copy. However we do backups. If you insist on DASD, you may (theoretically) connect another DASD box dedicated for backups only. And even (logically) disconnect it between backup sessions. However it is IMHO worse version of VTS. Note: I do not discuss here things like price (initial, per terabyte), compression, thruput, scalability, RAID, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 06.07.2020 o 16:46, kekronbekron pisze: > Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? > Don't know if EMC DLm has a cart back-end option. > > If it's VTL with disk back-end, is that any different from having it all on > DASD? > > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, July 6, 2020 4:25 PM, R.S. wrote: > >> I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. >> No jobs should write or read tapes. >> Nothing except backup and restore and (optionally) ML2. Managed by >> HSM or FDR. Some excepions for archive copies are worth to consider. >> Note: you may have 15 years old backup on new shining tape. Migration >> from older tape is no nightmare at all. It is simple. >> >> - >> - >> - >> - >> - >> >> >> Radoslaw Skorupka >> Lodz, Poland >> >> W dniu 06.07.2020 o 12:49, R.S. pisze: >> >>> W dniu 05.07.2020 o 14:12, kekronbekron pisze: >>> >>>> Hello List, >>>> Just wondering ... assuming there's a primary storage product out >>>> there that can store how-many-ever hoo-haa-bytes, and is a good >>>> product in general, it should make sense to begin eliminating all >>>> tape (3490/3590) use right? >>>> First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to >>>> write to disk, or do SMS/ACS updates to make it all disk reads/writes. >>>> Looking at the current storage solutions out there, this is >>>> possible, right? >>>> What would be the drawbacks (assume that primary storage is super >>>> cost-efficient, so there's no need to archive anything). >>> Few remarks: >>> Even the cheapest possible DASD will not replace backup and other >>> things (archive copy, etc.) I did replace 3490E tapes with really >>> cheap second hand DASD boxes, it was approx. 20 years ago. Been >>> There, done that. It wasn't very fine solution, it was cheap and >>> working. AFAIR HSM does not like DASD as the output for some >>> activities, can't remember details. >>> Someone wrote about tapes moved to DR shelter. That's very >>> old-fashioned. I would strongly prefer to have remote copy, that >>> means two dasd-boxes and connectivity between. >>> There are products for tap
Re: Storage & tape question
It it feasible. However using PS files on tape you loose many DFSMS facilities including backup, MC features (when to delete, how many backup versions), replication is possible, but it's not DASD remote copy (and no consistency between VTS and DASD), etc. Also no sharing for input. And many other issues. Regarding B37 - few SMS tricks will prevent you against this problem. BTDT many times. Personally I would not consider that as an argument for using tapes for PS. -- Radoslaw Skorupka Lodz, Poland W dniu 07.07.2020 o 10:35, Brian Fraser pisze: I'm of the opposite opinion. Virtual tapes should be used for most large sequential datasets. Only exceptions are datasets that are required to be read by multiple subsequent jobs at the same time. No B37 ABENDs ever, lower cost and much more easily recovered if something gets "accidently" deleted. On Tue, 7 Jul 2020 at 13:29, Timothy Sipples wrote: Radoslaw Skorupka wrote: I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. No jobs should write or read tapes. Nothing except backup and restore and (optionally) ML2. Managed by HSM or FDR. Some excepions for archive copies are worth to consider. I take your point, but "NEVER" is too strong. And you're acknowledging there might be some exceptions, so let's dig into them a bit. One notable exception that I'm increasingly encountering is in the digital asset industry. There are occasions when they'd like to have certain digital assets in an offline state, for example in technically and operationally assured systems, encrypted on WORM tape cartridges physically removed from tape libraries. In some cases that sort of approach is what the asset owners and their insurers require. Another potential exception involves certain content management systems, although it depends on how they're designed. As another example, IBM SAFR runs really don't mind source data from tape and/or virtual tape. As long as the data streams fast enough for whatever you're trying to do with SAFR, that's perfectly fine. I suppose you could drive even these edge cases through DFSMShsm handling (and manual tape loading procedures in the first example), but then you'd need above average cooperation with application developers and owners. The "my application knows best" philosophy is powerful, for better or worse. You just try to do the best you can, and if there's an exceptional edge case and consensus agreement that it ought to be handled differently (even if you disagree), OK, so it goes. == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
W dniu 07.07.2020 o 07:28, Timothy Sipples pisze: Radoslaw Skorupka wrote: I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. No jobs should write or read tapes. Nothing except backup and restore and (optionally) ML2. Managed by HSM or FDR. Some excepions for archive copies are worth to consider. I take your point, but "NEVER" is too strong. And you're acknowledging there might be some exceptions, so let's dig into them a bit. One notable exception that I'm increasingly encountering is in the digital asset industry. There are occasions when they'd like to have certain digital assets in an offline state, for example in technically and operationally assured systems, encrypted on WORM tape cartridges physically removed from tape libraries. In some cases that sort of approach is what the asset owners and their insurers require. Another potential exception involves certain content management systems, although it depends on how they're designed. As another example, IBM SAFR runs really don't mind source data from tape and/or virtual tape. As long as the data streams fast enough for whatever you're trying to do with SAFR, that's perfectly fine. I suppose you could drive even these edge cases through DFSMShsm handling (and manual tape loading procedures in the first example), but then you'd need above average cooperation with application developers and owners. The "my application knows best" philosophy is powerful, for better or worse. You just try to do the best you can, and if there's an exceptional edge case and consensus agreement that it ought to be handled differently (even if you disagree), OK, so it goes. Well, I agree "NEVER" was strong. However the context is important. This is "good advice" for someone who needs the advice. So, some simplification is justified. In many cases people need short answer instead long lecture. Regarding your case - I would classify it as archive copy. WORM is very good solution here. Of course there are no more WORM media, I mean physical WORM like CD-R (or DVD-R, or UDO). Tape cart WORM is "digital agreement" between chip inside the cart and the drive. However the media itself is regular magnetic tape. In theory "hacked" drive could overwrite it. Why I'm discussing it? Because there are WORM solutions which are disk arrays. Even IBM offer such solution (DR550). So, for tape is not the only solution for such data. Obviously disk itself is not WORM, this is microcode which makes the copy "WORM". There is another issue to consider. AFAIK solution like DR550 cannot be attached to FICON, othere vendors also do not offer such attachment. So, if you don't want to engage another (non-z/OS) system between, WORM tape seems to be more interesting. -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Hi RS, "Even the biggest, cheapest and really huge DASD will not protect you form human and application (and other) errors. But backup will do it." Don't understand why 'offline' backup is considered a difficulty when going all-DASD. Keeping synchronous replication aside, PiT/snapshots are still a thing, right? ADRDSSU or FDR based dataset/volume dumps still work right? It maybe 'dumb' to have backups also go to the same DASD, but secondary DASD for backups should work. I've seen in a lot of the recent SHARE sessions that many sites use A to B sync and then A to A` & B to B` local/offline copies. It all boils down to the resiliency of the primary storage w.r.t serviceability and being generally painless to operate/manage. Also, if there's no easy way of changing the esoteric 'CART' or '3490/3590' to go to primary disk, perhaps something like - DASD, tape emulator (Optica zVT/Luminex CGX/any other) -> DASD Not considering the Luminex MVT-like options that come with storage capacity. The whole idea is if there exists some magical DASD vendor that offers RAS & capacity for "cheap" vs operational cost of VTL-like solutions... - KB ‐‐‐ Original Message ‐‐‐ On Tuesday, July 7, 2020 2:05 PM, R.S. wrote: > Yes, it is possible to have VTS without real tapes on backend. Some > vendors do offer only "tapeless tapes", with no option to connect real > tape library. > However from OS point of view there is difference between disk (DASD) > and tape (offline storage). > Price difference is also worth to consider, however I mean the logic. > Even the biggest, cheapest and really huge DASD will not protect you > form human and application (and other) errors. But backup will do it. > That's why we do backups. We don't afraid of disk failure, because we > have RAID, spare modules and possibly remote copy. However we do backups. > If you insist on DASD, you may (theoretically) connect another DASD box > dedicated for backups only. And even (logically) disconnect it between > backup sessions. However it is IMHO worse version of VTS. > > Note: I do not discuss here things like price (initial, per terabyte), > compression, thruput, scalability, RAID, etc. > > --- > > Radoslaw Skorupka > Lodz, Poland > > W dniu 06.07.2020 o 16:46, kekronbekron pisze: > > > Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? > > Don't know if EMC DLm has a cart back-end option. > > If it's VTL with disk back-end, is that any different from having it all on > > DASD? > > > > - KB > > > > ‐‐‐ Original Message ‐‐‐ > > On Monday, July 6, 2020 4:25 PM, R.S. r.skoru...@bremultibank.com.pl wrote: > > > > > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > > > No jobs should write or read tapes. > > > Nothing except backup and restore and (optionally) ML2. Managed by HSM > > > or FDR. Some excepions for archive copies are worth to consider. > > > Note: you may have 15 years old backup on new shining tape. Migration > > > from older tape is no nightmare at all. It is simple. > > > > > > Radoslaw Skorupka > > > Lodz, Poland > > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > > > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > > > > > Hello List, > > > > > Just wondering ... assuming there's a primary storage product out > > > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > > > product in general, it should make sense to begin eliminating all > > > > > tape (3490/3590) use right? > > > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write > > > > > to disk, or do SMS/ACS updates to make it all disk reads/writes. > > > > > Looking at the current storage solutions out there, this is possible, > > > > > right? > > > > > What would be the drawbacks (assume that primary storage is super > > > > > cost-efficient, so there's no need to archive anything). > > > > > Few remarks: > > > > > Even the cheapest possible DASD will not replace backup and other > > > > > things (archive copy, etc.) > > > > > I did replace 3490E tapes w
Re: Storage & tape question
I'm of the opposite opinion. Virtual tapes should be used for most large sequential datasets. Only exceptions are datasets that are required to be read by multiple subsequent jobs at the same time. No B37 ABENDs ever, lower cost and much more easily recovered if something gets "accidently" deleted. On Tue, 7 Jul 2020 at 13:29, Timothy Sipples wrote: > Radoslaw Skorupka wrote: > >I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION > >DATA. No jobs should write or read tapes. > >Nothing except backup and restore and (optionally) ML2. Managed by > >HSM or FDR. Some excepions for archive copies are worth to consider. > > I take your point, but "NEVER" is too strong. And you're acknowledging > there might be some exceptions, so let's dig into them a bit. > > One notable exception that I'm increasingly encountering is in the digital > asset industry. There are occasions when they'd like to have certain > digital assets in an offline state, for example in technically and > operationally assured systems, encrypted on WORM tape cartridges > physically removed from tape libraries. In some cases that sort of > approach is what the asset owners and their insurers require. Another > potential exception involves certain content management systems, although > it depends on how they're designed. > > As another example, IBM SAFR runs really don't mind source data from tape > and/or virtual tape. As long as the data streams fast enough for whatever > you're trying to do with SAFR, that's perfectly fine. > > I suppose you could drive even these edge cases through DFSMShsm handling > (and manual tape loading procedures in the first example), but then you'd > need above average cooperation with application developers and owners. The > "my application knows best" philosophy is powerful, for better or worse. > You just try to do the best you can, and if there's an exceptional edge > case and consensus agreement that it ought to be handled differently (even > if you disagree), OK, so it goes. > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: sipp...@sg.ibm.com > > -- > 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
Re: Storage & tape question
Yes, it is possible to have VTS without real tapes on backend. Some vendors do offer only "tapeless tapes", with no option to connect real tape library. However from OS point of view there is difference between disk (DASD) and tape (offline storage). Price difference is also worth to consider, however I mean the logic. Even the biggest, cheapest and really huge DASD will not protect you form human and application (and other) errors. But backup will do it. That's why we do backups. We don't afraid of disk failure, because we have RAID, spare modules and possibly remote copy. However we do backups. If you insist on DASD, you may (theoretically) connect another DASD box dedicated for backups only. And even (logically) disconnect it between backup sessions. However it is IMHO worse version of VTS. Note: I do not discuss here things like price (initial, per terabyte), compression, thruput, scalability, RAID, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 06.07.2020 o 16:46, kekronbekron pisze: Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. No jobs should write or read tapes. Nothing except backup and restore and (optionally) ML2. Managed by HSM or FDR. Some excepions for archive copies are worth to consider. Note: you may have 15 years old backup on new shining tape. Migration from older tape is no nightmare at all. It is simple. - Radoslaw Skorupka Lodz, Poland W dniu 06.07.2020 o 12:49, R.S. pisze: W dniu 05.07.2020 o 14:12, kekronbekron pisze: Hello List, Just wondering ... assuming there's a primary storage product out there that can store how-many-ever hoo-haa-bytes, and is a good product in general, it should make sense to begin eliminating all tape (3490/3590) use right? First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, or do SMS/ACS updates to make it all disk reads/writes. Looking at the current storage solutions out there, this is possible, right? What would be the drawbacks (assume that primary storage is super cost-efficient, so there's no need to archive anything). Few remarks: Even the cheapest possible DASD will not replace backup and other things (archive copy, etc.) I did replace 3490E tapes with really cheap second hand DASD boxes, it was approx. 20 years ago. Been There, done that. It wasn't very fine solution, it was cheap and working. AFAIR HSM does not like DASD as the output for some activities, can't remember details. Someone wrote about tapes moved to DR shelter. That's very old-fashioned. I would strongly prefer to have remote copy, that means two dasd-boxes and connectivity between. There are products for tape emulation on CKD disk. It is definitely no cheap. It also consume MSU. Tapes, even virtual tapes are OFFLINE media from MVS point of view. Offline media are good for some ps! mistakes. Last, but not least: you assumption is far from reality. DASD is still more expensive than tape. The more capacity the difference is bigger. Tape (real one) is cheap when talking about carts and very well scalable. However tape realm with "first cart" is extremely expensive, because drives are expensive, controllers are expensive and ATLs are expensive. The real decision depends strongly on your capacity, your predicted growths, your needs and budget. == == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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
Re: Storage & tape question
On IBM TS7700 R4 the maximum quantity of feature #5268, 100 MBps Throughput, is increased to 39 when 16 Gbps FICON adapter features #3402 or #3403 are installed. So throughput will max out at 4,000 MBps. On Mon, 6 Jul 2020 at 22:58, Jackson, Rob wrote: > We have a three-way TS7760 grid--all mirrors of each other. DR box is a > TS7760T with a 3584, with some 650 tapes, or so. > > Yes, it's very much different. With IBM's VTSs you pay for bandwidth. We > license 300 MB/s, for instance, on each cluster. If I remember correctly, > you can go up to 700 MB/s on the TS7760. A far cry from normal "DASD" > boxes. > > First Horizon Bank > Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of kekronbekron > Sent: Monday, July 6, 2020 10:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage & tape question > > [External Email. Exercise caution when clicking links or opening > attachments.] > > Hmm... do a lot of shops use actual cart based tapes ... TS77xx with > TS4x00? > Don't know if EMC DLm has a cart back-end option. > > If it's VTL with disk back-end, is that any different from having it all > on DASD? > > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, July 6, 2020 4:25 PM, R.S. > wrote: > > > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > > No jobs should write or read tapes. > > Nothing except backup and restore and (optionally) ML2. Managed by HSM > > or FDR. Some excepions for archive copies are worth to consider. > > Note: you may have 15 years old backup on new shining tape. Migration > > from older tape is no nightmare at all. It is simple. > > > > -- > > -- > > -- > > -- > > -- > > --- > > > > Radoslaw Skorupka > > Lodz, Poland > > > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > > > Hello List, > > > > Just wondering ... assuming there's a primary storage product out > > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > > product in general, it should make sense to begin eliminating all > > > > tape (3490/3590) use right? > > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to > > > > write to disk, or do SMS/ACS updates to make it all disk > reads/writes. > > > > Looking at the current storage solutions out there, this is > > > > possible, right? > > > > What would be the drawbacks (assume that primary storage is super > > > > cost-efficient, so there's no need to archive anything). > > > > > > Few remarks: > > > Even the cheapest possible DASD will not replace backup and other > > > things (archive copy, etc.) I did replace 3490E tapes with really > > > cheap second hand DASD boxes, it was approx. 20 years ago. Been > > > There, done that. It wasn't very fine solution, it was cheap and > > > working. AFAIR HSM does not like DASD as the output for some > > > activities, can't remember details. > > > Someone wrote about tapes moved to DR shelter. That's very > > > old-fashioned. I would strongly prefer to have remote copy, that > > > means two dasd-boxes and connectivity between. > > > There are products for tape emulation on CKD disk. It is definitely > > > no cheap. It also consume MSU. > > > Tapes, even virtual tapes are OFFLINE media from MVS point of view. > > > Offline media are good for some ps! mistakes. > > > Last, but not least: you assumption is far from reality. DASD is > > > still more expensive than tape. The more capacity the difference is > bigger. > > > Tape (real one) is cheap when talking about carts and very well > > > scalable. However tape realm with "first cart" is extremely > > > expensive, because drives are expensive, controllers are expensive > > > and ATLs are expensive. > > > The real decision depends strongly on your capacity, your predicted > > > growths, your needs and budget. > > > > == > > > > Jeśli nie jesteś adresatem tej wiadomości: > &
Re: Storage & tape question
Radoslaw Skorupka wrote: >I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION >DATA. No jobs should write or read tapes. >Nothing except backup and restore and (optionally) ML2. Managed by >HSM or FDR. Some excepions for archive copies are worth to consider. I take your point, but "NEVER" is too strong. And you're acknowledging there might be some exceptions, so let's dig into them a bit. One notable exception that I'm increasingly encountering is in the digital asset industry. There are occasions when they'd like to have certain digital assets in an offline state, for example in technically and operationally assured systems, encrypted on WORM tape cartridges physically removed from tape libraries. In some cases that sort of approach is what the asset owners and their insurers require. Another potential exception involves certain content management systems, although it depends on how they're designed. As another example, IBM SAFR runs really don't mind source data from tape and/or virtual tape. As long as the data streams fast enough for whatever you're trying to do with SAFR, that's perfectly fine. I suppose you could drive even these edge cases through DFSMShsm handling (and manual tape loading procedures in the first example), but then you'd need above average cooperation with application developers and owners. The "my application knows best" philosophy is powerful, for better or worse. You just try to do the best you can, and if there's an exceptional edge case and consensus agreement that it ought to be handled differently (even if you disagree), OK, so it goes. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Thank you for the detailed response Glenn, IBM-MAIN is truly amazing. > Migrate/Archive > The three purposes of HSM migration are to 1) compress the data so that the > footprint is smaller, 2) move it to a lower cost media so that the TCO is > lower and 3) move the data to an offline media that doesn't consume online > UCBs. When considering bringing all of your data back online, you need to > consider the impact of all three. 1) Assuming 3:1 compaction, you'll need 3x > the online storage. With zEDC, that will vary on both what you can get on the > primary storage and the ML2 storage. 3) For larger shops, the number on > online UCBs is a factor. It's not a factor for smaller shops. - 1) Compression - wouldn't it be enough to rely on z15 on-chip compression + the compression/dedupe done by the storage array itself? Sure, it may not be 3:1.. but worth evaluating? If the array itself is doing C+D, then "rehydrating" the data isn't a problem I believe? 2) It's not just the storage cost though right.. (cost of a bunch of disk, S&S) vs (cost of tape emulation, physical carts, bandwidth, S&S, HSM's direct & indirect costs) 3) Ok, the UCB thing can be problematic for big shops, agreed. There's only so much you can do with 3390-54 (are bigger volumes coming anytime soon?). > Another thing to consider with an all disk environment is your 'relief > valve'. It's simple to migrate data to tape as a means of ensuring that you > always have enough space on your primary storage for growth. If you only have > primary storage, what is your exception handling case when you have > unexpected growth and no migration tiers to which to move your inactive data? > How quickly can you bring more primary storage online? Sorry, I know it sounds silly when I keep saying 'assume x/y/z is already catered to', but ... assuming primary storage provisioning is no longer a problem (apart from the UCBs mentioned above). > Another option is DS8000 transparent cloud tiering. This enables you to > migrate inactive data to cloud object storage, with minimal cpu since the > DS8K is doing the data movement. If not a primary means of migrating data, it > is a very good option for a 'relief valve'. Hmm... the two whole approaches (all-primary vs standard procedure) need to costed out and compared to be impartial to either case. > Backup > Regardless of the replication technique that you are using > (synchronous/asynchronous), you need point-in-time copies of your data for > logical corruption protection. If a data set is accidentally or maliciously > deleted, replication quickly deletes it from all copies. Also, if data > becomes logically corrupted, it is instantly corrupted in all copies. So, you > have to have a point-in-time backup technique for all of your data. You need > as many copies as you want recovery points. One copy doesn't give you much > security. Keeping n copies on disk can get pricey and consume alot of > storage. Also, you need to replicate the n PiT copies to all of your sites so > that you can do a logical recovery after a physical fail over. This makes the > cost add up even more quickly. TCT is another good option for this. You can > keep 1 or 2 copies on disk and then have HSM migrate/expire the older backup > copies to cloud object storage which is then available at all of your > recovery sites. If we consider that the storage array has *proper* support for multi-site, snapshots/PiTs, etc. ... again not problematic. Fully understand I may be dreaming about such a primary storage, it's good to know the technical constraints against it. - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 10:54 PM, Glenn Wilcock wrote: > A few thoughts: > > Migrate/Archive > The three purposes of HSM migration are to 1) compress the data so that the > footprint is smaller, 2) move it to a lower cost media so that the TCO is > lower and 3) move the data to an offline media that doesn't consume online > UCBs. When considering bringing all of your data back online, you need to > consider the impact of all three. 1) Assuming 3:1 compaction, you'll need 3x > the online storage. With zEDC, that will vary on both what you can get on the > primary storage and the ML2 storage. 3) For larger shops, the number on > online UCBs is a factor. It's not a factor for smaller shops. > > Some clients have selected to go to an all HSM ML1 environment to still get > the advantage of zEDC compression on inactive data. (You may be utilizing > zEDC for primary storage, but that is only available for nonVSAM data). These > clients utilize the lowest cost disk and utilize the value of zEDC > compression to minimize the footprint. > > Another thing to consider with an all disk environment is your 'relief > valve'. It's simple to migrate data to tape as a means of ensuring that you > always have enough space on your primary storage for growth. If you only have > primary storage, what is y
Re: Storage & tape question
A few thoughts: Migrate/Archive The three purposes of HSM migration are to 1) compress the data so that the footprint is smaller, 2) move it to a lower cost media so that the TCO is lower and 3) move the data to an offline media that doesn't consume online UCBs. When considering bringing all of your data back online, you need to consider the impact of all three. 1) Assuming 3:1 compaction, you'll need 3x the online storage. With zEDC, that will vary on both what you can get on the primary storage and the ML2 storage. 3) For larger shops, the number on online UCBs is a factor. It's not a factor for smaller shops. Some clients have selected to go to an all HSM ML1 environment to still get the advantage of zEDC compression on inactive data. (You may be utilizing zEDC for primary storage, but that is only available for nonVSAM data). These clients utilize the lowest cost disk and utilize the value of zEDC compression to minimize the footprint. Another thing to consider with an all disk environment is your 'relief valve'. It's simple to migrate data to tape as a means of ensuring that you always have enough space on your primary storage for growth. If you only have primary storage, what is your exception handling case when you have unexpected growth and no migration tiers to which to move your inactive data? How quickly can you bring more primary storage online? Another option is DS8000 transparent cloud tiering. This enables you to migrate inactive data to cloud object storage, with minimal cpu since the DS8K is doing the data movement. If not a primary means of migrating data, it is a very good option for a 'relief valve'. Backup Regardless of the replication technique that you are using (synchronous/asynchronous), you need point-in-time copies of your data for logical corruption protection. If a data set is accidentally or maliciously deleted, replication quickly deletes it from all copies. Also, if data becomes logically corrupted, it is instantly corrupted in all copies. So, you have to have a point-in-time backup technique for all of your data. You need as many copies as you want recovery points. One copy doesn't give you much security. Keeping n copies on disk can get pricey and consume alot of storage. Also, you need to replicate the n PiT copies to all of your sites so that you can do a logical recovery after a physical fail over. This makes the cost add up even more quickly. TCT is another good option for this. You can keep 1 or 2 copies on disk and then have HSM migrate/expire the older backup copies to cloud object storage which is then available at all of your recovery sites. Glenn Wilcock DFSMS Chief Product Owner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Nope. I meant what I said. 300 MB/s. It is what it is. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Monday, July 6, 2020 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] ITYM TB, not MB -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Monday, July 6, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We have a three-way TS7760 grid--all mirrors of each other. DR box is a TS7760T with a 3584, with some 650 tapes, or so. Yes, it's very much different. With IBM's VTSs you pay for bandwidth. We license 300 MB/s, for instance, on each cluster. If I remember correctly, you can go up to 700 MB/s on the TS7760. A far cry from normal "DASD" boxes. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Monday, July 6, 2020 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > No jobs should write or read tapes. > Nothing except backup and restore and (optionally) ML2. Managed by HSM > or FDR. Some excepions for archive copies are worth to consider. > Note: you may have 15 years old backup on new shining tape. Migration > from older tape is no nightmare at all. It is simple. > > -- > -- > -- > -- > -- > --- > > Radoslaw Skorupka > Lodz, Poland > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > Hello List, > > > Just wondering ... assuming there's a primary storage product out > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > product in general, it should make sense to begin eliminating all > > > tape (3490/3590) use right? > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to > > > write to disk, or do SMS/ACS updates to make it all disk reads/writes. > > > Looking at the current storage solutions out there, this is > > > possible, right? > > > What would be the drawbacks (assume that primary storage is super > > > cost-efficient, so there's no need to archive anything). > > > > Few remarks: > > Even the cheapest possible DASD will not replace backup and other > > things (archive copy, etc.) I did replace 3490E tapes with really > > cheap second hand DASD boxes, it was approx. 20 years ago. Been > > There, done that. It wasn't very fine solution, it was cheap and > > working. AFAIR HSM does not like DASD as the output for some > > activities, can't remember details. > > Someone wrote about tapes moved to DR shelter. That's very > > old-fashioned. I would strongly prefer to have remote copy, that > > means two dasd-boxes and connectivity between. > > There are products for tape emulation on CKD disk. It is definitely > > no cheap. It also consume MSU. > > Tapes, even virtual tapes are OFFLINE media from MVS point of view. > > Offline media are good for some ps! mistakes. > > Last, but not least: you assumption is far from reality. DASD is > > still more expensive than tape. The more capacity the difference is bigger. > > Tape (real one) is cheap when talking about carts and very well > > scalable. However tape realm with "first cart" is extremely > > expensive, because drives are expensive, controllers are expensive > > and ATLs are expensive. > > The real decision depends strongly on your capacity, your p
Re: Storage & tape question
Hi Allan, Nope, he meant MB. The number Rob is talking about it thruput. You pay for the capacity of the pipeline for ingesting data into the VTS in 100 MB/second increments. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Monday, July 6, 2020 11:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Storage & tape question ITYM TB, not MB -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Monday, July 6, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We have a three-way TS7760 grid--all mirrors of each other. DR box is a TS7760T with a 3584, with some 650 tapes, or so. Yes, it's very much different. With IBM's VTSs you pay for bandwidth. We license 300 MB/s, for instance, on each cluster. If I remember correctly, you can go up to 700 MB/s on the TS7760. A far cry from normal "DASD" boxes. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Monday, July 6, 2020 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > No jobs should write or read tapes. > Nothing except backup and restore and (optionally) ML2. Managed by HSM > or FDR. Some excepions for archive copies are worth to consider. > Note: you may have 15 years old backup on new shining tape. Migration > from older tape is no nightmare at all. It is simple. > > -- > -- > -- > -- > -- > --- > > Radoslaw Skorupka > Lodz, Poland > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > Hello List, > > > Just wondering ... assuming there's a primary storage product out > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > product in general, it should make sense to begin eliminating all > > > tape (3490/3590) use right? > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to > > > write to disk, or do SMS/ACS updates to make it all disk reads/writes. > > > Looking at the current storage solutions out there, this is > > > possible, right? > > > What would be the drawbacks (assume that primary storage is super > > > cost-efficient, so there's no need to archive anything). > > > > Few remarks: > > Even the cheapest possible DASD will not replace backup and other > > things (archive copy, etc.) I did replace 3490E tapes with really > > cheap second hand DASD boxes, it was approx. 20 years ago. Been > > There, done that. It wasn't very fine solution, it was cheap and > > working. AFAIR HSM does not like DASD as the output for some > > activities, can't remember details. > > Someone wrote about tapes moved to DR shelter. That's very > > old-fashioned. I would strongly prefer to have remote copy, that > > means two dasd-boxes and connectivity between. > > There are products for tape emulation on CKD disk. It is definitely > > no cheap. It also consume MSU. > > Tapes, even virtual tapes are OFFLINE media from MVS point of view. > > Offline media are good for some ps! mistakes. > > Last, but not least: you assumption is far from reality. DASD is > > still more expensive than tape. The more capacity the difference is bigger. > > Tape (real one) is cheap when talking about carts and very well > > scalable. However tape realm with "first cart" is extremely > > expensive, because drives are expensive, controllers are expensive > > and ATLs are expensive. > > The real decision depends strongly on your capacity,
Re: Storage & tape question
ITYM TB, not MB -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Monday, July 6, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We have a three-way TS7760 grid--all mirrors of each other. DR box is a TS7760T with a 3584, with some 650 tapes, or so. Yes, it's very much different. With IBM's VTSs you pay for bandwidth. We license 300 MB/s, for instance, on each cluster. If I remember correctly, you can go up to 700 MB/s on the TS7760. A far cry from normal "DASD" boxes. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Monday, July 6, 2020 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > No jobs should write or read tapes. > Nothing except backup and restore and (optionally) ML2. Managed by HSM > or FDR. Some excepions for archive copies are worth to consider. > Note: you may have 15 years old backup on new shining tape. Migration > from older tape is no nightmare at all. It is simple. > > -- > -- > -- > -- > -- > --- > > Radoslaw Skorupka > Lodz, Poland > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > Hello List, > > > Just wondering ... assuming there's a primary storage product out > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > product in general, it should make sense to begin eliminating all > > > tape (3490/3590) use right? > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to > > > write to disk, or do SMS/ACS updates to make it all disk reads/writes. > > > Looking at the current storage solutions out there, this is > > > possible, right? > > > What would be the drawbacks (assume that primary storage is super > > > cost-efficient, so there's no need to archive anything). > > > > Few remarks: > > Even the cheapest possible DASD will not replace backup and other > > things (archive copy, etc.) I did replace 3490E tapes with really > > cheap second hand DASD boxes, it was approx. 20 years ago. Been > > There, done that. It wasn't very fine solution, it was cheap and > > working. AFAIR HSM does not like DASD as the output for some > > activities, can't remember details. > > Someone wrote about tapes moved to DR shelter. That's very > > old-fashioned. I would strongly prefer to have remote copy, that > > means two dasd-boxes and connectivity between. > > There are products for tape emulation on CKD disk. It is definitely > > no cheap. It also consume MSU. > > Tapes, even virtual tapes are OFFLINE media from MVS point of view. > > Offline media are good for some ps! mistakes. > > Last, but not least: you assumption is far from reality. DASD is > > still more expensive than tape. The more capacity the difference is bigger. > > Tape (real one) is cheap when talking about carts and very well > > scalable. However tape realm with "first cart" is extremely > > expensive, because drives are expensive, controllers are expensive > > and ATLs are expensive. > > The real decision depends strongly on your capacity, your predicted > > growths, your needs and budget. > > == > > 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
Re: Storage & tape question
We have a three-way TS7760 grid--all mirrors of each other. DR box is a TS7760T with a 3584, with some 650 tapes, or so. Yes, it's very much different. With IBM's VTSs you pay for bandwidth. We license 300 MB/s, for instance, on each cluster. If I remember correctly, you can go up to 700 MB/s on the TS7760. A far cry from normal "DASD" boxes. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Monday, July 6, 2020 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question [External Email. Exercise caution when clicking links or opening attachments.] Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > No jobs should write or read tapes. > Nothing except backup and restore and (optionally) ML2. Managed by HSM > or FDR. Some excepions for archive copies are worth to consider. > Note: you may have 15 years old backup on new shining tape. Migration > from older tape is no nightmare at all. It is simple. > > -- > -- > -- > -- > -- > --- > > Radoslaw Skorupka > Lodz, Poland > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > Hello List, > > > Just wondering ... assuming there's a primary storage product out > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > product in general, it should make sense to begin eliminating all > > > tape (3490/3590) use right? > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to > > > write to disk, or do SMS/ACS updates to make it all disk reads/writes. > > > Looking at the current storage solutions out there, this is > > > possible, right? > > > What would be the drawbacks (assume that primary storage is super > > > cost-efficient, so there's no need to archive anything). > > > > Few remarks: > > Even the cheapest possible DASD will not replace backup and other > > things (archive copy, etc.) I did replace 3490E tapes with really > > cheap second hand DASD boxes, it was approx. 20 years ago. Been > > There, done that. It wasn't very fine solution, it was cheap and > > working. AFAIR HSM does not like DASD as the output for some > > activities, can't remember details. > > Someone wrote about tapes moved to DR shelter. That's very > > old-fashioned. I would strongly prefer to have remote copy, that > > means two dasd-boxes and connectivity between. > > There are products for tape emulation on CKD disk. It is definitely > > no cheap. It also consume MSU. > > Tapes, even virtual tapes are OFFLINE media from MVS point of view. > > Offline media are good for some ps! mistakes. > > Last, but not least: you assumption is far from reality. DASD is > > still more expensive than tape. The more capacity the difference is bigger. > > Tape (real one) is cheap when talking about carts and very well > > scalable. However tape realm with "first cart" is extremely > > expensive, because drives are expensive, controllers are expensive > > and ATLs are expensive. > > The real decision depends strongly on your capacity, your predicted > > growths, your needs and budget. > > == > > 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 025237, > NIP: 526-02
Re: Storage & tape question
Hmm... do a lot of shops use actual cart based tapes ... TS77xx with TS4x00? Don't know if EMC DLm has a cart back-end option. If it's VTL with disk back-end, is that any different from having it all on DASD? - KB ‐‐‐ Original Message ‐‐‐ On Monday, July 6, 2020 4:25 PM, R.S. wrote: > I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. > No jobs should write or read tapes. > Nothing except backup and restore and (optionally) ML2. Managed by HSM > or FDR. Some excepions for archive copies are worth to consider. > Note: you may have 15 years old backup on new shining tape. Migration > from older tape is no nightmare at all. It is simple. > > - > > Radoslaw Skorupka > Lodz, Poland > > W dniu 06.07.2020 o 12:49, R.S. pisze: > > > W dniu 05.07.2020 o 14:12, kekronbekron pisze: > > > > > Hello List, > > > Just wondering ... assuming there's a primary storage product out > > > there that can store how-many-ever hoo-haa-bytes, and is a good > > > product in general, it should make sense to begin eliminating all > > > tape (3490/3590) use right? > > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write > > > to disk, or do SMS/ACS updates to make it all disk reads/writes. > > > Looking at the current storage solutions out there, this is possible, > > > right? > > > What would be the drawbacks (assume that primary storage is super > > > cost-efficient, so there's no need to archive anything). > > > > Few remarks: > > Even the cheapest possible DASD will not replace backup and other > > things (archive copy, etc.) > > I did replace 3490E tapes with really cheap second hand DASD boxes, it > > was approx. 20 years ago. Been There, done that. It wasn't very fine > > solution, it was cheap and working. AFAIR HSM does not like DASD as > > the output for some activities, can't remember details. > > Someone wrote about tapes moved to DR shelter. That's very > > old-fashioned. I would strongly prefer to have remote copy, that means > > two dasd-boxes and connectivity between. > > There are products for tape emulation on CKD disk. It is definitely no > > cheap. It also consume MSU. > > Tapes, even virtual tapes are OFFLINE media from MVS point of view. > > Offline media are good for some ps! mistakes. > > Last, but not least: you assumption is far from reality. DASD is still > > more expensive than tape. The more capacity the difference is bigger. > > Tape (real one) is cheap when talking about carts and very well > > scalable. However tape realm with "first cart" is extremely expensive, > > because drives are expensive, controllers are expensive and ATLs are > > expensive. > > The real decision depends strongly on your capacity, your predicted > > growths, your needs and budget. > > == > > 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 025237, > NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION DATA. No jobs should write or read tapes. Nothing except backup and restore and (optionally) ML2. Managed by HSM or FDR. Some excepions for archive copies are worth to consider. Note: you may have 15 years old backup on new shining tape. Migration from older tape is no nightmare at all. It is simple. -- Radoslaw Skorupka Lodz, Poland W dniu 06.07.2020 o 12:49, R.S. pisze: W dniu 05.07.2020 o 14:12, kekronbekron pisze: Hello List, Just wondering ... assuming there's a primary storage product out there that can store how-many-ever hoo-haa-bytes, and is a good product in general, it should make sense to begin eliminating all tape (3490/3590) use right? First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, or do SMS/ACS updates to make it all disk reads/writes. Looking at the current storage solutions out there, this is possible, right? What would be the drawbacks (assume that primary storage is super cost-efficient, so there's no need to archive anything). Few remarks: Even the cheapest possible DASD will not replace backup and other things (archive copy, etc.) I did replace 3490E tapes with really cheap second hand DASD boxes, it was approx. 20 years ago. Been There, done that. It wasn't very fine solution, it was cheap and working. AFAIR HSM does not like DASD as the output for some activities, can't remember details. Someone wrote about tapes moved to DR shelter. That's very old-fashioned. I would strongly prefer to have remote copy, that means two dasd-boxes and connectivity between. There are products for tape emulation on CKD disk. It is definitely no cheap. It also consume MSU. Tapes, even virtual tapes are OFFLINE media from MVS point of view. Offline media are good for some ps! mistakes. Last, but not least: you assumption is far from reality. DASD is still more expensive than tape. The more capacity the difference is bigger. Tape (real one) is cheap when talking about carts and very well scalable. However tape realm with "first cart" is extremely expensive, because drives are expensive, controllers are expensive and ATLs are expensive. The real decision depends strongly on your capacity, your predicted growths, your needs and budget. == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
W dniu 05.07.2020 o 14:12, kekronbekron pisze: Hello List, Just wondering ... assuming there's a primary storage product out there that can store how-many-ever hoo-haa-bytes, and is a good product in general, it should make sense to begin eliminating all tape (3490/3590) use right? First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, or do SMS/ACS updates to make it all disk reads/writes. Looking at the current storage solutions out there, this is possible, right? What would be the drawbacks (assume that primary storage is super cost-efficient, so there's no need to archive anything). Few remarks: Even the cheapest possible DASD will not replace backup and other things (archive copy, etc.) I did replace 3490E tapes with really cheap second hand DASD boxes, it was approx. 20 years ago. Been There, done that. It wasn't very fine solution, it was cheap and working. AFAIR HSM does not like DASD as the output for some activities, can't remember details. Someone wrote about tapes moved to DR shelter. That's very old-fashioned. I would strongly prefer to have remote copy, that means two dasd-boxes and connectivity between. There are products for tape emulation on CKD disk. It is definitely no cheap. It also consume MSU. Tapes, even virtual tapes are OFFLINE media from MVS point of view. Offline media are good for some ps! mistakes. Last, but not least: you assumption is far from reality. DASD is still more expensive than tape. The more capacity the difference is bigger. Tape (real one) is cheap when talking about carts and very well scalable. However tape realm with "first cart" is extremely expensive, because drives are expensive, controllers are expensive and ATLs are expensive. The real decision depends strongly on your capacity, your predicted growths, your needs and budget. -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Ok, so assuming the primary storage takes care of DR backups, active/active, sync/async replication, physical risks [earth(quake), fire, wind, water, power], assures ease of standing up the DR environment after a whoopsie, isn't from a rent-seeking company that does planned obsolescence (i.e., there's a way to upgrade h/w without having to take it down). Thank you, I don't mean to say everything is already accounted for, just trying to surface the kind of issues/things to consider. ‐‐‐ Original Message ‐‐‐ On Sunday, July 5, 2020 11:07 PM, retired mainframer wrote: > You might want to consider whether transportability is an issue. How do you > get your backups to your disaster recovery site? The systems I worked on were > prohibited from connecting to public networks. > > You might also want to consider operational security. If your new storage > device is physically on line, it is subject to things like accidental data > deletion and damage from a power surge, fire, or EMP. A tape drive in a > secure vault could probably survive the next mass extinction. > > And after you resolve all the technical issues, somebody should still bring > up cost. It's not just acquisition cost per megabyte but things like > equipment footprint, power, air conditioning, maintenance. And don't forget > planned obsolescence. Mine was one of the last sites in the company > (country?) to use 9345s. > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of kekronbekron > > Sent: Sunday, July 05, 2020 5:13 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Storage & tape question > > Hello List, > > Just wondering ... assuming there's a primary storage product out there > > that can store > > how-many-ever hoo-haa-bytes, and is a good product in general, it should > > make sense > > to begin eliminating all tape (3490/3590) use right? > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to > > disk, or do > > SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > > What would be the drawbacks (assume that primary storage is super > > cost-efficient, so > > there's no need to archive anything). > > > > - KB > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
You might want to consider whether transportability is an issue. How do you get your backups to your disaster recovery site? The systems I worked on were prohibited from connecting to public networks. You might also want to consider operational security. If your new storage device is physically on line, it is subject to things like accidental data deletion and damage from a power surge, fire, or EMP. A tape drive in a secure vault could probably survive the next mass extinction. And after you resolve all the technical issues, somebody should still bring up cost. It's not just acquisition cost per megabyte but things like equipment footprint, power, air conditioning, maintenance. And don't forget planned obsolescence. Mine was one of the last sites in the company (country?) to use 9345s. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of kekronbekron > Sent: Sunday, July 05, 2020 5:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Storage & tape question > > Hello List, > > Just wondering ... assuming there's a primary storage product out there that > can store > how-many-ever hoo-haa-bytes, and is a good product in general, it should make > sense > to begin eliminating all tape (3490/3590) use right? > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, > or do > SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > What would be the drawbacks (assume that primary storage is super > cost-efficient, so > there's no need to archive anything). > > - KB > > -- > 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
Re: Storage & tape question
On 7/5/20 6:12 AM, kekronbekron wrote: Just wondering ... assuming there's a primary storage product out there that can store how-many-ever hoo-haa-bytes, and is a good product in general, it should make sense to begin eliminating all tape (3490/3590) use right? I have long been a fan of the separation between online DASD and not online in the same way tape. I believe that this separation makes it much more difficult to destroy as much data when the worst happens vs if said data is on online and accessible DASD. Even if the data is on DASD attached to a VTL, it is still separated from z/OS (et al.) running on the mainframe. I really like this separation. This is analogues to the difference between (s)ftp(s) access to a web server verses mapping a drive in Windows. Different blast radius / area of effect when the worst happens. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
Did this in the nineties > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of kekronbekron > Sent: Sunday, July 05, 2020 5:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Storage & tape question > > Hello List, > > Just wondering ... assuming there's a primary storage product out there that > can store how-many-ever hoo-haa-bytes, and is a good product in general, it > should make sense to begin eliminating all tape (3490/3590) use right? > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, > or do SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > What would be the drawbacks (assume that primary storage is super cost- > efficient, so there's no need to archive anything). > > - KB > > -- > 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
Re: Storage & tape question
Yup, those are the things I'm looking to identfy - what kinda things should one address before saying goodbye to tapes altogether (tapes/vtapes). - KB ‐‐‐ Original Message ‐‐‐ On Sunday, July 5, 2020 8:33 PM, Seymour J Metz wrote: > If you have DASD that are as cost effective as tape, have off site mirroring > and have software to keep track of and retrieve old versions, then you don't > need tape. If you go that way, it's crucial to have all of your ducks in a > row before you start changing things. Take a close look at what you're using > your current backup software for and ensure that any replacement has the > necessary functionality. > > > - > > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu] > Sent: Sunday, July 5, 2020 8:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Storage & tape question > > Hello List, > > Just wondering ... assuming there's a primary storage product out there that > can store how-many-ever hoo-haa-bytes, and is a good product in general, it > should make sense to begin eliminating all tape (3490/3590) use right? > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, > or do SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > What would be the drawbacks (assume that primary storage is super > cost-efficient, so there's no need to archive anything). > > - KB > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage & tape question
If you have DASD that are as cost effective as tape, have off site mirroring and have software to keep track of and retrieve old versions, then you don't need tape. If you go that way, it's crucial to have all of your ducks in a row before you start changing things. Take a close look at what you're using your current backup software for and ensure that any replacement has the necessary functionality. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu] Sent: Sunday, July 5, 2020 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Storage & tape question Hello List, Just wondering ... assuming there's a primary storage product out there that can store how-many-ever hoo-haa-bytes, and is a good product in general, it should make sense to begin eliminating all tape (3490/3590) use right? First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, or do SMS/ACS updates to make it all disk reads/writes. Looking at the current storage solutions out there, this is possible, right? What would be the drawbacks (assume that primary storage is super cost-efficient, so there's no need to archive anything). - KB -- 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
Re: Storage & tape question
All of this assumes that you're not taking frequent incremental backups. When you have periodic full volume backups and frequent increwmental backups then recovering deleted production DASD datasets is no big deal. Of course, that requires that the retention period be adequate. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joel C. Ewing [jce.ebe...@cox.net] Sent: Sunday, July 5, 2020 10:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage & tape question One of the major historical functional differences between tape-based and DASD-based data sets has to do with with ability to recover deleted data sets later found to be needed. You delete a data set on DASD, odds are very good something else overwrites that data or all knowledge of the location of the old data quickly in seconds, minutes or hours and destroys all possibility of recovery. You delete a data set on tape, the physical tape volume may not be re-used for days or weeks -- or if you realized there is an issue, the physical tape volume could be set aside and easily kept for archive indefinitely. In the old days, an application read a tape master file, did updates, wrote out a new tape master file with the same name, and operators put physical labels on the tape volumes and just knew how long to keep the old physical master volumes and not mount them as output tapes. That design evolved so that master files and other files that needed retention became GDG's with "reasonable" limits, with tape volumes protected or made eligible for re-use by a tape management system. In theory, such GDGs could just as easily be on DASD as tape. In practice one encountered applications systems where "temp" data sets that were originally on tape because of data set size probably should have been GDGs but were not; where applications that used to run once a month now ran more frequently or irregularly on user demand, and GDG limits and data set retention rules had not been increased as much as they should have been. These errors typically don't get detected until there is a problem requiring old data to recover. It is not always possible for application systems to anticipate all possible failures, particularly those caused by bad user input where the error might not be discovered until much later, or by an operational error or JCL design error where incorrect job re-starts could cause premature data-set deletion. Over the decades I saw a number of application systems that were able to recover from problems where the recovery was either made easier or possible by access to tape data sets that had logically scratched but were still physically available. Even virtual tape systems still allow for some leeway on the destruction of logically scratched tape volumes, but typically that retention with virtual tape was only a matter of days, unless the problem was recognized in time to mark the volume for retention in the tape management system. It is even possible to recover the data in the case of a deleted ML2 data set on tape: If the physical volume ML2 is still intact and you have backups of the HSM CDS data sets before the deletion, an independent test/recovery z/OS system can be used to recall the data set and save it in a way that can be ported back to the original system. So yes, in a perfect world you could just eliminate all tape and replace tape data sets with DASD data sets; but this really needs to be co-ordinated with a careful review of application systems to be sure that there is proper retention of all data sets potentially needed for recovery from data and/or design errors -- and best to err on the side of excess retention to guard against the unexpected. For some application systems it might even make sense to ask, what would it take to reprocess all data from any starting point in the last x months for some value of x. Joel C. Ewing On 7/5/20 7:12 AM, kekronbekron wrote: > Hello List, > > Just wondering ... assuming there's a primary storage product out there that > can store how-many-ever hoo-haa-bytes, and is a good product in general, it > should make sense to begin eliminating all tape (3490/3590) use right? > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, > or do SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > What would be the drawbacks (assume that primary storage is super > cost-efficient, so there's no need to archive anything). > > - KB > > ... -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-M
Re: Storage & tape question
Thanks Joel for the detailed response. As long as there's good backup and restore-testing hygeine, eliminating tape or vtape altogether (plus the complexity around it - HSM, OAM, 3490 emulation) ... is something doable then. Benefit would be severely reduced complexity (and cost), which is probably worth it. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, July 5, 2020 7:44 PM, Joel C. Ewing wrote: > One of the major historical functional differences between tape-based > and DASD-based data sets has to do with with ability to recover deleted > data sets later found to be needed. You delete a data set on DASD, > odds are very good something else overwrites that data or all knowledge > of the location of the old data quickly in seconds, minutes or hours and > destroys all possibility of recovery. You delete a data set on tape, > the physical tape volume may not be re-used for days or weeks -- or if > you realized there is an issue, the physical tape volume could be set > aside and easily kept for archive indefinitely. > > In the old days, an application read a tape master file, did updates, > wrote out a new tape master file with the same name, and operators put > physical labels on the tape volumes and just knew how long to keep the > old physical master volumes and not mount them as output tapes. That > design evolved so that master files and other files that needed > retention became GDG's with "reasonable" limits, with tape volumes > protected or made eligible for re-use by a tape management system. In > theory, such GDGs could just as easily be on DASD as tape. In practice > one encountered applications systems where "temp" data sets that were > originally on tape because of data set size probably should have been > GDGs but were not; where applications that used to run once a month now > ran more frequently or irregularly on user demand, and GDG limits and > data set retention rules had not been increased as much as they should > have been. These errors typically don't get detected until there is a > problem requiring old data to recover. > > It is not always possible for application systems to anticipate all > possible failures, particularly those caused by bad user input where the > error might not be discovered until much later, or by an operational > error or JCL design error where incorrect job re-starts could cause > premature data-set deletion. Over the decades I saw a number of > application systems that were able to recover from problems where the > recovery was either made easier or possible by access to tape data sets > that had logically scratched but were still physically available. Even > virtual tape systems still allow for some leeway on the destruction of > logically scratched tape volumes, but typically that retention with > virtual tape was only a matter of days, unless the problem was > recognized in time to mark the volume for retention in the tape > management system. > > It is even possible to recover the data in the case of a deleted ML2 > data set on tape: If the physical volume ML2 is still intact and you > have backups of the HSM CDS data sets before the deletion, an > independent test/recovery z/OS system can be used to recall the data set > and save it in a way that can be ported back to the original system. > > So yes, in a perfect world you could just eliminate all tape and replace > tape data sets with DASD data sets; but this really needs to be > co-ordinated with a careful review of application systems to be sure > that there is proper retention of all data sets potentially needed for > recovery from data and/or design errors -- and best to err on the side > of excess retention to guard against the unexpected. For some > application systems it might even make sense to ask, what would it take > to reprocess all data from any starting point in the last x months for > some value of x. > Joel C. Ewing > > On 7/5/20 7:12 AM, kekronbekron wrote: > > > Hello List, > > Just wondering ... assuming there's a primary storage product out there > > that can store how-many-ever hoo-haa-bytes, and is a good product in > > general, it should make sense to begin eliminating all tape (3490/3590) use > > right? > > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to > > disk, or do SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > > What would be the drawbacks (assume that primary storage is super > > cost-efficient, so there's no need to archive anything). > > > > - KB > > > > ... > > -- > > Joel C. Ewing > > -- > > 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
Re: Storage & tape question
One of the major historical functional differences between tape-based and DASD-based data sets has to do with with ability to recover deleted data sets later found to be needed. You delete a data set on DASD, odds are very good something else overwrites that data or all knowledge of the location of the old data quickly in seconds, minutes or hours and destroys all possibility of recovery. You delete a data set on tape, the physical tape volume may not be re-used for days or weeks -- or if you realized there is an issue, the physical tape volume could be set aside and easily kept for archive indefinitely. In the old days, an application read a tape master file, did updates, wrote out a new tape master file with the same name, and operators put physical labels on the tape volumes and just knew how long to keep the old physical master volumes and not mount them as output tapes. That design evolved so that master files and other files that needed retention became GDG's with "reasonable" limits, with tape volumes protected or made eligible for re-use by a tape management system. In theory, such GDGs could just as easily be on DASD as tape. In practice one encountered applications systems where "temp" data sets that were originally on tape because of data set size probably should have been GDGs but were not; where applications that used to run once a month now ran more frequently or irregularly on user demand, and GDG limits and data set retention rules had not been increased as much as they should have been. These errors typically don't get detected until there is a problem requiring old data to recover. It is not always possible for application systems to anticipate all possible failures, particularly those caused by bad user input where the error might not be discovered until much later, or by an operational error or JCL design error where incorrect job re-starts could cause premature data-set deletion. Over the decades I saw a number of application systems that were able to recover from problems where the recovery was either made easier or possible by access to tape data sets that had logically scratched but were still physically available. Even virtual tape systems still allow for some leeway on the destruction of logically scratched tape volumes, but typically that retention with virtual tape was only a matter of days, unless the problem was recognized in time to mark the volume for retention in the tape management system. It is even possible to recover the data in the case of a deleted ML2 data set on tape: If the physical volume ML2 is still intact and you have backups of the HSM CDS data sets before the deletion, an independent test/recovery z/OS system can be used to recall the data set and save it in a way that can be ported back to the original system. So yes, in a perfect world you could just eliminate all tape and replace tape data sets with DASD data sets; but this really needs to be co-ordinated with a careful review of application systems to be sure that there is proper retention of all data sets potentially needed for recovery from data and/or design errors -- and best to err on the side of excess retention to guard against the unexpected. For some application systems it might even make sense to ask, what would it take to reprocess all data from any starting point in the last x months for some value of x. Joel C. Ewing On 7/5/20 7:12 AM, kekronbekron wrote: > Hello List, > > Just wondering ... assuming there's a primary storage product out there that > can store how-many-ever hoo-haa-bytes, and is a good product in general, it > should make sense to begin eliminating all tape (3490/3590) use right? > First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, > or do SMS/ACS updates to make it all disk reads/writes. > > Looking at the current storage solutions out there, this is possible, right? > What would be the drawbacks (assume that primary storage is super > cost-efficient, so there's no need to archive anything). > > - KB > > ... -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Storage & tape question
Hello List, Just wondering ... assuming there's a primary storage product out there that can store how-many-ever hoo-haa-bytes, and is a good product in general, it should make sense to begin eliminating all tape (3490/3590) use right? First, ML1 & ML2 in HSM, then HSM itself, then rebuild jobs to write to disk, or do SMS/ACS updates to make it all disk reads/writes. Looking at the current storage solutions out there, this is possible, right? What would be the drawbacks (assume that primary storage is super cost-efficient, so there's no need to archive anything). - KB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
