exagrid.com · Primary Storage Snapshots Every primary storage vendor supports snapshot technology. Data is stored on primary storage disks in disk sectors, which are typically 512

Copyright © 2013 ExaGrid Systems, Inc. All rights reserved. ExaGrid and the ExaGrid logo are trademarks ofExaGrid Systems, Inc. All other trademarks or registered trademarks are the property of their respective owners.

Contents

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1 – Backup Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 – Primary Storage Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Snapshots Are Not a Second Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

The Limitations of Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Disk Capacity Required for Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Managing Snapshots Across Different Vendors’ Disk Storage Products . . 9

Snapshots Are Not Data Deduplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Pros and Cons of Primary Storage Snapshots . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 3 – Traditional Nightly and Weekend Backups . . . . . . . . . . . . . . . .13

Chapter 4 – Complete Data Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Primary Storage Snapshots and Traditional Nightly Backup—Complementary Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Requirements for Application Server Data Protection Determine the Optimal Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 5 – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

1

IntroductionIT data backup solutions are very complex to operate and manage. They must fulfill multiple business requirements, including:

• Short-term restore requirements.

• Long-term and regulatory retention requirements.

• Site disaster recovery requirements.

The purpose of the Straight Talk book series is to assist you in deciding which option or options for disk-based backup make sense for your organization’s many data storage, protection, and retention requirements. When you are evaluating data protection options, it is important to realize that no single solution can fulfill all of an organization’s needs. Typically, most IT organizations employ multiple solutions to satisfy these requirements.

A paradigm shift is taking place in IT data centers as companies move from storing backup data on tape to storing all backup data on disk. Various approaches are available to back up data to disk, including:

• Employing a traditional backup application that sends backup data to a disk-based backup appliance where data deduplication is accomplished within the deduplication appliance itself.

• Employing a traditional backup application that supports a software-based data deduplication feature, which sends deduplicated backup data to a standard low-cost disk subsystem.

• Sending backup data to a disk storage service that is part of a public cloud storage service.

• Leveraging primary storage snapshots to augment traditional backup software and processes.

2

Straight Talk About Primary Storage Snapshots and Traditional Backups

The purpose of this book is to describe backup requirements and to show which requirements are best met by primary storage snapshots and which are best met by traditional nightly backups.

Other Straight Talk books offered by ExaGrid include:

Straight Talk About Disk Backup with DeduplicationThis book discusses the strengths and weaknesses of various deduplication solutions that are part of traditional backup software applications or included in disk-based deduplication appliances.

Straight Talk About the Cloud for Data Backup and Disaster RecoveryThis book describes the strengths and weaknesses of leveraging cloud-based storage services for backing up and restoring data.

3

Chapter 1

Backup RequirementsIT departments must satisfy many business and regulatory requirements in the storing, protecting, and retaining of their organization’s data. The following list describes some of the major requirements that must be considered when comparing the use of primary storage snapshots with traditional backup applications for data protection.

1. Applications running in your organization may require hourly backups to protect data that cannot easily be recreated. Some examples of critical data applications include CAD/CAM design data, business databases, video editing data, legal document updates, medical records, etc., and it can be time consuming or impossible to recreate even one hour’s worth of data.

2. Users often overwrite or delete files and then need them restored. The average time for a user to realize a file is missing is anywhere from a day to as long as six weeks, depending on how frequently they access the files. Files such as quarterly spreadsheets or reports may not be detected as lost, corrupted, or accidentally deleted for many months. This is why many organizations keep at least 13 weeks (three months) of backup data onsite.

3. Virtual machine (VM) backups contain images of entire VMs, including the operating system, the applications, and the data. If a VM is corrupted, the entire machine needs to be restored from a backup copy. Backup approaches that only back up the data of a VM, and not the complete VM, will be ineffective in recovering the VM in the event of its loss or corruption.

4


4. Data corruption events can be caused by: faulty hardware (disk drives, memory, RAID controllers, etc.); an unexpected loss of power; a software bug in the operating system, file system, or application software that writes the data; or a security/virus attack. When one or more of these conditions occurs, the resulting data corruption may not be detected for weeks. In tracing back to the source of the corruption event, you may discover that the event started weeks earlier and that some or perhaps all of the data is corrupted. In this case, you need to delete the corrupted data and restore the data as it was prior to the corruption event. This will require historical versions of the data to be retained over time. It may take multiple restore attempts, going back in time, to identify a backup version that does not contain corrupted data.

