| Home > Disaster Recovery
Disaster Recovery
Disaster Recovery Strategy for Window Book clients
When reviewing this document, it’s important to understand that Window Book usually has little specific up-to-date knowledge about what is currently deployed in your shop. This includes but is not limited to: server and workstation hardware and their operating systems, virtualization and terminal server systems. Systems change quickly, virtualization happens without our knowledge and deployment plans change. As a result, the following should be considered a set of recovery guidelines that focus on the tendencies and needs of our applications and their data, rather than a specialized disaster recovery plan for your site.
The components typically deployed in a Window Book client’s site include a Microsoft SQL Server, Pervasive SQL Server and Clients (or Pervasive SQL Workgroup), as well as some combination of our desktop products (Dat-Mail, Postmaster, Tagmaster, eDocs Manager, DM Prep and Postal Package Partner) and automation services like the Window Book Automation Scheduler and Dat-Mail Daemon.
Considerations related to Microsoft SQL Server
Window Book is migrating off of Pervasive to MS SQL Server. Long time Window Book clients should be aware that this transition will require an increased emphasis on MS SQL Server in your shop and you would be wise to have resources available that can run, manage and maintain MS SQL Server and resources it uses.
Mail Volume, Database Sizing and SQL Server Express Edition
In most cases, Window Book is not familiar with your mailing volume or performance requirements, but for most medium and large mailers, it is likely that your volume will make it unacceptable to use SQL Server Express (what Window Book installs by default when installing a new SQL Server), particularly with its 1 gig of RAM, 1 CPU and 10 GB per database limitations.
SQL Server Standard Edition (which does not have those limits) will work fine on your existing servers. Unlike the Pervasive SQL license, please note that the SQL Server license purchase is our client’s responsibility. You can use an existing instance of SQL Server as long as it is SQL Server 2008 R2 or later.
Your mail volume and level of use of Intelligent Mail Barcode (IMB) related tracking in Dat-Mail will directly impact the timeframe of a move off of SQL Server Express Edition. Replication will also likely do that, as SQL Server Express Edition cannot act as a replication publisher or distributor. Likewise, Express Edition cannot run the SQL Server Agent, which is often used to drive replication processing.
The licensing considerations noted above must be considered when doing disaster planning. The sizing info above is provided to remind you that remote sites must have the ability to support the same amount of data as production at a reasonable performance level after failover.
Real-time backup of Microsoft SQL Server data
There are a number of vendors who provide real-time backup of Microsoft SQL Server databases. While we cannot recommend a specific vendor or product at this time, the real-time backup process can be an ideal way to keep your disaster recovery sites in sync with the production database.
Considerations related to Pervasive SQL
All Window Book applications that use Pervasive databases (Dat-Mail and Postmaster) must be closed when backups are being done. The Window Book Automation Scheduler, Dat-Mail daemon and PPP import agent must also be stopped before backups are run.
There are 3rd party systems that claim to be able to backup Pervasive databases while they are in use, but we do not have any experience with them. If you try them, you will need to be sure they handle your systems at peak workload and are capable of both switching to the replicated site as well as making it easy to return to your normal production system.
Considerations related to Text / Flat files
Text, Ini, Configuration, Log and other flat files
Flat files and configuration files (ini, etc) can be replicated to your DR site/servers via the client file replication software of your choice.
These files will include the .tps mail.dat file storage (which are typically zipped), various ini files, log files and similar. Specifically, we’re referring to the contents of the server’s wb product folder (usually \wb\) as well as \public documents\window book\. In addition, there are client-machine-specific configuration files on the various client. These files are stored in the WB product folder.
NAS systems sometimes have built-in functionality to replicate files. The SQL components are currently small enough that log shipping should work to replicate that data, but large mailers should consider more robust solutions.
Hot Folders
For file services of this nature where mail.dat, spoilage and other files are dropped into hot folders by Window Book, in-house applications or commercial software, we recommend the use of UNC paths versus mapped drives. We recommend using UNC because mapped drives don’t work with services and are tied to individual logins. The latter makes it easy to create a difficult to diagnose situation. For example, the symptom may be that the drive or folder isn’t visible to the app, yet the cause is that the service’s security profile never maps the drive – even though that same machine’s desktop login does map the drive and allows the app to work correctly.
Keep in mind that workflow may change with third parties and hardware-driven hot folder functionality when servers and/or clients migrate to failover sites. Consider how this mailing equipment might be used in failover workflow and how its access to hot folders will change.
Testing should be performed at the recovery site to make sure that hot folder permissions, setups and naming match the production configuration and that the setups pointing to those folders have the proper names. Service logins may also access these folders, so be sure to check that they have the necessary permissions to do so. This is likely to be “full control” for Window Book driven processes.
Client installations
When a server does a failover to a remote site, keep in mind you will redirect clients / workstations to the disaster recovery site.
WBIinstall.ini in \public documents\Window Book serves as a “direction finder” for various program and data file locations. This ini will need to be adjusted to point to the proper UNC / mapped drive locations in the event of a failover. This would be necessary on each client and server where WBI apps are being run.
In addition, the SQL Server instance location is stored in \public documents\Window Book\wbdb.xml. The instance named in that XML file will contain two Window Book created databases, wbdb and wbdbCla.
A SQL Server cluster would allow for failover to a recovery instance without changes to that xml file as long as the cluster doesn’t failover to a different instance name. My understanding of SQL Server clusters is that this is part of the cluster failover functionality, but if the instance name isn’t managed in that way for some reason, then wbdb.xml would also have to be changed on any server and client where WB apps are being run.
Virtualization
Virtualization makes disaster recovery easier, simply because you’re not as tightly bound to specific hardware as you would be without virtualization.
When it comes to disaster recovery and replication, If you are using VMWare, you might check out http://veeam.com. If it works as advertised, it might make the sync process much simpler, vs trying to get multiple products to synch ini, zip and other files. We haven’t used this tool as yet, but it looks like it has possibilities for this scenario and the reviews are good. It appears to be capable of syncing entire VMs as well as VMWare datastores - in real-time, while systems are up. For virtualized environments, this functionality has the potential to save a lot of time and effort.
Postal One!, TEM, etc
Installation of identical releases for Postal One!, including parallel configuration and TEM testing should be done in advance on the recovery systems so that PO issues are not an obstacle to getting production work done after failover.
These installs have dependencies on Java, logins, folder name setup and the like, so they will require a non-trivial install and testing in advance. Your client systems will need to be kept up to date after USPS updates the MD Client software, which happens several times per year.
Checklist
Before the failover event occurs
-
Backup / replicate MSSQL data to disaster recovery systems
-
Backup / replicate Pervasive data to disaster recovery systems
-
Backup / replicate TPS data to disaster recovery systems
-
Backup / replicate ini and other flat / config files to disaster recovery systems
-
Backup / replicate public documents\window book to disaster recovery systems
-
Install Window Book software and services
-
Install and configure current version of USPS MDR Client / Java
-
Test server
-
Test clients
After failover occurs
-
Make sure data and systems are accessible
-
Make sure data is up to date
-
Test server
-
Test clients
-
Communicate system status and access instructions to user community
After production system access is restored and/or local office is usable
-
Migrate MSSQL data from failover system
-
Migrate Pervasive data from failover system
-
Migrate TPS data from failover system
-
Migrate ini and other flat / config files from failover system
-
Migrate public documents\window book from failover system
-
Reinstall / configure USPS MDR Client / Java
-
Test server
-
Test clients
-
Communicate system status and access instructions to user community
Implementation
Guideline documents are one thing, implementation is quite another. Your challenge is to go from this document to implementation.
Failover to a disaster recovery site involves far more than migrating the data managed by your Window Book applications. You need to consider connectivity, email, backups, security, printing and interaction with external and internal systems, among other things.
Companies sometimes plan their disaster recovery process, but never test it. Others test the failover process but never plan and/or test how they will return to the production site. It’s easy to forget simple tasks if you don’t test - and they frequently relate to human factors more so than technology in the server room. If your employees can’t work at the office because it’s been destroyed, the quality of your failover site is of little consequence if you haven’t tested things like remote network access, RDP and webmail.
We strongly urge that a documented, step-by-step process that is fully tested by your staff comes out of this planning so that you can pull this off without having to find a path in the dark under pressure during a downtime – even with our help. Each individual tool might do its job, but getting a process established where they all work together when used in the right order will be essential to successful failovers, much less to reverting back to production after the situation causing the failover has been eliminated.
Disaster Recovery Support
It’s critical to understand that our customer support team is not knowledgeable with things like Double-Take, MSSQL replication, cluster failover, 3rd party sync / replication tools and the like. They know the mail business, the USPS and they know our products. However, they are not experienced enterprise IT staffers with a background in replication, DR, Citrix, VMWare, etc. As such, their expertise will be of limited use until the failover has completed successfully. The same goes for the sync/migration process when moving from failover back to normal production.
The time to involve Window Book’s staff is during design, implementation and testing so that your processes are ready for the next disaster. |
|
Frequently Asked Questions