=?UTF-8?B?UmU6IENhbiBEaXNrIG1pcnJvcmluZy9kYiBzbmFwc2hvdHMgcmVwbGE=?= =?UTF-8?B?Y2UgdGhlIHVzYWdlIG9mIHRha2luZyBkYXRhYmFzZSBiYWNrdXBz4oCP?=

jpierrot@chubb.com wrote: > > 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. > This will not work consistently and so not at all. IDS keeps much information about the state of the database server and its disk structures in memory only flushing it to disk at checkpoint time. At best restarting an IDS instance pointed to such a copy would require a long recovery period. At worst it will not work at all. Not as an automated scheduled copy. There is a way to take archived by copying the disks directly in IDS 10.00 and later. It is called External Backup and Restore. Read the manuals for the requirements, the point is that the engine has to be involved and certain onmode commands have to be executed before the copy is begun and after it is completed. Art S. Kagel Oninit > 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? > Your IDS engine will refuse to startup because the disk structures are inconsistent. If it does start you have no way of knowing if the data on disk is complete until the engine happens to read a damaged page. > > 2- What are the benefits and disadvantages of going that path if you > see any. > > Using IDS 7.31.UD8 and IDS 10.0.UC8 on AIX 5.2 > Using the 7.31 engine there is no direct support for external backups and no way to rename the chunks to point to the copies. So, even if you make the copy correctly (the engine has to be checkpointed and blocked before the copy and no users will be permitted to update any data until the copy is completed and the engine block removed) you will have to change the chunk links manually or using a script to point to the copies before you will be able to restart the instance. Finally, there will be no way to recover the instance to the moment it crashed. You will only be able to recover to the time of the last copy. If you use ontape or onbar instead and your databases are created with logging and you archive your logical logs you can recover to the moment of the crash and only uncommitted transactions and the few committed transactions whose final commit record were in a buffer in memory and not flushed to disk will be lost. (With UNBUFFERED LOG databases this possibility is vanishingly small and only one transaction can be at risk in this way at a time.) My real question is: in IDS's ontape and onbar you have two of the most modern, most reliable archive and restore facilities available in any database. Why would you want to revert to circa 1960's backup procedures? Art S. Kagel Oninit > > Thanks in advance for your anticipated help! > > jp > > ------------------------------------------------------------------------ > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >