Disaster Recovery

Criteria to determine whether or not to back up a system

For infrastructure administrators, there is nothing more frustrating than expending precious time and system capacity to round out a data protection strategy for systems that don’t need backing up. IT pro Rick Vanover shares some criteria to help navigate these systems.

In many of my blogs, one may think my primary goal is to have a very clear handoff from application owners to infrastructure administrators. While there should be a smooth transition from these two groups, one hand needs to know about the other. If systems that don’t need to be backed up are being backed up, this can lead to incredible wastes in licensing, bandwidth, storage and precious time during backup windows. There are no steadfast criteria that will apply to all organizations on what does or does not need to be backed up. There is an entirely separate discussion about what tools or processes make up backup processes today or as it's more appropriately called, data protection.

As a general starting point, I’ve collected a few criteria to determine if a system does not need to be backed up. This is only a springboard of ideas for you to consider against your requirements; each situation is unique, as we all know. Here are a few situations where a system may not need to be backed up:

  1. Transporting code and configuration
  2. For some applications, the rebuild will always be quicker. In today’s world of automated deployments, it may just be quicker to re-create a system than perform a full recovery. A new build has a comforting sense of being a clean installation, whereas depending on the failure, a recovery may have system consistency risks associated with it. In my own experience I had a situation where the only thing unique about one system (amongst a number of similar ones) is an entry in an .INI file. With that, it may be better to keep the .INI file central instead of wasting the time and effort to back up an entire operating system.

  3. Parallel working systems
  4. If an application is configured in a pool where many systems are configured exactly the same, each system may not need to be backed up. A good example here is a pool of web servers serving exactly the same content. Other compensating controls such as central log management and central code repositories can make the need to back up all of the systems in a pool unnecessary.

  5. Development or test systems
  6. If you provide test systems to developers or application owners, does this system need to be in the backup rotation? This may be a situation where an out-of-band data protection strategy can be used. For virtual machines, possibly a scheduled snapshot once a week would be an adequate level of protection (be sure to script the removal of the snapshot). If the developers and application owners manage source code in a code repository, there again may be a reason that the system may not need to be backed up.

  7. User data managed centrally
  8. If a solid document management strategy exists for configuration items such as My Documents, user data can be protected across all systems centrally. If a system functions only as a user interface (such as a Windows Terminal Server farm) and a redirected profile puts all of a user’s data centrally, all of the terminal servers may not need to be backed up.

  9. Application data managed centrally
  10. Just like the user data subject, if an application’s relevant data goes to a centralized database server; it may be quicker and more comforting to rebuild the system in favor of a recovery. Each application behaves differently, so give consideration to what needs to be protected outside of the data.

These are just a few situations that I have come across over the years that can translate into dollars saved, backup windows less crowded, and less storage wasted.

What are some criteria you have for systems that do not require data protection? Share your comments below.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

25 comments
steven.footy02
steven.footy02

Before setting up the criteria, i belive you should check which tools are being used to perform the backup process. If you would use an application with de-duplication, use would reduce the time, backup window and stress on the machine by far. As you have mentioned in you post, if you have a web farm replicated on several servers, each having the same config and files, the application will only backup 1 server, cause the others are identical.

gavin142
gavin142

Mine is simple: Can we afford to live without it while it is reconstructed? if the answer is yes, then NO, don't back it up regularly. If NO, then it's backed up nightly.

santeewelding
santeewelding

Underfoot great terrible lizards. Thank you, Rick, and the rest of you.

tcunningham4
tcunningham4

The comments above covered most points, but did not mention the OOPS! factor, especially in the case of 'personal' files. In my 30+ years of experience, the vast majority of restores were of a file accidentally deleted by a user after working on it for several days, followed by actual data corruption, requiring the reloading of one or more database tables. Rick has given some good information, since it makes us rethink our own strategies. One thing I have found missing in most 'backup' systems, is the regular review of requirements. The best implemmentations of this do a regular 'disaster test' which may not be realistic in a small shop, but can save major headaches in a large one. Anyway, thanks, Rick!

mfde_cesare
mfde_cesare

On a past assignment for a financial institution, we backed up all data as this was the strategy. I can see (from my previous experience) why the article offers a better strategy. However, when you need to meet certain government regulation, a full backup of all servers may be necessary to reconstruct certain email conversations and documents that are subject to civil and/or criminal investigations. These issues should be taken into account before a final strategy is decided on.

elynes
elynes

