BakBone Blog

News & Views from BakBone® Software

Posts Tagged ‘Dawn renee Campbell’

« Previous Entries

Calculating Physical Disk Space for Licensed NetVault: SmartDisk Capacity

Posted by Dawn renee Campbell on March 8, 2010

Dawn renee Campbell, Senior Product Manager for NetVault: SmartDisk & NetVault: Backup

After you have determined how much NetVault: SmartDisk (NVSD) capacity you need to license, the next step is calculating how much physical disk space you will need.

As we discovered in my Calculating NetVault: SmartDisk License Capacity blog, NVSD is licensed based on the Logical Capacity of the data that it can store. However, in Deduplicated NVSD Instances, Logical Capacity does not match Physical Capacity or physical disk space. This is because NVSD Deduplication Option packs up to 12 times more protected data into the same storage area for a 92% reduction in storage footprint.

Deduplicated NVSD Instances

A Deduplicated NVSD Instance can have a combination of both Deduplicated and Non-Deduplicated data. In this configuration, calculating the total Physical Capacity or physical disk space is comprised by calculating the Physical Capacity for the Deduplicated Backups followed by calculating the Physical Capacity for the Non-Deduplicated Backups and totaling the sums.

Deduplicated Backups

The Physical Capacity or physical disk space required for Deduplicated Backups in Deduplicated NVSD Instances is equal to the Size of Weekly Full Backups + Unique Data Size and is calculated using the following formula:

(Size of Weekly Full Backups) +

Size of Weekly Full Backups + ((Size of Weekly Full Backups * Weekly Change Rate)

* Weekly Full Backup Retention Period)

+ (Size of Daily Backups * (Number of Daily Backups between Weekly Full Backups

* Daily Backup Retention Period))

Non-Deduplicated Backups

The Physical Capacity or physical disk space required for Non-Deduplicated Backups in a Deduplicated NVSD Instance is calculated using the following formula:

(Size of Non-Deduplicated Weekly Full Backups * Weekly Full Backup Retention Rate)

+ (Size of Non-Deduplicated Daily Backups * (Number of Daily Backups between Full Backups * Daily Backup Retention Period in Weeks))

Total Required Disk Space = Deduplicated Backup Disk Space + Non-Deduplicated Backup Disk Space

The Total Required Disk Space is divided into the Staging Store and the Chunk Store. If different file systems or disk spindles are going to be utilized for the Staging Store and the Chunk Store, it is important to know how much of the Total Required Disk Space will be allocated to the Staging Store versus the Chunk Store. The calculations below can be used to make this determination.

Read the rest of this entry »

Posted in BakBone North America | Tagged: , , , , , , , , | Comments Off

Calculating NetVault: SmartDisk Licensed Capacity

Posted by Dawn renee Campbell on February 17, 2010

Dawn renee Campbell

You have chosen which data you want to deduplicate with NetVault: SmartDisk (NVSD), and now you are tasked with calculating how much capacity to license.

NVSD is licensed based on the logical capacity (or total size) before deduplication of ALL backups that are stored in NVSD.

NVSD provides the ability to deploy multiple instances that can be targeted for backup from multiple NVBU Servers. When calculating the licensed capacity for NVSD, the capacity across all deployed NVSD instances must be included. For example, if two NVBU Servers are targeting backups to one or more NVSD instances, the capacity of the backups from both NVBU Servers must be included in the calculations.

Understand that NVSD licensed capacity is NOT based upon any of the following:

  • Actual size of the storage pool, staging store, or chunk store
  • Actual size of the backups after deduplication

Calculating NVSD capacity requires the collection of the following values for each NVBU Server that will target backups to NVSD. When inserting these values into the calculations, be sure to include the sum of the values across ALL the NVBU Servers that will target backups to NVSD. For example, if NVBU Server 1’s size of weekly backups is 40GB and NVBU Server 2’s is 60GB, use 100GB as the size of the weekly full backups.

If separate NVSD instances for non-deduplicated and deduplicated data will be used, perform the calculations below separately for the backups that will not be deduplicated versus the backups that will be deduplicated. This will enable you to know exactly how much NVSD non-deduplicated capacity needs to be licensed and how much capacity needs to be licensed for the NVSD deduplication option.

If a single NVSD instance will be used for both non-deduplicated and deduplicated data, include both the values for non-deduplicated and deduplicated data in the single calculation.

Size of Weekly Full Backups

Size of all the full backups that will be targeted to NVSD. For example, if  SQL Server, Exchange, Oracle and File System backups will be targeted for NVSD, calculate the total size of ALL the full backups for SQL Server, Exchange, Oracle and File System.

Weekly Full Backup Growth Rate

Average weekly growth rate of the full backups, which are included in the size of weekly full backup calculation. Weekly full backup growth rate is a critical factor in accurately determining NVSD sizing. For example, the average of all of the full backups is growing 10% each week. Another convenient method to calculate this is to base it on annual data growth.  For example, an annual growth rate of 100%, or an annual doubling of data, would represent a weekly growth rate of 1.333%.

Weekly Full Backup Retention Period in Weeks

