Deciding what data to back up can be a delicate balancing act for backup administrators. You probably have a limited backup capacity and a limited backup window during which to complete your data backups. At the same time, you have to back up enough data to meet your company's recovery needs. Fortunately, there are some relatively easy things you can do to set a data backup policy. Here's a list of considerations to help you decide what data you need to back up.
Data or system state backup?
One of the first considerations you need to make when figuring out what to back up is whether you need bare-metal recovery capabilities or if simply recovering data is sufficient. If you only need to back up data, this saves time and space. However, backing up only the data could prolong your recovery efforts because you may end up in a situation that requires you to manually reinstall your operating system and applications.
Requires Free Membership to View
When you register for SearchDataBackup.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Because your job never seems to get any easier, it’s our goal to keep you up-to-date on the latest backup tips, trends and technologies that will help you get the job done.
Rich Castagna, Editorial Director
In my own organization, deciding whether to perform a full, system state backup or to just back up the data is based on how difficult it would be to rebuild the server. For example, my primary file server uses a very simple configuration. If I had to set the server up from scratch, it would mostly be a matter of installing Windows and creating a couple of network shares. If that's the case, I usually back up only those volumes that contain data.
On the other hand, I have a server running Microsoft Office Communications Server (OCS) 2007. If you've ever installed OCS 2007, you know the configuration process is tedious to say the least. Even though there's technically no data residing on that server, I still perform a full, system state backup at least once a week so I don't end up having to rebuild the server from scratch one day.
Application-level backup considerations
Another thing you might take into account is the nature of the applications running on a server. For example, Exchange Server 2007 offers a server role called "edge transport server." An edge transport server's job is to sit at the edge of the network and perform message hygiene on inbound SMTP mail. It also shields your back-end Exchange organization from Internet traffic.
The interesting thing about an edge transport server is that you can get away with not backing it up, and it runs an extremely simple configuration. While Exchange Server is normally dependent upon the Active Directory, an edge transport server is the exception to the rule because it uses an application directory partition and copies whatever information it needs from the Active Directory to that partition. This means that even if the edge transport server were to fail, you wouldn't lose anything because all of the configuration information is stored in the Active Directory. Bringing a new server online simply involves installing Windows and the edge transport role, and then setting up an edge synchronization.
How dynamic is your data?
One last thing you need to consider is how dynamic your data is. For example, some servers run applications, but they're relatively static in nature. Because nothing ever truly changes on those types of servers, you can get away with never backing them up (assuming that you're willing to manually rebuild the server in the event of a failure) or just backing them up on occasion.
In contrast, some servers contain data that's so dynamic that it's pointless to back up the machine. A good example of this is the Exchange 2007 hub transport server. A hub transport server contains a jet database similar to the one used for mailbox stores. The difference is that this database is used only for message queues. Because messages pass through the queue extremely rapidly, the contents of the database change constantly, making it pointless to back up the database.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Serve). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful backup tip, timesaver or workaround? Email the editors to talk about writing for SearchDataBackup.com.
This was first published in February 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation