CIO Concerns: Maximizing Your Data Protection Budget, Part II

Mike Daniels, Product Manager

In Part I of this blog entry, I talked about maximizing your data protection budget by considering consolidation and looking at disk-to-disk (D2D) or disk-to-disk-to-tape (D2D2T) solutions. In this article, we’ll look at deduplication and some budget savers versus budget busters.

Enter deduplication. When you start deduplicating data it can drastically decrease the budget requirement for disk due to reduced space needed. It reduces storage by eliminating redundant data. One unique instance of the data is retained, and redundant data is replaced with a pointer to the original unique data. So, less space, less money.

Further savings with disk is recognized with significantly faster recovery times. Remember cassette tapes and how cool it was when CDs entered the market?

If you wanted to hear song number three on your tape, you needed to hit

fast-forward and wait. When CDs showed up, you could enter any random track and get your song near-instantaneously. I don’t know any IT managers who don’t want to deliver this functionality for data restore to their teams. So, not only are you buying less disk with deduplication, but you speed up recovery producing further cost-savings.

Another disk benefit is reliability. There is no argument that disk is more reliable than tape. Anyone who uses tape will tell you it’s fragile. Humidity, temperature, number of uses will all negatively impact your chance of getting your data back. Are you confident you have proper guidelines regarding tape storage at your organization? What happens if the person whose job it is to swap tapes and take them off-site, leaves them in the car to run a quick errand, in the middle of summer, and you happen to be located in Arizona? Basically that tape is not usable. But you won’t know until you have to restore something. That’s an extreme example and unlikely that any IT manager is advising his team to manage their tapes in this fashion, but I’m sure you’ve heard of or experienced yourselves numerous accounts of data loss when recovering from tape.

I’m not saying you do away with tape backup. It’s a good solution for long-term storage, but it certainly is not cost-effective when it comes to reliable, fast recovery. If you can get the correct business unit managers supporting a disk-based purchase initiative, you can easily show tremendous cost-savings associated with productivity and reliability to your CFO.

I’ll leave you with one last cost-savings tip, choose one vendor with a suite of products to support your data protection requirements. You don’t want multiple finger-pointing vendors when you have questions, and it makes life much easier for your team to learn and stay trained on the applications.

Consider a couple of things when evaluating vendors: 1) how easy are the solutions to administer, 2) how responsive is support. I had an experience with a customer who was using a competitive product. While I was on site, he called the other vendor’s support to help resolve some issues. Meanwhile, he allowed us to do a proof of concept with our product. We installed, configured, and completed a backup before our competitor’s support team had even answered the customer’s call.

Make sure you understand every aspect of a vendor’s support program before you enter into a contract. This is overlooked far too often, in my experience, until you actually need support. This oversight can unexpectedly impact your budget and increase the overall cost of the product.

So here’s the thing: it’s not difficult to find cost savings when it comes to adequate and proper data protection. Just remember…

CIO Concerns: Maximizing Your Data Protection Budget, Part I

Mike Daniels, Product Manager

How do you protect an enterprise environment without an enterprise budget? I see this problem so frequently in customer data centers, trying to adequately protect data in a budget constrained environment.

Don’t despair. There are several things your team can do to maximize your budget.

First, consider consolidation. Do different departments or branch offices have their own protection solutions? Maybe some are on Mac, Windows, or Linux. Each likely has critical some critical data and applications that need special attention. If you haven’t already, consider consolidating requirements into a central location with heterogeneous protection. By centralizing, you recognize savings on economies of scale – one large environment versus small islands. You’ll have one maintenance cost, perhaps price breaks on standardized applications addressing multiple departments’ needs rather than each sourcing its own solution.

Many large companies have been doing charge backs for a long time. Why not you too? Departments were going to pay for the protection anyway, and now you could actually end up saving them money by charging a smaller fee than their previous individual payments. Not only is it an overall cost-savings measure, it addresses what should be your top concern: data being protected properly by the experts who really know how to do it.

Aside from consolidation, ensuring fast, reliable restores is one of your best budget-savers. One way to do this is to look at a disk-to-disk (D2D) or disk-to-disk-to-tape (D2D2T) solution. I know what those of you who haven’t already done this are thinking… new hardware, new applications, how is this possibly a cost-savings measure? Stay with me, because, ultimately, this could save you a lot of money.

In the past, disk-based backup has been a niche feature, because backing up to disk could take anywhere from ten to fifty times the amount of space versus server space. This was a big hindrance for people not moving to disk-based solutions faster.

In Part II of this blog entry, we will examine deduplication as it relates to maximizing your data protection budget, and we will discuss some budget savers versus budget busters.

Selecting the SQL Server Backup Type to Use with NetVault: Backup – Part 2