5. Many applications and regulatory rules require backup copies of data to be saved at various time intervals and retained for long periods of time. Data related to legal discovery actions, lawsuits over a service-level agreement (SLA) violation, and regulatory audits for GLBA, HIPAA, or Sarbanes-Oxley, as well as data that needs to be reviewed as part of an audit from an external financial audit firm or the SEC, are all examples that fit this profile. For example, a critical record of the organization’s financial performance may need to be saved once a week for 26 weeks and then, after 26 weeks, a monthly copy must be saved for up to seven years.

6. In the event of a primary site disaster, a second copy of all backup data must be stored a safe geographic distance away from the primary site. Primary site disasters can occur when natural disasters strike (flood, tornado, tsunami, earthquake, hurricane) or in the event of a fire or other building-related failure. In any of these situations, a complete set of backup data needs to be retained in a separate location to completely restore the business to an operational level. Almost all organizations replicate their backup data nightly to an offsite disaster recovery site.

The goal of a complete and comprehensive backup plan is to make sure all of these requirements can be satisfied with one or more data protection solution (snapshots, backup, replication, etc.).

5

Chapter 2

Primary Storage Snapshots

Every primary storage vendor supports snapshot technology. Data is stored on primary storage disks in disk sectors, which are typically 512 bytes in size. Snapshot technology keeps track of which sectors have been modified since the last snapshot was taken and maintains those modified sectors in a logical container. For example, if you are editing a file and have snapshots configured to run hourly, then the storage blocks that change during that hour will be accumulated and saved at the end of each hour. The disk storage system maintains the most recent sectors, in addition to a specified number of historical snapshot copies of those sectors that change within the hour. This enables you to roll back/restore your data to an earlier point in time, based on the interval of the snapshots.

Snapshots Are Not a Second Copy

Snapshots reside on the same disk storage volume as your most recent data. In the event of a disk storage volume failure (disk drive failure, file corruption, etc.), not only is your current data lost, but all snapshot versions are lost. Snapshots are effective in recovering files that are accidentally deleted or overwritten by users, but snapshots provide no protection against the loss of the entire disk volume or disk subsystem. For this reason, virtually all organizations continue to run nightly backups to have a second physical onsite copy of all their primary

6


storage data. This backup is saved on a separate and independent storage medium, such as a set of magnetic tapes or a magnetic disk subsystem dedicated to storing backup data. Alternatively, having snapshots replicated to a second identical primary storage system at a second site can mitigate primary site data loss.

Blocksin a File

1

2

3

1

2

3

Blockson the Disk

1

2

3

Snap 1

Blocksin a File

1

2a

3

1

2

3

Blockson the Disk

1

2

2a

3

Snap 1

Blocksin a File

1

2a

3

1

2a

3

Blockson the Disk

1

2

2a

3

Snap 2

1

2

3Snap 1

1

2

3Snap 1

Figure1a Figure1b Figure1c

Blocksin a File

1

2

3

1

2

3

Blockson the Disk

1

2

3

Snap 1

Blocksin a File

1

2a

3

1

2

3

Blockson the Disk

1

2

2a

3

Snap 1

Blocksin a File

1

2a

3

1

2a

3

Blockson the Disk

1

2

2a

3

Snap 2

1

2

3Snap 1

1

2

3Snap 1


Blocksin a File

1

2

3

1

2

3

Blockson the Disk

1

2

3

Snap 1

Blocksin a File

1

2a

3

1

2

3

Blockson the Disk

1

2

2a

3

Snap 1

Blocksin a File

1

2a

3

1

2a

3

Blockson the Disk

1

2

2a

3

Snap 2

1

2

3Snap 1

1

2

3Snap 1


When the first snapshot is taken, all of the blocks that have been written have their block pointers maintained in the snapshot area. This is very space efficient.

After the snapshot, as new data is written to primary storage, new blocks of data are used to store that data. In this example, the 2nd block in the file would normally overwrite block 2, but with snapshots, this updated block 2a is written to a new empty block on disk. All future reads will see blocks 1, 2a, and 3 at this point, and the snapshot will retain the pointers to the original blocks 1, 2, and 3.

When a second snapshot is taken, that snapshot maintains the pointers to all of the most recent copies of block data, in this case, blocks 1, 2a, and 3. Snapshots themselves are pointers to actual disk blocks, but the “effective” snapshot space consumed is all of the space taken up by blocks that have been overwritten over time. The more write intensive the environment, the faster snapshot space is consumed.

7

The Limitations of Snapshots

