Claris Networks uses a Knoxville data center called Digital Crossing Networks. Recently, we were privileged to have Digital Crossing’s CEO, Dennis Corley, contribute his thoughts on stabilizing enterprise information technology through data centers like his own on the Claris Networks’ blog. Digital Crossing Networks has been operating East Tennessee’s premiere collocation data center for nearly ten years, and services organizations in Knoxville, Chattanooga, East Tennessee and throughout the Southeast. Digital Crossing achieves an “uptime” percentage of the coveted “five nines” or 99.999%. Data centers shoulder corporate customers’ mission-critical applications, cloud computing platforms, disaster recovery platforms and business continuity plans. With all that at stake, “uptime” is the gold standard. So, what does it take to keep a data center operating with such reliability?

The following areas comprise the “three-legged stool” supporting data center operations: Infrastructure, Maintenance, and People. Infrastructure is the group of industrial systems required to provide continuous power and cooling to the IT systems housed in the facility. It involves the design and implementation of electrical, mechanical, and security systems. Both the system design and the specific equipment installed must support the hardened, industrial requirements of 24x7x365 operations, and a good infrastructure will always have solid redundancy. Redundancy provides emergency backup if a primary system fails and allows a business to remain in operation during maintenance.

Maintenance is another essential leg of data center stability, and can be often overlooked for multiple reasons. For one, proper maintenance is expensive, and some IT companies may be tempted to skimp on maintenance to cut operational costs. Inexperience in contracting and managing maintenance vendors also contributes to poor data center maintenance. However, quality maintenance boils down to two things: the willingness to invest in proper maintenance and the experience and knowledge of what constitutes quality maintenance.

This leads to the third leg of the stool: People. The best infrastructure design and implementation can be taken down in the blink of an eye by human error. In fact, over 70% of data center outages involve human error. The operation and maintenance of a data center is a both a science and an art. When the line between them blurs, the data center’s stabilizing factor is the experience and knowledge of its people. There is no short-cut to attaining and retaining experienced people. The best data centers must invest in quality people and continue to invest in their skill-sets and tools to provide quality and excellence. These three legs—infrastructure, maintenance and people—form a bedrock foundation for building and operating a quality, highly reliable data center facility.

So the question becomes, “How do we effectively prepare for these disasters?”  Backups are good to have, but just having data to restore isn’t really a sufficient plan.  Technology only makes up about 15% of a solid business continuity and disaster recovery plan.  Having the right steps in place is what really makes the difference between success and failure after an interruption.

Sadly, most businesses aren’t properly prepared.  Around 93% of companies that lose their data center for 10 days or more file for bankruptcy within a year.  30% of businesses that experience a major fire fail within a year, and 70% fail within five years.  The statistics show that businesses are generally ill-prepared for interruptions. 

Poor preparation puts employees in danger, too.  We all remember those fire drills and hard-to-take-seriously chemistry videos from high school.  At their essence, those exercises are business continuity planning.  What will your employees do when your server room does catch on fire?  An emergency evacuation plan is a good idea for every office.  BC/DR plans not only protect your job but protect the safety of the people you work with (and the mannequin next to your office’s Bunsen burner).  

We can’t prevent disasters, but we can be ready for them.  It’s well said that “Planning is bringing the future into the present so that you can do something about it now.”  On top of preparedness, BC/DR planning gives you peace of mind that your business can handle what gets thrown at it (not to mention insurance discounts). 

Need more information about backups?  Companies like Claris Networks can help you be prepared.  Click here to learn more.

The system state includes the following files: the boot files (boot.ini, NDTLDR, NTDetect.com); the registry (including the COM settings); the SYSVOL (group policy and logon scripts); the active directory NTDS.DIT (on domain controllers) and if the certificate service is installed on the server, the certificate store.

As you know these are the critical files you will need to restore the operating system configuration to its previous working state if something goes wrong during your enhancement of the server. Having these backed up will give you a good fall back position and can save your but in case of an emergency.

Too many times I have seen people make major changes to their servers or workstations without taking the simple precaution of backing up the system state. Having good backups from the night before is an adequate precaution, but to restore from the backup media might take time and it may not be the most recent system state. This is time in which the server is down and costing the company money because it is down. Having a recent copy of the system state will save you time, money, and give you a piece of mind when enacting changes on the server.

I like to use the ntbackup that is resident on the Windows 2003 Server OS and the XP workstation OS to backup the system state locally. The job will take about 5 minutes on average. Backing up the system state across a network can greatly increase this time to unacceptable ranges. With an investment of about 5 minutes you have taken an additional step to guarantee a successful rollback.

I have found that some companies even backup the system state during the day to catch any changes between backup jobs that run at night. Again, the system state is backed up locally, but some even transferred the backup file to a designated web share using a third party software such as Robocopy.