Perennial question. The question at hand, though, is the requirements of business continuity.

CharlieSpencer
CharlieSpencer

Turn the system off. If no one's work is affected, you don't need to back it up regularly.

dawgit
dawgit

Money vs. Money... While you seem to be concerned with the Money spent on the time in doing Back-ups, more than a bit short sighted (IMHO), you seem to forget the possible losses in not doing Back-ups. Both in terms of business lost, or in ligation. With that in mind, let me tackle what you've given as examples... First we need to define just what is a "Back-up"? That is the keeping, or archiving of pertinent Data used by a particular organization. This is not always set in stone, agreed, but much of that is now set by law, or involves the core business, or, in fact may even be the core business. (software company) So, I'll take it point by point as you have layed out... 1). "Transporting Code and Configuration": Very rarely will a rebuild with-out a valid up-to-date Back-up involve less time to recent state. If even possible. You can at best bring a system to 'Ideal State' but that might be the limit. 2). "Parallel Working Systems": While many large organizations do deploy individual computers in identical set ups, they do not remain that way long. Each terminal operator, user will have separate uses of their equipment. A general wipe an re-image to the original 'Ideal State' will not restore their (the companies) Data. Data lost = Money lost. 3). "Development or Test Systems": Her you really need a definition of what you consider "Back-up". If you are doing 'snap shots' or working with a (hopefully a version oriented) 'code respiratory', you are already doing "Back-ups". In fact, in many engineering companies or organizations these or done in 5 minute increments. Automatically and set by policy. So "Back-ups" are done. 4.) "User Data Managed Centrally": Here you're assuming a Windows only world, but even if not in a Windows environment, you're referring to Dumby terminals with a terminal server. In that case than the Back-ups would be done on the server. In this case you are correct in not doing a Back-up on each terminal. But only if the terminal was indeed a 'Dumby Terminal'. Other wise it's same situation as #2. 5). "Application Data Managed Centrally": Here is a critical situation. That being the 'How' the data gets to the Central Management. In many situations this is done by data transfer over the Net. Irregardless of the method there can (and then will be) many times errors in the transfer, broken connections, a missed bit or two, or just errant corruption. It is paramount to that particular location that the data integrity be trusted, and not on the hope that the central management has it. In summery, your concept of Back-ups is IT department only, which in most cases is not the core business of the organizations we might be working for. Yes, one can restore the OS's to an "Ideal State" sometimes quicker, but that does not constitute a restored system. I can't think of any business or organization that is able to operate only on the OS that runs in most cases only in the background. Secondly, and perhaps most importantly, there are far too many legal reasons that require Back-ups irregardless of what their IT departments find 'easier'. E-mails, (all) Financial Data, Personal Data and the like are mandated to be archived (read: Backed-up). Also, any data lost is always a loss for that organization. "Back-up", "Back-up", "Back-up" (or you will pay) -d

b4real
b4real

For the lizards? Perplexing.

jasonemmg
jasonemmg

I backup everyone's "My Documents" folder to an hot-swap HDD and tape drive. If a PC should crash that employee can jump on a spare PC in the office and have continued access to their files via the network while a restoration is being done on his/her PC.

robo_dev
robo_dev

Because the whole premise of 'back up' in this case is implied to mean 'archive to tape'. In today's world, tape is being used less and less, as a primary backup method. In the olden days, it was your tape backups that were the most important method to protect your data. But tape backups create issues, mainly that they take a lot of time to do, and that backing up things like databases to tape typically requires special software add-ons for the tape backup solution. Today it more typical for an application to be on a RAID array that is part of a SAN, and the critical stuff is getting backed up with snapshots to other parts of the SAN and either duplicated to another SAN or possibly even mirrored offsite. So in terms of data protection, you've got it about 90% covered right there. Storage and SAN solutions have gotten so cheap that most organizations just put ALL the servers into that SAN pool, so all of them get the same level of data protection....it's easier to manage this way. How often would an organization using a SAN with all sorts of redundancy actually have to recover from tape backups? Not too often, typically only a really nasty DR scenario where their SAN got destroyed. So really, the question of 'what servers to backup' is not really a relevant question anymore, as the cost of storage and SAN technology has really made it unnecessary to even ask that question. And the concept of 'backup' is also not as clear anymore, as the use of tape is only a small part of an overall data protection strategy.

jasonemmg
jasonemmg