Snapshots can be effective in maintaining critical file changes for a limited period of time (days), but they are ineffective in maintaining historical copies over longer periods of time (weeks, months, etc.). As an example, if snapshots are configured to run hourly, then exactly 168 (24 per day x 7 days) snapshots per week will be created.

To restore a file to an earlier version using snapshots, the disk storage system must merge the disk sectors from the current active data versions with all of the snapshot sectors that have been maintained. This sequential process must reach all the way back to the version of the file requested by the restore operation. The older the file(s) requested for restoration, the greater the number of snapshots that need to be processed. With 168 snapshots per week, or 672 snapshots per month, this could be a very time-consuming process.

If any single disk sector of any snapshot is deemed corrupt, then trying to restore to any earlier version will fail. The probability of a successful restore operation decreases with the age of the snapshot requested. Imagine attempting to restore a file from a year ago using hourly snapshots. It would require the sequential merging of data sectors from over 8,000 “perfect” sequential snapshots. As a result, most primary disk storage vendors limit the number of snapshots that can be managed per volume to between 200 and 500. With hourly snapshots, the historical data retention period is limited to between one and four weeks.

In addition, the rate at which users and applications change the data in primary storage can affect the number of snapshots that can be managed within its associated storage volume. The more primary storage data changes, the more rapidly the disk space available for snapshots is consumed. Consequently, fewer versions of snapshot data can be maintained. The oldest snapshot is typically removed when there is not enough space to maintain the most recent snapshot. For these reasons, it might not even be possible to retain the maximum number of snapshots on disk volumes that have a high degree of changing data.

Chapter 2 – Primary Storage Snapshots

8


Disk Capacity Required for Snapshots

If four weeks of snapshots are to be maintained, primary storage disk vendors recommend that the disk capacity allocated/reserved to store those snapshots must be the same size as the primary storage volume the snapshots are protecting. For customers who replicate primary storage at a second site, disk space also must be allocated for both primary and snapshot copies. For an application that requires 40 terabytes (TB) of primary storage, customers opting to maintain four weeks of snapshot history would have to purchase 80TB at the primary site and an additional 80TB at the remote site—four times the capacity required by the application.

For all of these reasons (snapshots consuming disk sectors in the same volume as the primary data they are protecting, the limited number of configurable snapshots, and the need for a large amount of additional costly primary storage to store snapshots), snapshots are typically used only to protect critical file systems and application data multiple times throughout the day. It is too costly to perform snapshots on all of the data due to the sheer amount of relatively expensive primary storage capacity consumed. In addition, given the limited space available for snapshots and the maximum number of snapshots that can be configured per volume, snapshot protection alone cannot meet the longer term retention needs most business applications and regulatory agencies require.

Primary - 40TB

Snaps 40TB

80TB OnsIte

Primary - 40TB

Snaps 40TB

80TB Offsite

9

Managing Snapshots Across Different Vendors’ Disk Storage Products

Most organizations deploy primary disk storage systems from two or more vendors to leverage features only available from certain vendors or to create competition among vendors for reduced pricing. The challenge with installing, configuring, operating, and maintaining primary disk storage units from multiple vendors is the complexity that comes with each vendor’s specific operating procedures, product features and limitations, user interfaces, and reporting systems. Snapshots further complicate the management of storage systems from multiple vendors because the implementation of snapshots is very different from one vendor to the next. And remember, each vendor’s snapshot disk sectors are maintained in that same vendor’s primary data disk storage system.

Snapshots Are Not Data Deduplication

Some vendors would lead you to believe that nightly backups can be directed to a primary storage system and that once the data is stored, snapshots can somehow perform deduplication of that backup data. But this approach yields no deduplication. When a backup stream is directed to a primary storage disk volume, all of the backup “files” written to that primary storage system are seen as new sectors of data. So taking a snapshot of that volume after the backup is completed results in all of the bytes of that backup stream being preserved again within a snapshot. Snapshots work by tracking the changes to disk sectors within a primary storage volume. Backup applications aggregate file, email, and database data into a backup file and give that aggregated file a unique name on every backup run. So to a primary storage system that supports snapshots, it appears as if a collection of new files has been created on the primary storage volume. All disk sectors associated with those backup files then become part of the next snapshot. This is undesirable, in that it would almost immediately consume all of the available snapshot space after just a single backup. The net result is that sending data from a backup application to the primary storage system with snapshots turned on yields no reduction in data because each backup job is seen as a new file. Snapshots are a disk block tracking technology, not a data comparison technology.


