On Tue, 24 Oct 2023 09:52:26 +0300, Arye Shemer <aryeshe...@gmail.com> wrote:
>the standard existing backup policies (ex: taking copies to another remote >site in this country) are not sufficient. >Hence the idea of backup to another geographical (cloud) area is raised. I believe you are saying that you want offsite out of country backup. Are there any other uses for this backup than disaster recovery? For instance, will it be used for file recovery or will onsite copies of these backups be used for file recovery? >(TS7700...) were already offered to the customer but rejected. The obvious problem is maintaining a TS7700 in another country and moving it if that country becomes a problem. I personally don't recommend using the offsite backups for specific file recovery. Disaster recovery is suitable. Volume recovery is suitable if it can meet your recovery requirements. I don't think build an inhouse solution would be difficult if you already maintain offsite disaster recovery tapes. Here is how I would approach this: Step 1. Convert the backup to make it portable. I don't know z/VM backup / restore backup file structure. I suspect z/VM doesn't care about disk or tape block sizes. In z/OS, we would use IBM's AMATERSE to retain file and block attributes. I suspect (but not sure) AMATERSE also creates checksum to verify the file is not corrupted during transmission. To restore the file, AMATERSE has an option to restore the z/OS file. Step 2. Create programs to send and receive the backups to the cloud or non-cloud server. You don't care if this is a cloud solution as long as it meets your requirements. There are many ways to send and receive these backups to the cloud. As Timothy said, writing a program using cloud objects is one solution. There are other cloud API's that could also accomplish your goals. I suspect there are other solutions that I haven't considered. if your customer does not want to become cloud literate. then maybe use FTP is an option because many cloud providers support FTP. Does z/VM FTP have a REXX API like z/OS? If not then maybe pipes would allow you to use REXX. Worst case, you stack commands to FTP and process the messages file. Another possibility is to send the file to a local PC that mapped the cloud as a local drive (e.g. MS Onedrive). You don't care if the solution is cloud enabled. Maybe your disaster recovery provider also provides offsite backup services. Step 3. Test, test, test. Setting customer expectations from the solution requires testing backup and restore, using someone with minimal knowledge and experience ensures disaster recovery doesn't require key personnel. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
