The switch over by a replication is definitely quicker, but it doesn't offer the same protection againt logical errors. In such case it may be necessary to restore the state from 2 or even 6 hours earlier. Furthermore I'm not sure how much an asynchronous replication affects the performance, which for us is still a critical issue. It also increases the complexity and adminstration.

The Database is 26GB. It takes nearly 2 hours for a full backup. A restore within the rewuired 30 minutes is therefore impossible.

--- In firebird-support@yahoogroups.com, Aage Johansen <aagjohan@...> wrote:
>
> nhiggs wrote:
> <<
> Aim:
> To deliver the required business continuity (RTO/RPO) I need to
> create an "application consistent" SAN based snapshot of the Firebird
> Databse disk every hour. In case of a logical error the snapshot can
> be later mounted and the database restarted with a previous good version.
>
> Solution:
> My current solution is to "freeze" or "quiece" the IO to the databse
> file by setting the database in backup mode. Then to flush the file
> system buffers to disk using sync.exe and then create the snapshot on
> the storagesystem. Afterwards the databse backup mode is turned off.
> ...
> >>
>
> I haven't used nbackup, so the following may be of no use, but anyway...
> 1.
> Maybe replication would be a good solution. And switch-over should
> be fairly quick.
> 2.
> For how long can the system be unavailable after a failure? You can
> probably backup a 3GB database in 10 minutes (online, without any
> "freeze" or "quiesce"), but a restore might take 30 minutes. Maybe
> this is too much, in particular if your database is large/huge. At
> least, there is no interruption of service unless a failure happens.
>
> Either of this should produce a copy/backup that is 100% ok.
>
> I believe someone on this newsgroup has written about a
> "almost-hot-standby" system, but I don't remember details (or the author).
>
>
> --
> Aage J.
>