Recovering a Public Folder Database after a Hardware Crash

  • [アーティクル]

You’re just too "simple", to be true
Can't take my eyes off of you… :)

(Stolen from Andy Williams’ song “You're Just Too Good To Be True”)

 

So simple it is to recover a Public Folder Database in case of a hardware crash, that this song comes to my mind each time I handle such scenarios.

Let’s suppose we have an environment with 3 MBX Servers, each of them holding a replica of our dear public folder Database. Let’s call her PFDB1.

 

 

Each of the PFDB replicas is set as default PFDB for the corresponding Mailbox Database existing on the same server. (PFDB1 is default public folder DB for MDB1, PFDB2 is default public folder DB for MDB2 and PFDB3 is default public folder DB for MDB3)

If a hardware crash occurs on Mbx Server1 on the drive where the PFDB1 resides and PFDB1 is lost, first thing you may want to do is to set another default public folder database for the mailboxes residing on Mbx Server1:

 

Now all users can happily continue working on their public folders, creating items, deleting items and so on.

So what’s next?

After solving the hardware issue, you may want to mount the PFDB1. But... “Surprise”:

“At least one of this store's database files is missing. Mounting this store will force the creation of an empty database. Don’t take this action if you intend to restore an earlier backup or recover using a continuous replication copy of your database. Are you sure you want to continue?”

 

And THAT IS THE QUESTION: to be sure or not to be sure…

Well… There are cases, where you may have a Backup of the affected PF DB – these are happy scenarios.

And there are cases where you do not have a Backup of the affected PF DB – and these are still happy scenarios. :) .

That's because in both cases, you have the very easy and elegant way to recover it by simply mounting an empty public folder database. 

When the empty PFDB1 comes online, it is automatically brought to the current status of the other PFDB2/PFDB3, because they treat her like a new comer in the game. And since it exists on the list of game players (replicas of the PFDB), the other participants of the game (PFDB2/PFDB3) will welcome her gladly and will explain her the rules (PF hierarchy) and the pieces (PF content) of the game and so it will become “up-to-date” and will play the game with her pals.

If PFDB1 is restored from backup and it wants to rejoin the game, the other players will say “Hi, welcome back. Let’s see what you know, if you remember the rules and pieces.” Of course, being restored from backup, it will already have a certain status of the hierarchy and of the content. This status will be compared with the status of the other game players and if necessary it will be updated.

In other words, even if users have done some changes/deletions in public folders while PFDB1 was down, when it is brought online from backup, replication of both hierarchy and then content will be done in the desired direction, namely PFDB1 will be brought to the actual status of the other replicas in the environment.

So YES, I am sure I want to mount the database, even though this will force the creation of an empty database.

Comments

  • Anonymous
    January 01, 2003
    ThanksI wish 2013 was that easy:)especially the hierarchy mailbox/public folder
  • Anonymous
    January 01, 2003
    Hello Ana-Maria,it is a good idea to blog about this simple and effective solution to rebuild a public folder database. Thank you for the good cooperation in the corresponding support caseBest RegardsChristian