I back up everyone's "My Documents" to both a hot-swap HDD and tape drive daily. Every weekend I do a full backup of "VIP" computers to an external HDD which is switched out every Monday morning for safe storage This allows anyone whose PC may crash to jump on any spare PC and continue working during rebuild of his/her PC. Our "MOST CRITICAL" data,etc.. gets backed up off-site EVERY NIGHT!

b4real
b4real

To a central file server, back it up. And snyc the local copy to the file server. 3 tiers!

CharlieSpencer
CharlieSpencer

The key word is 'regularly'. You can shut down a user's desktop and damage that user's productivity, but most shops have use imaging to restore / replace a damaged user system. You don't need to back up that individual machine when you already have one for that class of system. You can shut down one node of a multi-server cluster without impacting productivity. Do you need a backup? Sure, but you don't need to back each one up outside of maintenance periods.

Tony Hopkinson
Tony Hopkinson

you don't need to versus not baclking up one that you should. Disproportionate, I should think. Not arguing against efficiency, just worried about a bean counter mind set. Err on the side of caution not cost.

jasonemmg
jasonemmg

I backup everyone's "My Documents" folder to a hot-swap HDD daily as well as a taper drive on our server. On the weekends I do full back ups of all the "VIP"(boss',managers,etc..)computers to the hot-swap HDD which is switched out every Monday morning. If a VIP PC should crash they can jump on any PC in the office and continue accessing their "My Docs" folder via the network while restoration in being done. I know its not necessary to backup an entire PC when we have the restore CD/DVD's and programs such as Office,etc. for reinstall but thats how the boss wants it done (he signs my checks!!)

b4real
b4real

I am not saying that nothing needs to be backed up. I'm saying that we probably backup SOME systems that don't need to be backed up.

robo_dev
robo_dev

The more typical configuration these days is that the servers themselves have only the OS on them and whatever apps are needed. Realistically, these do not change very often, so it makes no sense to backup something that has not changed, and something that could be rebuilt relatively easily. On top of that, many servers these days are virtual or are part of a cluster, so 'rebuilding' the server may mean only clicking a couple of buttons on the screen. Of course the data and databases are another animal altogether. One huge issue with this whole discussion is that it lacks context... the backup requirements and strategy for a workstation, a server in a mom-and-pop business, or a corporate database server are waaaaaaaay different.

taylorstan
taylorstan

What the article is trying to get you to understand is that you don't have to back-up "everything". For instance, out timeclock software is a DB. I back-up the DB but not the frontend application. No need to do that because if the server it is on fails, it's easier to just re-install the application with minimal info and reload the backed-up DB. The DB holds all the settings and configurations. This is what he is trying to get people to think about. What is it you are backing-up? Why back-up the application when the DB is the critical part? Saves time, bandwidth, and money(larger back-up space). I am always re-examining what our company backs-up. We use "My Documents" redirection. But it's not used properly. When I scan the folder the see what is in it. There is mostly users personal files like pics and music. This folder is currently being backed-up. Why do it if we are not properly implementing this system. I am going to suggest that we stop using it(frees up server and network bandwidth and server space) and don't back-it up (frees up more bandwidth and space in back-up cycle). All work docs and files are in other central location. I'm not worried about losing someone's pre-filled fax cover sheet.

CharlieSpencer
CharlieSpencer

"If systems that don?t need to be backed up are being backed up, this can lead to incredible wastes in licensing, bandwidth, storage and precious time during backup windows. ... These are just a few situations that I have come across over the years that can translate into dollars saved, backup windows less crowded, and less storage wasted." From the use of the phrase 'backup windows', I assume we're discussing routine regularly scheduled backups. Yes, I'm already creating backups of all of my servers before deployment, but many of them don't change often enough to require backing up except before and after applying service packs. Those aren't set to back up regularly or automatically just because some ill-advised policy mandates backing up all servers every 72 hours, even if they haven't changed in two months.

dawgit
dawgit

In by doing what you are saying, you are already creating 'Back-ups'. Are you not? By the tone and implications of this particular Blog Post, Back-ups are not needed at all. This I find both conflicting and can be to many non IT types, or those with limited Business, Organizational, or Industrial experience, to forgo the idea that Back-ups are a very important tool. If for nothing else when the krapp hits the proverbial fan... for the Forensics.

b4real
b4real

Is where the question is answered if other things are put in place, I think that strong policies supplemented by configurations such as folder redirection, active code repositories and good understanding of the application can make a good case for a system to not be backed up.