Mike Daniels, Product Manager

In my previous blog we talked about the importance of defining a SQL Server backup strategy that included defining the types of backups that you will perform. To determine which backup types you use, you must first understand the difference between the various SQL Server VDI-based backup types. To recap, NetVault: Backup APM for SQL Server offers the following type of VDI-based backups:

• Full database
• Differential database
• Copy-only
• Incremental transaction log
• Tail-log
• Full file and filegroup
• Differential file and filegroup
• Partial database
• Differential partial database

In this blog, we will discuss Full File and Filegroup Backups, Differential File and Filegroup Backups, and Partial Database Backups.

Full File and Filegroup Backups are designed for SQL Server databases that contain multiple files or filegroups. These backups, like the Full Database Backups back up all the data in one or more Files or Filegroups. A complete set of Full File backups is equivalent to a Full Database backup. The benefit that the Full File Backup has over the Full Database Backup is that with the Full File Backup, you can recover an individual file without requiring the recovery of the entire database. This will speed up the recovery process for recovery scenarios where you only need to recover the damaged files and not the entire database.

While Full File and Filegroup Backups are advantageous for larger databases they also work well for databases that contain different update characteristics. For example if you have a large database where some of the database files are modified frequently, some are modified less often, and maybe even a read only file, using a standard backup strategy of Full Database and Differential Database Backups which backups up the entire database including the files which are rarely modified or even marked read-only. Having the ability to choose exactly which files and/or filegroups to backup and when to backup those files up is a more efficient solution. With these advantages does come additional complexity in that you must understand that a media failure can make a complete database unrecoverable if the damaged file(s) can not be recovered because it wasn’t backed up.

Selecting the SQL Server Backup Type to use with NetVault: Backup – Part 1

Mike Daniels, Product Manager

Before deploying the NetVault: Backup APM for SQL Server, you must first define your SQL Server backup strategy. The purpose of creating a SQL Server backup strategy is to be able to recover a database that has been damaged or become corrupted. When creating a backup strategy, you define the type and frequency of backups to meet the data protection requirements of the database or application.

First, it is important to understand the VDI-based backup types that can be performed with SQL Server in order to give you an idea of what each one does. The NetVault: Backup APM for SQL Server offers several types of backups including

• Full database
• Differential database
• Copy-only
• Incremental transaction log
• Tail-log
• Full file and filegroup
• Differential file and filegroup
• Partial database
• Differential partial database

With full database backups, you are backing up the entire database. This type of backup also includes part of the transaction log so that the full database backup can be completely recovered. A full database backup represents the database at the time that the backup was completed. These backups are typically easy to use because they contain all the data in the database. For smaller databases that can be backed up quickly, this is the recommended method for backups due to the simplicity of the recovery process. As databases become larger and the full database backups take longer, you probably want to consider supplementing full database backups with differential database backups.

Differential database backups only record the data that has changed since the last full database backup. These backups are smaller and faster than a full database backup, which saves time but does start to increase the complexity of the backup scheme. For large databases, it is Microsoft’s best practice to follow full database backups with a series of differential database backups. Since each differential will get larger than the previous, it is also recommended that you schedule a new full database backup on an appropriate schedule.      There are special situations where you might want to have a database or a backup of the database, but do not want to impact the regular backup rotation or scheme. A typical SQL Server backup will change the database by updating the differential bitmap. This change affects how future backups and restores are done. By using copy-only backup, you can create a backup that is independent of the regular SQL Server backup sequence. This means that the differential bitmaps are not changed and your regular backup sequence will not be affected. Typically these backups are ideal for circumstances where you require the database, but do not want to affect you production system, such as creating a test environment, or for standby databases.

Transaction logs contain the data for all of the actual transaction that have occurred on the database. In SQL Server, taking routine transaction log backups are essential to be able to fully recover the data. With transaction log backups, you have the ability to recover a database to a specific point in time or to the point of a database failure. With incremental transaction log backups, you capture all of the transaction logs including transaction logs that have been generated since the last full database/file or filegroup, differential database/file or filegroup, or incremental transaction kog backup. These backups are also the means by with the SQL Server logs are typically truncated in order to reduce the amount of space required by the SQL Server logs.

Tail-log backups are backups that capture the logs that have not been backed up yet. These are typically the last backup restored in a SQL Server recovery sequence because it completes the log chain. With SQL Server 2005 and 2008, it is required that you run a tail-log backup prior to restoring any database that is currently attached to the SQL Server Instance. Because of this, the tail-log backup is typically the first step in any recovery process.

While restores are the primary consideration when creating a backup strategy, you have to understand what the different types of backups are actually doing so that you can make a conscious and informed decision.

In my next Blog we will continue the discussion on different types of SQL Server backups and their purpose.