Spam Filter ISP Support Forum

  New Posts New Posts RSS Feed - Offsite Disaster Recover Plan
  FAQ FAQ  Forum Search   Register Register  Login Login

Offsite Disaster Recover Plan

 Post Reply Post Reply
lyndonje View Drop Down
Senior Member
Senior Member

Joined: 31 January 2006
Location: United Kingdom
Status: Offline
Points: 192
Post Options Post Options   Thanks (0) Thanks(0)   Quote lyndonje Quote  Post ReplyReply Direct Link To This Post Topic: Offsite Disaster Recover Plan
    Posted: 24 September 2008 at 8:48am
Hello everybody,

I'm in the process of comming up with a disaster recovery plan whereby we have servers at an 2nd location ready to run (as seamless as possible) in the event of a disaster at our primary site.

Running SpamFilter Enterprise I know I am able to run multiple SFE servers linking back to a central database. I also know that should the database, or primary site where they SQL server is located fails, that SFE will continue to function from its local text files. In this scenario, not quarantining emails during a short period would be acceptable, however we would need to restore the quarantine and associated functions (such as email notifications) within a reasonable amount of time.

As the SQL database is not replicated, and as far as I'm aware would be costly to do so (correct me if I'm wrong there?), my only option would be to schedule SQL backups, and then transfer that backup file to the remote server on a regular/automated basis. In the event of a disaster we would restore this database and point the 2nd instance of SFE to it. The downside to this would be that if any email addresses had been whitelisted, or new addresses registered in tbllogins & tbl_authorizedto since the backup ran, they would be lost - we would be unaware of any discrepancies, as would the customer be unaware of any issues until somepoint in the future the customer realises and calls to complain.

So... what I was thinking is that a 2nd instance of SFE run dormant and point to the primary database, that way its local text files will be up to date and ready to run straight away in the event of disaster. At this point quarantine functions would be offline. If I then restored a local copy of the SQL database as explained above, any newly registered email addresses or whitelists would again be lost as SFE syncronises its local text files with the restored, and potentially out of date, database.

To get around this, is it possible for SFE syncronise the database with the contents of the local text files instead of SFE syncronising its local text files with a database? Or is there an easy way of achieving this?

I'm not concerned about loosing the contents of a quarantine in the event of a disaster, but what I am concerned about is bringing the quarantine facility back online in a timely fashion, and not loosing any 'settings', such as registered email addresses/domains/whitelists etc. If anybody has any alternative ideas I'd be happy to hear them :)


Back to Top
LogSat View Drop Down
Admin Group
Admin Group

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4077
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 24 September 2008 at 4:19pm

I'll try to answer as much as I can here, even though it's likely that more questions will follow :-)

To begin with, please note that, starting from v3.5.4.725 (but we recommend using v4.x), should the quarantine database go offline, SpamFilter will queue all spam emails to be archived to a local disk cache. When the database comes back online, all this spam will be automatically archived to the DB. This cache is kept in the \SpamFilter\Quarantine directory. As an additional side-note, if you simply move the contents of this directory to another SpamFilter server pointing to another database, this second SpamFilter server will begin immediately archiving these emails to the second database.

Going back to SFE and the database going offline. When this happens, SpamFilter Enterprise will indeed continue to function. Please do note that performance will be affected, as for many operations SFE will continue to access the database before timing out. Furthermore, most of the filtering settings will be read-only and cannot be modified, as there is no database to update.

Your 2 main issues in the event of a "database" disaster are (1) loosing recently archived emails, and (2) loosing recently updated settings.

Being able to replicate in real-time your database would solve both, but bandwidth between the two site would need to be adequate (= expensive).

If you can afford loosing a portion of your recently archived emails, you can then opt for the scheduled transfer of backups.

For the other settings, there's a couple of options I can think of. First of all, you could enable SQL replication for all tables except for the tblMsgs and the tblQuarantine (these latter two store the actual emails and headers, and thus cause the bulk of the traffic). Without these two, the amount of data being updated is minimal.
Another option is to forget the database, and simply replicate the \SpamFilter\Domains directory structure. This contains the file-based settings that SpamFilter Enterprise uses. If you replicate this directory to the second server, this second server can run off these file-based settings without a database.
Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

This page was generated in 0.117 seconds.