Number of weeks that full backups will be retained in NVSD. Restores are faster when being performed from disk-based media than when being performed from tape-based media. Increasing the amount of protected data that is available on disk-based media increases the number of restore scenarios that can be performed from disk-based media.  Requiring tapes to be located, retrieved and loaded in order to perform a restore slows down the restore speed and increases downtime.

Additionally when performing deduplication, the longer the data is retained in NVSD, the better the deduplication ratios will be because more duplicate chunks are found, thereby enabling the ability to pack more data into the same storage footprint. This enables even more protected data to be available via disk-based media.

To obtain the most ideal deduplication ratios, we recommend a retention period of 12 weeks or more.

Size of Daily Backups

Size of all the daily backups that will be targeted to NVSD.  For example, if SQL Server, Exchange, Oracle and File System backups will be targeted for NVSD, calculate the total size of ALL the daily backups for SQL Server, Exchange, Oracle and File System.

Daily backups are interim backups between the weekly full backups. These are anticipated to be incremental or differential backups, and as such, will generally be much smaller than the weekly full backups.

Daily Backup Growth Rate

Average daily growth rate of the daily backups that are included in the size of daily backups.  For example, the average of all the daily backups is growing 1% each week.

Number of Daily Backups between Full Backups

Number of daily backups that are performed between full backups. For example, if full backups are performed on Sunday and daily backups are performed each day, Monday thru Saturday, the number of daily backups would be six.

Daily Backup Retention Period in Weeks

Number of weeks that daily backups will be retained in NVSD. Daily Backups provide the ability to perform fixed-point-in-time restores, thereby reducing the recovery time objective. Daily backups can be retained for the same period of time as full backups, which enables fixed-point-in-time restores for the entire weekly full backup retention period.  Fixed-point-in-time restores are typically performed using backups taken within the last four weeks. As such, it is possible to retain weekly full backups for one retention period and daily backups for a shorter retention period. This would allow you access to daily backups for a set period of time, such as four weeks, while providing you with access to full backups to a longer period of time, such as 12 weeks.

NVSD Sizing Calculator

With the NetVault: SmartDisk Sizing Calculator, you simply enter all the above values.  It will calculate not only the amount of NVSD capacity to license but also tell you the number of NVSD instances and the amount of memory for each NVSD instance. The NVSD Sizing Calculator can be obtained from your BakBone representative.

In my next NVSD blog, we will learn how to calculate how much physical capacity is required.

Posted in BakBone North America | Tagged: , , , , , , , , , | Comments Off

Encrypting all Backups vs. Job-Level Encryption with NetVault: Backup

Posted by Dawn renee Campbell on January 27, 2010

Dawn renee Campbell

  

You have selected the encryption algorithm you are going to use with the NetVault: Backup (NVBU) Encryption Plugin and have decided whether to encrypt your primary or secondary backups, but now you are not sure if you should encrypt all of your backups or use NVBU 8.5’s new job-level encryption feature.  

Prior to NVBU 8.5, your only option was to encrypt all the backups for the NVBU Server or a Heterogeneous Client where the NVBU Encryption Plugin is installed, but NVBU 8.5 gives you the ability to only enable encryption for specific jobs.  Understanding the benefits of both options will help you choose the best strategy for your environment.  

Encrypt all Backups  

The NVBU Server or Heterogeneous Client should only be configured to encrypt all its backups when  

  • All the NVBU Plugins installed on the NVBU Server or Heterogeneous Client are compatible with the Encryption Plugin
  • All backups from the NVBU Server or Heterogeneous Client require encryption
  • Primary and secondary backups require encryption
  • Backups will be targeted to NetVault: SmartDisk (NVSD) devices for deduplication

For a list of NVBU Plugins that are not compatible with the Encryption Plugin, refer to the NetVault: Backup Encryption Plugin Release Notes.  

Job-Level Encryption  

Job-level encryption for primary backups is beneficial when  

  • Not all the NVBU Plugins installed on the NVBU Server or Heterogeneous Client are compatible with the NVBU Encryption Plugin
  • Not all backups from the same NVBU Server or Heterogeneous Client require encryption
  • Primary backups do not require encryption while secondary backups for offsite protection do require encryption
  • Primary backups are targeted to NVSD devices for deduplication

Posted in BakBone North America | Tagged: , , , , , , | Comments Off

Encrypting Primary Backup vs. Secondary Copy Backups with NetVault: Backup

Posted by Dawn renee Campbell on January 13, 2010

Dawn renee Campbell

You have the NetVault: Backup Encryption Plugin installed and have selected the algorithm you want to use. Now you are wondering if you should encrypt your primary backups, your secondary copy backups, or maybe you are not even sure of the difference between a primary backup and a secondary backup.

In NetVault: Backup 8.5 (NVBU 8.5), a backup job can be split into two distinct phases: primary backup and secondary copy. The primary backup is the back up of the data stream to the targeted backup device, while the secondary copy is a duplication or data copy of the primary backup to a different backup device, which is typically for offsite protection.