10


In contrast, a purpose-built backup appliance that supports data deduplication can identify exact or similar blocks/bytes of data within a single backup and among all of the backups that have ever been run, storing only unique blocks/bytes of data. Data deduplication for backup represents a very different technology when compared with primary storage snapshots.

Pros and Cons of Primary Storage Snapshots

Snapshots are most effective at protecting critical files throughout the workday, such that no more than one hour of work would be lost if a file is accidentally deleted or corrupted. However, in the event of a primary disk storage system hardware failure, all of the most recent data and all of the associated snapshots will be lost.

With snapshots, no backup agents are required and no data has to traverse the network; the snapshots are maintained on the same physical disk storage system as the primary data. As a result, multiple snapshots can be taken throughout the day with no disruption to user productivity. This approach is very appealing, but the many limitations of snapshots mean that protecting your organization from data loss due to primary disk storage system failures will require a traditional backup application.

Identical primary storage systems can be deployed at both primary and secondary sites with snapshots maintained at each site. In the event of a primary site disaster, the second site’s replicated data can be used almost immediately to begin disaster recovery operations. However, the use of snapshots in this configuration can be very expensive when compared with traditional backup solutions. Replicated primary storage systems with snapshots enabled could consume four times the amount of storage space as the primary storage data itself.

Snapshots can be effective in maintaining just a few weeks of short-term historical data to support quick rollback/restore operations. But snapshots cannot satisfy the backup requirements of long-term historical data retention. The number of snapshots per volume is limited by each vendor’s storage system implementation to just a few hundred. In addition, the storage space set aside for snapshots can be consumed very quickly if applications and users are creating and modifying data at a rapid rate.

11

Finally, maintaining snapshots across multiple vendors’ products can be challenging and costly in terms of IT expertise because each product will have unique features, limitations, configuration rules, reporting formats, etc.

Strong Use Cases for Primary Storage Snapshots

Weak Use Cases for Primary Storage Snapshots

Intra-day backups for intra-day rollback/restore points of mission-critical data

Primary storage snapshots live in the same volume as the primary data. If that volume is lost or corrupted for any reason, the snapshots are gone as well. Snapshots cannot replace traditional backups.

Short-term historical rollbacks/restores, up to a couple of weeks

Long-term onsite and offsite retention is needed. Snapshots cannot support months/years of data retention because only a limited number of snapshots can be maintained by either snapshot count or reserved snapshot capacity. This approach is very costly.

Up-to-date primary storage replicated and maintained at an offsite location; however, this could result in very expensive disaster recovery

Snapshots are too expensive to deploy for all of an organization’s data. Four times the amount of primary storage data will be needed to store and protect data onsite and offsite.

May be adequate for small remote offices or smaller organizations—under 2TB of data with no need for longer-term retention

Each primary storage vendor only supports its own snapshot tools and schemes. This means multiple disparate data protection tools to purchase, install, configure, and manage.


12


13

Chapter 3

Traditional Nightly and Weekend Backups

More than three million organizations have over 1TB of data and perform traditional nightly and weekend backups for data protection. Among the many available backup applications are SymantecTM BackupExecTM, SymantecTM NetBackupTM, IBM® Tivoli® Storage Manager, EMC® NetWorker®, CommVault® Simpana®, HP® Data Protector, CA® ARCserve®, Veeam® Backup & ReplicationTM, and many others. With these applications, backup agents must be installed on every server and many scheduled jobs must be configured to protect the data available to those servers. Each scheduled job also details where all of that job’s backup data will be stored—on low-cost magnetic tape, inexpensive disk storage, or a disk-based backup appliance that supports data deduplication. Disk-based backup appliances with deduplication only store the unique data within and among multiple backup jobs over time. This deduplication approach greatly reduces the amount of disk storage required to maintain backup data over time, resulting in reduced backup data storage costs.

Running backups heavily impacts both the application servers being backed up and the network to which those servers are connected. For this reason, backups are typically run during off-hours to minimize the impact on user productivity. During the week, only “incremental” day-to-day changes are typically backed up. On weekends, a “full” backup copy of all application server data is made.

14


Snapshots can be effective in providing data protection during normal working hours. For active application environments where losing more than an hour’s worth of data is costly to the business, snapshots can provide more frequent intra-day protection than a nightly backup.

Traditional nightly backups address all of the following data protection requirements:

1. Storing data in a separate onsite storage pool (tape, low-cost disk, disk-based backup appliance with deduplication). If primary storage data is lost or corrupted, a second copy is onsite to restore that data.

