External backup

IDS 10.0 for example, any O/S. I've never understood why we have to an onmode -c block/onmode -c unblock when taking a clone of Informix's data disks for back-up purposes. To my simple mind if Informix can fast recover from the original disks it should by definition be able to recover from the clone. But I have it in my mind that someone here - may have been Madison - once sent me the perfect explanation of why this is not true. But I can't find it anywhere! Was it you, dear reader, and if so could you re-send it? Thx Neil

You just have to think about how the copy is done... Let's take dd as an example and just one chunk for simplicity. On time t0 you start dd of the file. It copies the first 50MB and at that exact instant informix decides to change a block at offset 40MB. When dd ends you'll have an invalid image. No way fast recovery can handle that. In theory if you guarantee that the changes are copied in the same time sequence they were made, recovery will work. But that's not easy to implement/guarantee. Another aspect, onmode -c block writes some info in the system pages. This is used to check that the ontape -p (physical restore) is ok. If the restore tool doesn't see that info it will complain. Besides this, you can imagine more weird scenarios. Imagine that you change the disk mirrors physically and replace them with others. You may want to have your system freeze until new ones are installed and in sync. HTH Regards. On Mon, Jul 27, 2009 at 4:16 PM, Neil Truby <neil.truby@ardenta.com> wrote: > IDS 10.0 for example, any O/S. > > I've never understood why we have to an onmode -c block/onmode -c unblock > when taking a clone of Informix's data disks for back-up purposes. To my > simple mind if Informix can fast recover from the original disks it should > by definition be able to recover from the clone. > > But I have it in my mind that someone here - may have been Madison - once > sent me the perfect explanation of why this is not true. But I can't find > it anywhere! > > Was it you, dear reader, and if so could you re-send it? > > Thx > Neil > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

----- Original Message ----- From: Fernando Nunes Newsgroups: comp.databases.informix To: Neil Truby Cc: informix-list@iiug.org Sent: Monday, July 27, 2009 4:57 PM Subject: Re: External backup >> You just have to think about how the copy is done... Let's take dd as an example and just one chunk for simplicity. >> On time t0 you start dd of the file. It copies the first 50MB and at that >> exact instant informix decides to change a block at offset 40MB. When dd ends you'll have an invalid image. No way fast recovery can handle that. In theory if you guarantee that the changes are copied in the same time sequence they were made, recovery will work. But that's not easy to implement/guarantee. --------------------------------- Thanks for that. But most SANs have the principle of "consistency groups" where all the clones are kept at the exactly the same point in time as each other. Obviously in IDS one of these would span all the LUNs in a db server. So I come back to the central point: if it is possible for IDS to fast recover 100% of the time from its primary disks following an interruption, BY DEFINITION it shouls be possible to do the same from an exact clone of those disks?

Neil Truby wrote: > IDS 10.0 for example, any O/S. > > I've never understood why we have to an onmode -c block/onmode -c > unblock when taking a clone of Informix's data disks for back-up > purposes. To my simple mind if Informix can fast recover from the > original disks it should by definition be able to recover from the clone. onmode -c block flushes all dirty pages to disk and prevents any updatesfrom happening. This makes it possible to get a consistent copy of the chunks. In order to do fast recovery, it is a requirement to get a consistent copy of the disks. > > But I have it in my mind that someone here - may have been Madison - > once sent me the perfect explanation of why this is not true. But I > can't find it anywhere! > > Was it you, dear reader, and if so could you re-send it? > > Thx > Neil

-----Original Message----- From: Madison Pruet [mailto:mpruet1@verizon.net] Sent: 27 July 2009 19:38 To: Neil Truby Subject: Re: External backup Neil Truby wrote: > IDS 10.0 for example, any O/S. > > I've never understood why we have to an onmode -c block/onmode -c unblock > when taking a clone of Informix's data disks for back-up purposes. To my > simple mind if Informix can fast recover from the original disks it should > by definition be able to recover from the clone. > onmode -c block flushes all dirty pages to disk and prevents any updatesfrom happening. This makes it possible to get a consistent copy of the chunks. >> ***** In order to do fast recovery, it is a requirement to get a consistent copy of the disks. **** Thanks. I follow all of this. But if IDS can't reliably fast recover from a set of cloned disks for these reasons, how can it fast recover reliably from the *original* disks which by definition are identical to the clones ...?

Neil Truby wrote: > -----Original Message----- > From: Madison Pruet [mailto:mpruet1@verizon.net] > Sent: 27 July 2009 19:38 > To: Neil Truby > Subject: Re: External backup > > Neil Truby wrote: >> IDS 10.0 for example, any O/S. >> >> I've never understood why we have to an onmode -c block/onmode -c >> unblock when taking a clone of Informix's data disks for back-up >> purposes. To my simple mind if Informix can fast recover from the >> original disks it should by definition be able to recover from the clone. > >> onmode -c block flushes all dirty pages to disk and prevents any updates> from happening. This makes it possible to get a consistent copy of the > chunks. > >>> ***** In order to do fast recovery, it is a requirement to get a > consistent copy of the disks. **** > > Thanks. I follow all of this. But if IDS can't reliably fast recover > from a set of cloned disks for these reasons, how can it fast recover > reliably from the *original* disks which by definition are identical to > the clones ...? When a system crashes and is recovered, it is as a point in time (i.e. as of the crash). The process of recovery includes 1) physical recovery and 2) logical recovery. Basically, the first time an active page is changed after a checkpoint, the before image of the page is written to the physical log. At the start of recovery, we apply all of the before images from the physical log file which will bring the instance to a point of consistency as of the last checkpoint. From there we enter logical recovery by applying the logical log records taken since the last checkpoint. If we were to attempt an external backup without performing onmode -c block, we would not be guaranteed of taking a copy of a consistent image because writes would be occurring to the disk while the copy was being made. Chunk pages could be flushed from the buffer pool, additional writes to both the physical log file and the logical log file would occur. onmode -c block prevents all of that from happening. Therefor, onmode -c block is a requirement for external backups. The key thing in both recovery and in external backups is that we must get to a point of physical consistency before we can replay the logs. > >