Unencrypted Primary Backup vs. Encrypted Secondary Copy Backup

Prior to NVBU 8.5, your only option was to encrypt both the primary backups and the secondary copy backups, but starting with NVBU 8.5, you can encrypt your primary backups, just the secondary copy backups or both your primary and secondary copy backups. Understanding the difference between the primary backups and secondary backups will help you choose the best strategy for your environment.

Typically the primary backup is performed to local disk-based backup devices such as NetVault: SmartDisk (NVSD) devices, virtual tape library (VTL) or shared virtual tape library (SVTL) to enable faster restores while the secondary copies are targeted to remote disk-based backup devices or physical tape libraries whose tapes are stored offsite for disaster recovery purposes.

Security requirements will typically dictate whether both the primary backups and the secondary copy backups require encryption. For example, if security requirements only require backups that leave the corporate network (such as those stored on physical tapes stored in a remote location) require encryption, then only encrypting the secondary copy backups that target the physical tape library is required. However, if security requirements dictate that data must be encrypted while it transfers across the network and/or while it is stored on a disk-based backup device, even though the disk-based backup device is located within the corporate network, then encrypting both the primary backup and secondary copy backup is required.

Encrypted data does not deduplicate well; therefore, encrypting only the secondary copy backup is beneficial when targeting primary backups to NVSD devices that have the deduplication option enabled. This enables users to take advantage of both encryption and deduplication by deduplicating the primary backup and encrypting the secondary copy.

In my next blog, we will discuss the difference between encrypting all your backups and using job-level encryption.

Related links:

Selecting an Encryption Algorithm to use with NetVault: Backup

Posted in BakBone North America | Tagged: , , , , , , , , | Comments Off

Selecting an Encryption Algorithm to use with NetVault: Backup

Posted by Dawn renee Campbell on January 11, 2010

Dawn renee Campbell

When you are getting ready to deploy NetVault: Backup’s Encryption Plugin to encrypt your backups to meet regulatory or compliance requirements, you need to decide which of the available algorithms to use. To select the appropriate encryption algorithm you need to first understand the different algorithm categories and algorithms that are now available. NetVault: Backup’s available encryption algorithms are divided into two categories: Standard Algorithms and Advanced Algorithms. Each category is detailed below.

Standard Encryption Algorithms

NVBU Encryption Plugin’s Standard Algorithms include the CAST-128 algorithm.  CAST-128 is a 12- or 16-round Feistel network with a 64-bit block size and a key size between 40 to 128 bit but only in 8-bit increments. For more information on CAST-128, visit: http://en.wikipedia.org/wiki/CAST-128.

The CAST-128 algorithm was previously the only available encryption algorithm and is now available as part of the NVBU Encryption Plugin’s Standard Algorithm Option.  The CAST-128 algorithm is available for evaluations.

Advanced Encryption Algorithms

The NVBU Encryption Plugin’s Advanced Algorithms currently include the CAST-256 and AES-256 algorithms.

CAST-256 uses the same elements as CAST-128, but is adapted for a block size of 128 bits — twice the size of its 64-bit predecessor. Acceptable key sizes are 128, 160, 192, 224 or 256 bits. CAST-256 is composed of 48 rounds, sometimes described as 12 “quad-rounds,” arranged in a generalized Feistel network. For more information on CAST-256, visit: http://en.wikipedia.org/wiki/CAST-256

Advanced Encryption Standard (AES) is an encryption standard adopted by the U.S. government. The standard comprises three block ciphers, AES-128, AES-192 and AES-256. Each AES cipher has a 128-bit block size with key sizes of 128, 192 and 256 bits, respectively.  For more information on AES, visit: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

The CAST-256 and AES-256 algorithms are available as part of the NVBU Encryption Plugin’s Advanced Algorithm Option. Unlike the Standard Algorithm Option, the algorithms available as part of the Advanced Algorithm Option are not available for evaluation. The CAST-256 and AES-256 are available as separate NVBU .npk files and are only usable when a permanent license key for the NVBU Encryption Plugin Advanced Algorithm Option is installed.

When configuring the Encryption Plugin on each the NVBU Server or Heterogeneous Client, the encryption algorithm is specified. While each NVBU Server or heterogeneous client can utilize a different encryption algorithm, all backups from a particular NVBU Server or heterogeneous client will utilize the same algorithm.

The same encryption algorithm that was used during backup must be used during restores. It is possible to use a different algorithm from this point forward than has previously been used. However, when restoring backups that utilized the previous algorithm, the NVBU Server or heterogeneous client must be configured to specify the algorithm utilized by the backup in order for the restore to complete successfully.  For example, if previous backups utilized the CAST-128 algorithm while current backups are utilizing the AES-256 algorithm, the NVBU Encryption Plugin must be configured on the NVBU Server or heterogeneous client to utilize the CAST-128 algorithm when restoring a backup that was taken using the CAST-128 backup, otherwise the restore will fail.

In my next blog, we will explore the difference between encrypting primary backups vs. secondary backups.



Posted in BakBone North America | Tagged: , , , , , , , | Comments Off

« Previous Entries