Co nabídne společnost Microsoft na veletrhu Invex Computer ´99

Diskuze čtenářů k článku

Brett Arquette  |  20. 04. 2001 18:50  | 

Data loss. Ugly words. They're words IT managers fear. I don't even like to say those words, let alone announce them to my users. Yet that's exactly what I had to do a few weeks ago.

Here's why. While doing standard maintenance, we booted our Microsoft Exchange server and noticed that none of the Exchange services would come up. With Microsoft's help, we discovered that a disk drive had gone bad and corrupted our Exchange Infobase, the database file that stores all the e-mail indexes and documents. We replaced the disk, reinstalled Exchange and restored the Infobase from the day before.

No luck. Exchange still wouldn't crank up. It turns out that the disk drive had been experiencing problems long before it expired and had been corrupting the Infobase for days. What amazed us was that Exchange hadn't created any errors in the application error log. It had run for 10 days with a wasted database without realizing that anything was wrong.

We were forced to find clean data, which meant restoring back 10 days, thus losing 10 days of data.

I've always believed I would never lose data if I was a good boy and backed up religiously. This practice has worked for me for 20 years. But at 4 a.m., my analyst and I sat traumatized, lit by the dim glow of our CRTs, wondering how many other organizations out there hadn't booted their Exchange servers in months. With or without backup, their Infobases could be garbage, too.

I asked Microsoft why Exchange doesn't have some automated functionality that could shut down its services each night, run the diagnostic and bring back up the services. I was told that Exchange is marketed as a 24-by-7 system and a service of that type wouldn't fit in with that strategy. The Exchange that I was using must have been the 24-by-7 minus 10 release, subtracting the number of days of data loss.

I asked Microsoft if anyone sells a utility that can check the integrity of the Infobase while the Exchange services are up and running. They didn't know. They did send us a white paper on disaster recovery that said you should back up your database regularly on a server at a separate site and run a DOS diagnostic utility. On the surface, it sounds easy enough, until you consider that a machine of that type would need enough disk space, maybe 12GB, to hold the entire Infobase. Then you would need to run the restore, which could take up to an hour, and run the diagnostic, which could take up to 2 hours. It all boils down to how much your data is worth and how many hours are you willing to spend checking it.

We've searched, but haven't found any solid solutions. We've written a DOS batch file that will shut down the Exchange services, run the diagnostic, mail it to an analyst for review and bring the services back up each night. It works for us because we don't run a 24-by-7 shop and can afford the downtime each night.

The bottom line: Microsoft Exchange, and possibly other new mail applications, have some problems. They are relatively immature and don't have the 20 years of stability of their mainframe forefathers. True, their user front ends are pretty, shiny and cool, but their back ends can't detect problems to prevent, well, you know what.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Fero Kohanyi  |  20. 04. 2001 18:50  | 

pripravuje sa pre Windows2000 nieco ako
BackOffice SBS pre NT Windows
resp ako sa bude riesit intgracia dalsich serverov do win2000 {exchange SQL ...{ to jest kupa vyhodnejsie ako balik a kedy planovat
s uctou Fero Kohanyi

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Megatest 20 procesorů

Srovnání 15 True Wireless sluchátek

Vyplatí se tisknout fotografie doma?

Vybíráme nejlepší základní desky