LogSat Software

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   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 :)

Thanks.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
lyndonje Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 31 January 2006 Location: United Kingdom Status: Offline Points: 192	Post Options Post Reply Quote lyndonje Report Post Thanks(0) Quote Reply 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 :) Thanks.

LogSat Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104	Post Options Post Reply Quote LogSat Report Post Thanks(0) Quote Reply Posted: 24 September 2008 at 4:19pm
	lyndonje, 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

LogSat Software

Site Navigation[Skip]

Spam Filter ISP Support Forum

Offsite Disaster Recover Plan