Subject | Re: [firebird-support] Shadow files on a network share |
---|---|
Author | Brian L. Juergensmeyer |
Post date | 2004-01-22T15:26:16Z |
Hello, Ian,
From the IB 6.0 Beta Operations Guide (available at
http://www.ibphoenix.com/downloads/60OpGuide.zip ):
Shadowing has the following limitations:
- Shadowing is not an implementation of replication. Shadowing is one-way
writing,
duplicating every write operation on the master database. Client
applications cannot
access the shadow file directly.
- Shadowing is useful only for recovery from hardware failures or accidental
deletion of
the database. User errors or software failures that corrupt the database are
duplicated in
the shadow.
- Recovery to a specific point in time is not possible. When a shadow is
activated, it takes
over as a duplicate of the database. Shadowing is an "all or nothing"
recovery method.
- Shadowing can occur only to a local disk. Shadowing to a NFS filesystem or
mapped drive
is not supported. Shadowing to tape or other media is unsupported.
I hope you aren't planning on using a shadow for more than a backup to your
nightly GBAK backups. Since shadows are vulnerable to virtually everything
that will corrupt a primary database, they are (in my personal opinion) very
rarely worth the effort of creating them and the hard drive space to
maintain them.
In any case, attempting to maintain a valid shadow over a network connection
to a remote box is chancy at best. I don't know this for certain, but I'd
expect that it would be relatively easy to corrupt the shadow in case of
network difficulties without receiving any errors back to the server. Then,
something bad happens to the primary database, you try to flip over to the
shadow, and discover that it is virtual gibberish.
HTH,
Brian
From the IB 6.0 Beta Operations Guide (available at
http://www.ibphoenix.com/downloads/60OpGuide.zip ):
Shadowing has the following limitations:
- Shadowing is not an implementation of replication. Shadowing is one-way
writing,
duplicating every write operation on the master database. Client
applications cannot
access the shadow file directly.
- Shadowing is useful only for recovery from hardware failures or accidental
deletion of
the database. User errors or software failures that corrupt the database are
duplicated in
the shadow.
- Recovery to a specific point in time is not possible. When a shadow is
activated, it takes
over as a duplicate of the database. Shadowing is an "all or nothing"
recovery method.
- Shadowing can occur only to a local disk. Shadowing to a NFS filesystem or
mapped drive
is not supported. Shadowing to tape or other media is unsupported.
I hope you aren't planning on using a shadow for more than a backup to your
nightly GBAK backups. Since shadows are vulnerable to virtually everything
that will corrupt a primary database, they are (in my personal opinion) very
rarely worth the effort of creating them and the hard drive space to
maintain them.
In any case, attempting to maintain a valid shadow over a network connection
to a remote box is chancy at best. I don't know this for certain, but I'd
expect that it would be relatively easy to corrupt the shadow in case of
network difficulties without receiving any errors back to the server. Then,
something bad happens to the primary database, you try to flip over to the
shadow, and discover that it is virtual gibberish.
HTH,
Brian