2. Storing backup data on lower-cost media (tape, low-cost disk, disk-based backup appliance with deduplication), rather than using a high-cost SAN as primary storage.

3. Backing up data to an independent storage destination (tape, low-cost disk, or a disk-based backup appliance with deduplication), regardless of whether primary storage is provided to application servers via direct-attached storage (DAS), network-attached storage (NAS), or storage area networks (FC/iSCSI SAN).

4. Backing up the entire image of a virtualized server such that its virtual machines (VMs) can be restored quickly in the event of any storage or server failure. Primary storage snapshots only record file changes over time, maintaining only changed sectors of disk data on the same storage device they are trying to protect. Traditional backup applications can maintain a complete VM image, including all of its associated data (OS software, system files, data files).

5. Performing full weekly/monthly backups to provide longer-term historical copies of all of the primary storage data to be protected. Although newer schemes such as incremental-only or synthetic full backups may improve the performance of nightly backups, backup vendors still recommend that a full backup be performed every one to four weeks. This eliminates the risk, and time, of trying to do a restore from dozens of weeks of incremental-only or synthetic full backups. It also eliminates the risk of recovering data from a series of primary storage snapshots, where data corruption in any of the snapshots back to the point of restoration may cause the restore operation to fail.

15

Chapter 3 – Traditional Nightly and Weekend Backups

Secure Data Center

MAN/WAN

Primary SiteBackup Job Cross Site Protection

Secure Data Center50:1 Efficiency

Secondary SiteBackup Job

Optimized Deduplication

6. Choosing among the flexible retention options available. A number of periodic full backups may be taken, but not all of these backups need to be maintained. For example, it might make sense for an application server to retain 26 weeks of weekly full backups, as well as seven years of monthly full backups, to satisfy regulatory retention requirements. All of the other intermediary backup versions can be deleted to manage backup media costs.

7. Recovering data after a site disaster is critical for all businesses. However, because site disasters rarely occur, it is important to keep site disaster recovery costs as low as possible. One cost-effective approach to providing data protection in the event of a site disaster is to deploy a disk-based appliance with data deduplication at the primary site that can replicate backup data to a secondary disaster recovery site after each backup job runs. With these deduplication systems, only the bytes of data that change from backup to backup are stored onsite, and only those changed bytes are transmitted to the appliance at the disaster recovery site. This reduces both storage costs and inter-site networking bandwidth costs.

The most cost-effective backup storage solution that supports long-term historical data retention is a disk-based backup appliance with data deduplication. Any of the popular third-party backup applications can direct their backup data to these appliances, just as they have done for decades with magnetic tape. The combination of sophisticated deduplication algorithms and low-cost drives makes this type of solution competitive when compared with traditional tape library drive costs. Only unique data is transmitted between the primary site and the disaster recovery site with these appliances, thereby reducing WAN bandwidth and cost.

16


17

Chapter 4

Complete Data Protection

A complete data protection scheme employs primary storage snapshots for intra-day protection as well as traditional nightly and weekly backups for longer-term backup retention and offsite disaster recovery protection.

Primary storage snapshots should be enabled for disk volumes that have mission-critical or time-sensitive data, where the loss of more than an hour of data changes may result in significant productivity loss to end users. A lawyer who is working on a court brief for an upcoming trial or an architect who is making significant changes to a design are examples of significant productivity loss if data is only being protected once a day by a traditional backup application. By performing hourly snapshots of this data, more up-to-date hourly versions of these files are available for restores in the event of data loss or corruption.

For the most critical data, primary storage snapshots should be maintained at both the primary site and the disaster recovery site to provide immediate access to this data in the event of a primary storage site disaster. Primary storage snapshots for critical data are a good policy; however, having all data protected with snapshots at both sites would be cost prohibitive and would only provide for short-term retention of data. For data that either does not require hourly protection or can take longer to recover from a site disaster, traditional backups should be employed.

18


Primary Storage Snapshots and Traditional Nightly Backup—Complementary Solutions

Unlike primary storage snapshots, traditional nightly backups provide protection for all application data, regardless of the primary storage type (DAS, NAS, SAN). All backup data is stored on physically independent and low-cost storage media such as magnetic tape or low-cost disk. If the primary storage system fails or is corrupted, recovering selected files, VMs, databases, etc., from a physically independent backup storage pool is only supported by traditional backups.

