Re: Can Disk mirroring/db snapshots replace the usage of taking database backups?

<jpierrot@chubb.com> wrote in message news:mailman.908.1207757633.20610.informix-list@iiug.org... Hi Gang, I am evaluating a software out there called FalconStor and the software company promises to provide a solution that would make backing up the informix database or any other dbms using native commands such as onbar, rman, etc unnecessary. They said that their software takes a snapshot of the disk at regular interval from 5 minutes to one hour, depending on the frequency you want to set it. Then If you want to restore to any point it time , you just have to point your dbms to that snapshot and you are current as the time that snapshot was taken. Data within instances can also be refreshed from one environment to another using the same method. I need some questions of concerns to ask this vendor. Any help would be greatly appreciated. 1- What are the pitfalls of not taking regular conventional backups but to rely on the snapshots to restore the databases to any point in time in the event of a crash? 2- What are the benefits and disadvantages of going that path if you see any. <-- END jpierrot@chubb.com --> My first concern would be that this approach does not sound like it is guaranteed to capture a consistent version of the database -- especially w.r.t. the contents of the logs versus the contents of the data pages. For example, although the database enforces the usual write-ahead logging requirements for consistency, so that log changes are persisted before corresponding data changes are allowed to be flushed to disk, a snapshot tool that views everything it backs up as a black box with no internal semantics might back up log images before it backs up data images. The result would be a snapshot in which write-ahead logging is violated, i.e. there could be changes to data pages that have no corresponding records in the logs. In that case if you ever need to run through fast recovery, you may get corruption and failures (for example, it is not possible to roll back an uncompleted transaction, some of whose changes are reflected in data pages, if it has no corresponding records in the logical log images). It might also capture an image that has some but not all of the data changes of a particular transaction that was supposed to be atomic. A familiar banking example is that a customer transfers money from account A to account B. The debit of A and the credit of B must either both occur, or neither occur (else money is either created or destroyed, and one side or the other is sure to be unhappy with the results :-). A snapshot capture may have captured disk images in which only one of these two operations was persisted in the data pages, and moreover depending on backup order the logs it captured might have no record of either A or B. The result is an inconsistent database and no way to roll back or roll forward to make it consistent. You might also not immediately realize there is an inconsistency. Another issue with this approach is that IBM Support may be less able to help if you experience a problem. Advantages of using the disk snapshot approach are that you have lots of easily created backup images that might be useful to have around in case of some catastrophic failure. You should probably make sure you continue to back up at least the logical logs using IDS's native mechanisms. That might alleviate some of the problems of the snapshot having captured log images that are "old." -- Kevin Cherkauer Software Engineer IBM Informix Dynamic Server -- Database Kernel