Thank you Jon, I will convey your suggestions to the customer and talk with them to see how it fits their needs. Arye Shemer
On Wed, Oct 25, 2023 at 1:32 AM Jon Perryman <[email protected]> wrote: > On Tue, 24 Oct 2023 09:52:26 +0300, Arye Shemer <[email protected]> > 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 [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