Another benefit of traditional backups is the longer term retention of periodic weekly and monthly backups. Many regulatory requirements expect data to be maintained for these extended retention periods, and only traditional backups can support that type of retention.

Traditional nightly backups, along with disk-based backup appliances with data deduplication, deliver a more cost-effective data protection solution when compared with the cost of maintaining an equivalent number of snapshots on more costly SAN/NAS onsite and offsite primary storage systems.

Requirements for Application Server Data Protection Determine the Optimal Solution

Primary storage snapshots should be used if you need to have data on application servers protected as often as once an hour. In such cases, any data loss or corruption situation can be rolled back to an earlier copy using snapshots. This works for short retention periods.

Primary storage snapshots with second site replication should be used if you have application data that needs to be active offsite within hours of a primary site disaster.

Traditional nightly backup applications with disk-based appliances with data deduplication are the most cost-effective data protection solution, regardless of where the primary storage data resides (NAS, SAN, DAS) or the required retention period.

19

To protect your organization from the complete loss of a primary storage system, where snapshot technology would be ineffective in recovering data, maintaining a traditional backup storage pool onsite using magnetic tape, low-cost disk, or a disk-based appliance with data deduplication is the only reliable method. Snapshots maintain historical volume data on the same volume they are intended to protect, so the failure of a physical volume renders the most recent version of data, as well as all of its snapshots, unavailable for restoration.

To protect virtual machines, maintaining a traditional VM image backup application is required for a successful restoration of each part of that VM. The image is backed up to low-cost disk or a disk-based backup appliance with data deduplication.

To retain historical copies of data for longer than a few weeks, you will need to employ a traditional backup solution. Primary storage systems that support snapshots only retain a limited number of snapshots; data cannot be protected for multiple months or years.

To retain the majority of your data and have it available for recovery within hours of a primary site disaster, a traditional backup solution with a disk-based backup appliance with data deduplication meets the requirement in a cost-effective manner.

Chapter 4 – Complete Data Protection

20


21

Chapter 5

Summary

Primary storage snapshots and traditional nightly backups are complementary–not competitive–solutions for protecting your application server data.

Primary storage vendors that also provide a traditional nightly backup product, primary storage snapshots, and disk-based backup appliances with data deduplication provide a complete set of solutions for data protection.

Primary storage vendors that do not provide a traditional nightly backup product or a disk-based backup appliance with data deduplication in their product lines tend to market primary storage snapshots as a backup solution, because that is all these vendors have to offer. However, snapshots alone cannot satisfy all of the requirements of a comprehensive data protection solution.

IT departments need to provide a mix of traditional nightly backups and more frequent snapshots to satisfy the cost, retention, disaster recovery, and recovery point objectives (RPO) of the various applications they have to support.

22


Primary storage snapshots are an excellent solution for protecting mission-critical active data both onsite and offsite. Mission-critical data may amount to only 10% to 30% of the total data that must be protected. But even if this mission-critical data is protected using snapshots, it must still be protected with traditional nightly backups to maintain longer-term history on more cost-effective backup storage media.

Most companies continue to protect their data using the tried-and-true nightly incremental backups with a full weekly backup of all data. They retain 13+ weeks of onsite backup data to recover deleted or overwritten files and corrupted data that may not be discovered for weeks. Companies maintain offsite backup copies in a disk-based backup appliance with data deduplication to quickly and cost-effectively recover from a primary site disaster. In the offsite system, they maintain the number of copies required by their external auditors for legal discovery, SLAs, and regulatory and financial requirements. Typically, three to seven years of backup data is required by businesses. However, industries such as healthcare may require even longer retention periods.

Snapshots are a great short-term retention solution for the small percentage of your mission-critical data. Traditional nightly backups are required to protect this data over longer periods of time as well as for all of your non mission-critical data.

About the AuthorBill Andrews is President and CEO of ExaGrid Systems and has over 30 years of experience in IT data center technology. Bill has also written “Straight Talk About Disk Backup with Deduplication,” a guide to the key considerations for disk backup, and “Straight Talk About the Cloud for Disk Backup and Disaster Recovery,” a guide to leveraging cloud-based storage.

ExaGrid offers disk-based backup with deduplication appliances.

For more information, contact ExaGrid Systems at:

800.868.6985www.exagrid.com

[email protected]

www.facebook.com/ExaGridwww.twitter.com/ExaGrid

www.exagrid.com

Documents

exagrid.com · Primary Storage Snapshots Every primary storage vendor supports snapshot technology. Data is stored on primary storage disks in disk sectors, which are typically 512