For those who are using Window Server 2008 variants or Vista variants, you will not find the ntbackup. The methods you will use will be the command line wbadmin.exe utility. An example of the command to use would be:

  Wbadmin start systemstatebackup -backupTarget:D:

  In this command example, the system state is being backed up to the D: drive.

By taking these simple extra steps you can enhance your recovery success from a bad install. Does your IT company adequately back up your system? A couple of minutes before you make changes to a system can make you a hero in the eyes of the users and clients! Contact your Philadelphia IT Company today.

Backing up an organization’s critical data may seem like common sense or a topic that doesn’t require much attention. After all, who doesn’t recognize the benefits of running and maintaining good backups? Still there are many computer systems, especially databases, which are not properly backed up on a regular basis. FileMaker Server 10 makes it easier than ever to backup your FileMaker databases, but there is more to a backup plan than configuring your FileMaker Server. This article explores the elements of a full backup strategy including ways to avoid corrupting your backups and hosted databases, the capabilities of FileMaker Server 10, and the importance of system level backups in conjunction with FileMaker Server backups. All FileMaker Server features discussed in this article apply to both FileMaker Server 10 and FileMaker Server Advanced 10.

Keeping your backups safe

In a typical computer environment, system level backup software is scheduled to automatically copy files from one computer to another. Files are typically copied to a server located somewhere else on the network, to an external hard drive, or to tape and eventually moved physically offsite. The computer files are replicated bit for bit so if a file is open when a backup runs, unsaved changes may be lost. While many backup programs have ways of dealing with backing up open files, such as waiting for the file to be closed or using a last saved snapshot of the file, backing up databases has some extra layers of complexity.

FileMaker databases, particularly databases that are hosted using FileMaker Server, are constantly changing and can have several users attempting to commit changes to the database during the time of the backup. Running a system level backup on a hosted FileMaker database can result in a backup copy that is inconsistent or even corrupt. The original hosted file can also become corrupt as a result of the backup process attempting to copy it while it is being hosted. The database structure or data itself can end up damaged, which could cause the file to become unstable or data to be permanently lost.

The most important rule to follow when creating a backup plan is to never allow system level backup software to copy a FileMaker database file while it is being hosted.

Backups with FileMaker Server

FileMaker Server comes with a built- in feature to safely backup hosted FileMaker databases to the local hard drive. Using the Server Admin Console you can schedule as many backups as you would like. When you install FileMaker Server there are three backup schedules automatically set up: Hourly, Daily and Weekly. The Daily schedule is selected and set to run each night at 11:00 pm. Without doing anything extra, FileMaker Server will begin to back up all hosted databases keeping seven copies before overwriting any of them. The option to have FileMaker Server keep a certain number of backups without creating new schedules for each copy is a new feature in version 10. If you’re creating a daily backup, simply enter a 7 in the “number of backups to keep” option when configuring the schedule in the Admin Console. FileMaker Server will continue to create time- stamped copies until there are 7, one for each day. The next time the backup schedule runs it will overwrite the oldest copy. A similar retention schedule could be set up to keep 12 copies of monthly backups so you would always have a full year of backups.

FileMaker Server can perform backups while users are logged in and using the databases. The database files are simply paused until the backup routine is finished. Users will rarely notice when database files are being backed up. Even databases that are several hundred megabytes get backed up so quickly that the process is barely noticeable by users. In some cases though, particularly when storing images or other files in container fields, FileMaker databases can grow to several gigabytes in size. It may take several minutes or even a half hour to backup a large database, but that shouldn’t prevent you from including it in your backup plan.

If your system contains only one large database file that cannot be set to backup during the business day, you should at least schedule it to be backed up once each night. If possible, store records that contain a large amount of images, PDFs, or other binary data in a separate FileMaker database. Keep the large database in a different folder in your server’s data directory. Since backup schedules can be written to run separately on the different folders, the large database can be backed up at night while the smaller database can be backed up multiple times throughout the day.

Working with system level backups

Even though system level backup software should never touch your hosted databases, it is an important part of your overall backup strategy. After setting up a robust backup plan where FileMaker Server is creating backups of your databases on the local hard drive, you need to make sure that your system level backups are configured to copy those local backups to a remote location, such as an external hard drive, a separate file server on the network, or tape. Be sure to include the entire local backup folder in the system level backups. Since the local backups are not being hosted, they can be safely copied. Keep in mind that your system level backups should follow the local FileMaker Server backups, but you need to allow enough time for the local backups to complete.

A good backup plan is imperative to making sure that your critical databases are safe. You should take advantage of the features that FileMaker Server 10 has to offer, but remember that you also need a strategy for system level backups to copy the files to a remote location and eventually be moved offsite. The more robust your backup plan, the faster you will be able to get your databases back up and running in case of a system failure or disaster.