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. <r.skoru...@bremultibank.com.pl> 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 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 oooops! 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 0000025237, > 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 0000025237, 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
