solverxyz wrote:"IF the computer server with the VM witch installed with TM1 server just burned by a horriable fire, how could get my input data back 10 seconds before?", they said.
I know there are many technology for real time backup in DB or cloud storage, but they are all based one one thing: data are saved in HDD.
Which, as we know, are impervious to fire. Especially the ones that write simultaneously to clusters on multiple cloud servers distributed across the globe without any performance impact on the application.
solverxyz wrote:Maybe it hard to mirror data in memery only via pure software or it's too expensive , I am not sure.
No, the real problem is that the solutions are insufficient for the magnitude of the problem faced. They don't cover the very real possibility that each cloud server that you're backing up to could be simultaneously hit by meteors the size of Texas, which might then generate 70 metre high tidal waves that short out the memory chips of the client machine not to mention ruining the office carpet.
In such a case it would be impossible for them to recover their data as it was 10 seconds earlier.
I'd suggest implementing a further backup to a spacecraft in geostationary orbit, but that still won't overcome the possibility of a star going hypernova and generating a gamma ray burst that takes out the satellite and the Earth with it.
And the soggy office carpet, come to that.
And man, do you know how much the data roaming charges are for geostationary satellites? Not to mention the property damage insurance premiums for hypernova GRBs?
I'm sorry, maybe someone else can take this ridiculous situation seriously, but I just can't. Your client needs to get their head out of their rectal passage and into the real world. Here's the fact, Jack. There is
NO method,
NO way,
NO how that can give you an iron clad guarantee that you will not lose
any data at all (certainly not down to a 10 second granularity) in the event of the physical destruction of your hardware. Even if this Heath Robinson construct of sucking out the tm1s.log file from the API actually worked, have you
seen how slow querying the transaction log is? All you need to do is query it through the GUI, which would doubtless use the same API functions, or an equivalent of them. It would utterly slaughter the performance because the server would be too busy querying the transaction log to do any actual work.
Disaster recovery, just like any system design, is about balance. So you save regularly, backup regularly, use off site storage, if possible have multiple servers in different locations. But you
cannot guarantee that you will not ever lose data, on TM1 or any other system, without making the system's whole raison d'être backing itself up constantly.