Tony, I'm not impressed with the writing in the article. Parts of it are misleading. The picture showing the disaster and the RPO/RTO timelines on it are OK, but this paragraph leaves a bit to be desired:
<quote> For example, if you have a 4-hour RPO for an application then you will have a maximum 4-hour gap between backup and data loss. Having a 4-hour RPO does not necessarily mean you will lose 4 hours' worth of data. Should a word processing application go down at midnight and come up by 1:15 am, you might not have much (or any) data to lose. But if a busy application goes down at 10 am and isn't restored until 2:00 pm, you will potentially lose 4 hours' worth of highly valuable, perhaps irreplaceable data. In this case, arrange for more frequent backup that will let you hit your application-specific RPO. </quote> The example of a busy application going down at 10 and not being restored until 2 has nothing to do with a 4 hour RPO, they're describing a 4 hour RTO. The RPO could still be 5 minutes, if the data had been backed up at 9:55 and the application went down - and trashed the data requiring a data restore - at 10:00. In a nutshell, RPO has to do with how much elapsed time you can handle between the time a backup is done and a data loss occurs, and RTO is after the loss, how long you can handle being down before your applications are back. The example in the article didn't show that. Rex -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tony Thigpen Sent: Friday, January 31, 2020 10:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: 3592-E07 Radoslaw, I think you don't understand RPO correctly. read: https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html Tony Thigpen R.S. wrote on 1/31/20 11:24 AM: > W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: >> Radoslaw Skorupka wrote: >>> To complement and clarify: when using physical tapes (* see below) >>> your RPO and RTO may be 36 hours or zero. >> No, your RPO certainly won't be zero. A backup is a (hopefully >> useful) representation of data as it existed historically, at some >> particular past >> >> moment(s) in time. It takes some amount of time to run a backup -- >> let's call that "minutes or longer" for working purposes. Backups run >> at periodic intervals -- let's call that "hourly or less often" for >> working purposes. Your backups, without something else, facilitate a >> best case RPO >> >> that's as long/big as the maximum (worst case) time elapsed since the >> start of your last good backup. That practically always(*) means a >> RPO of "a couple hours or more." >> >> A long/big RPO usually holds RTO back too, but there are a few rare >> exceptions. On the other hand, it's quite possible to have a long/big >> RTO with a RPO of zero. >> >> (*) Why not "always"? Exotic, contrived exceptions might be possible, >> such >> >> as custom software that synchronizes writes directly to local and >> remote tape. > > No, my RPO *is* zero. We do not talk about backup itself, which is > ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media > the backup is representation of historical data. > What I'm talking about is time delta between primary and secondary > (local, remote) backup copies. > And again: some (typical?) modes of VTS replication are not > synchronous, so there is time delta between local copy is closed (and > marked as done) and remote copy is also finished. For duplex write in > HSM both tapes are being written simultaneously, so end of backup job > means you have both copies ready. > > Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* > the time to "historical representation". VTS non-synchronous mode adds > the time also (much less). but HSM duplex write add zero. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
