Server Backup Restore

When a server crashes and for some reason there’s data loss, maybe it’s a hard drive failure or something worse, bringing it back on-line can be a hard task. Even if it’s not a complete data loss, but a partial loss caused by an illegal intrusion, a virus or some accident, the task doesn’t get easier.

With some servers, geographic location can be an obstacle, since a company’s server might be located at one city while the IT department is located at another city or even another country, so restoring a server can become more difficult if there’s no “local” access which means that you can’t just plug in a display and a keyboard to work with it.

Another common issue when restoring a server is that sometimes it’s impossible to just tell users to stop hitting (by hitting I mean accessing services) the server, specially with busy servers on the Internet. Some services will keep a lot of files open or locked which means that in order to restore those files to a previous state you would need to stop the service that is locking those files and then restore them. Sometimes stopping a service just isn’t an option.

When it comes to databases, most modern databases have restore procedures that will allow you to restore a database without having to stop the database server, however this procedure usually involves several queries to the database as records are being reinserted or replaced, so if your database is huge, it might consume all available CPU and memory, locking you out of the server and sometimes bringing it to a complete crash.

That’s exactly why servers should always be backed up in two different ways. A server should be backed up completely in a not so often basis width differential backups performed often and also a separate backup for each service that runs in the server. That way the server administrator can evaluate and decide what’s better as his choices would be to take the server offline and perform a full restore using the complete backup and the last differential backup (we don’t recommend using incremental backups as those are slower to restore) or if the server should stay running and each service be restored individually bringing one service offline at a time.

However the best way to prevent such disasters is to always keep an eye on the health of the hard drives, so the administrator can anticipate when a hard drive is going to fail and therefore can take preventive measures such as setting up a mirror server to replace the faulty one or to perform a scheduled maintenance job alerting all users with some anticipation.