Or you just write protect all of your backups on virtual tape. Brian
On Sat, 5 Sep 2020 15:38:04 +0000, Russell Witt <[email protected]> wrote: >John, >But what happens if the virtual tape environment itself was over-written? That >is where the concept of "virtual WORM" devices can help. A virtual WORM volume >cannot be over-written. And if your tape management system itself is >protected, the tapes will not be scratched until they should be (cycle control >or GDG limit or xxx days). While the concept of a virtual WORM seems bizarre >(its virtual, not physical) - the ability to protect against over-writing is a >huge safe-guard if you are seriously worried about some type of insider >threat. After all, the first thing a good insider hack would target is the >audit trail of their own activities and most commonly that audit trail will be >backed up on tape. >Russell Wittopinions are all my own (and I have a lot of them) > > >-----Original Message----- >From: John McKown <[email protected]> >To: [email protected] >Sent: Sat, Sep 5, 2020 6:47 am >Subject: Re: Ransoming a mainframe disk farm > >If I were to consider this (which I don't because my shop _is_ going away >1Q2021), what I would do is have a "golden image" (aka sysprog sandbox or >the GI) in a different LPAR. This image would have access to all attached >devices, including sharing a virtual tape environment. But the "core" >volumes would be _isolated_ from all other LPARs via the IODF / HCD. This >would include the GI specific catalogs (at least the master) and RACF (or >TSS or ACF2) database. The GI would do at least weekly backups of all the >volumes to the virtual tape. So the GI could be used to recover the other >systems' volumes. > >If there is no virtual tape environment, then there needs to be a separate, >GI only, set of DASD which would be used for the backups of the real >volumes. Of course, this doubles the size of your DASD farm. For the truly >paranoid, and rich, this DASD would be on an entirely separate array which >is not accessible from any LPAR other than the GI LPAR. > >Or, as I have actually done, use DFDSS (or FDR or ???) to make volume level >backups & download them to a USB drive. USB drives can be mind boggling >huge today. I saw a flash drive with 1TiB. But an USB attached SSD can be >even bigger. LIke this 16TiB USB 3.0 attached, encrypted, array: (there is >also a 30 TiB array -- of course you'll need a lot if you're talking about >a PetaByte environment). > >https://smile.amazon.com/Buslink-CipherShield-CSE16TSSDB4SU3-Hardware-Encrypted/dp/B01JVVHYZM/ref=sr_1_2?dchild=1&keywords=usb+ssd&pd_rd_r=5a1bbdc9-acaa-48d2-9518-4bcd087cd0d8&pd_rd_w=OrRWX&pd_rd_wg=6dxyr&pf_rd_p=e47220c0-687b-448f-b180-4a20654b7464&pf_rd_r=8BZ5ET5XHGMBMD3A23E7&qid=1599306202&refinements=p_n_feature_three_browse-bin%3A6797522011&s=pc&sr=1-2 > > >On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson <[email protected]> >wrote: > >> It’s Friday, so don’t rag on me for venturing into IT fiction. No one has >> hit us with this challenge (yet), but it could happen. >> >> Ransomware is much in the news these days. As unlikely as it might be, >> some nefarious genius manages to lock you out of your entire disk farm and >> demands rubies and bitcoin to remove the lock. Meanwhile your shop is out >> of the water. You have everything meticulously mirrored to another site, >> but as with any good mirror, the lock has been reflected in your recovery >> site. >> >> The classic mainframe response--short of forking over the ransom--would be >> to IPL a standalone DSS restore tape, then locate and mount standard >> offload backup tapes. Restore enough key volumes to IPL a minimal system, >> then proceed to restore (all) other volumes. It will take a while, but it >> will work. Eventually. >> >> Now consider a smartly modern shop that has taken the advice of a >> generation of hired gurus and eliminated 'real tape' altogether. No more >> physical tapes. No more physical tape drives. >> >> What would be your sage advice? >> >> . >> . >> 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 >> [email protected] >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
