Yes, I have 4 smaller clients that use cloud tape connector who store the second copy of migrated datasets to the cloud, as well as some DR related items. Also, I have their DS8K DASD conduct backups of the full DASD volumes directly to the cloud. The neat part of doing that directly is there is no CPU overhead involved in the process.
In a DR test, we reload the cloud volumes from the cloud, and we direct HSM to use the second migrate copy instead of the primary one. It did seem a 'little" slow, but was offset by the fact that we had the volumes immediately available to be loaded. We had no tapes to transfer. Those sites could not afford and frankly did not need PPRC and a second DS8K sitting around so they saved a lot of hardware costs. Obviously I'm over simplifying a bit, but if you put the thought into the process, you can have a viable DR for frankly a very low cost. The biggest cost issue for using the cloud isn't writing the data, it's reading it back, depending on what your plan is, it can cost several times as much to read as it does to write. One of the sites uses Adabas, and after we flashcopy the database to a backup set of volumes, we then use CTC to write that saved database to the cloud and as the PLOGs are created, they are also copied to the cloud. Obviously none of these sites are a bank, and redoing work between the last PLOG (they cut them hourly) and the current time is completely possible and not a real hardship. Writing to the cloud isn't as fast as writing to a VTS, but it's not super slow either. Just make sure you have a zIIP processor so that the CPU overhead on your actual CPs is kept in the trivial zone. Normally you wouldn't have any production processes that write directly to the cloud. I try to have HSM do most of the work where possible, even if that means creating an extra backup copy of "important" production datasets. It's a lot of work to set things up properly, but then most DR solutions are pretty involved. If you don't spend a lot of time thinking it all through, your DR test, and more importantly the actual DR will likely fail, so take your time and think it all through. Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
