BackupExec stops PostgreSQL service
am 10.06.2010 15:33:22 von Rob RichardsonThis is a multi-part message in MIME format.
------_=_NextPart_001_01CB08A1.7FBEAF6F
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Greetings!
=20
In an attempt to satisfy our client's requirements for redundancy, we
ended up with an unusual (at least to my inexperienced eyes) system
configuration. Our client has two buildings that use our application.
Each building has an application server and a storage server. All are
runnning Windows Server 2003. An iSCSI controller running on a
building's storage server is configured to map an image on the D drive
of that server to appear as the H drive on the building's application
server. So, anything written to the H drive by the application server
actually is stored in STORAGE\\d:/DataStorage/data.img. PostgreSQL 8.4
is running on the application server, configured to use the H drive to
store data. Therefore, data is actually being stored on the storage
server's D drive. =20
=20
The storage servers for each building also have the task of backing up
data for the other building. Symantec's Backup Exec is used for that
purpose. But we found that when the backup job that was supposed to
back up one building's storage server ran, the PostgreSQL service on
that building's application server stopped. We tried excluding the
folder containing the image used as the H drive from the backup, but it
didn't help. =20
=20
Has anyone else seen a Backup Exec backup job stop a Postgres service?
Can anyone suggest ways to avoid the problem? (I'm already fighting to
run PostgreSQL on the storage server instead of the application server.
I see no benefit to having the service running on one machine and
storing data on the other. If a terrorist blows up the storage server,
it will take all of ten minutes to re-install PostgreSQL.)
=20
RobR
=20
------_=_NextPart_001_01CB08A1.7FBEAF6F
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
charset=3Dus-ascii">
attempt to=20
satisfy our client's requirements for redundancy, we ended up with an =
unusual=20
(at least to my inexperienced eyes) system configuration. Our =
client has=20
two buildings that use our application. Each building has an =
application=20
server and a storage server. class=3D937081513-10062010>All are runnning =
Windows Server=20
2003. An iSCSI controller running on a building's storage server =
is=20
configured to map an image on the D drive of that server to appear as =
the H=20
drive on the building's application server. So, anything written =
to the H=20
drive by the application server actually is stored in=20
STORAGE\\d:/DataStorage/data.img. PostgreSQL 8.4 is running on the =
application server, configured to use the H drive to store data. =20
Therefore, data is actually being stored on the storage server's D =
drive. =20
storage servers=20
for each building also have the task of backing up data for the other=20
building. Symantec's Backup Exec is used for that purpose. =
But we=20
found that when the backup job that was supposed to back up one =
building's=20
storage server ran, the PostgreSQL service on that building's =
application server=20
stopped. We tried excluding the folder containing the image used =
as the H=20
drive from the backup, but it didn't help.
anyone else seen=20
a Backup Exec backup job stop a Postgres service? Can anyone =
suggest ways=20
to avoid the problem? (I'm already fighting to run PostgreSQL on =
the=20
storage server instead of the application server. I see no benefit =
to=20
having the service running on one machine and storing data on the =
other. =20
If a terrorist blows up the storage server, it will take all of ten =
minutes to=20
re-install PostgreSQL.)
------_=_NextPart_001_01CB08A1.7FBEAF6F--