White Paper: EMC Backup-as-a-Service: Applied Best Practices for Service Provider Billing - EMC Avamar and EMC Data Protection Advisor

White Paper

EMC Solutions Group

Abstract

This white paper discusses billing best practice recommendations for EMC® Avamar® based Backup-as-a-Service (BaaS) solutions. The white paper details the benefits and design considerations of different BaaS billing solutions, and presents a new multi-tiered billing approach, and includes a review of how to implement these billing solutions.

August 2012

EMC BACKUP-AS-A-SERVICE: APPLIED BEST PRACTICES FOR SERVICE PROVIDER BILLING EMC Avamar and EMC Data Protection Advisor

• Multi-tiered billing accurately reflects data processed • Automation streamlines reporting • Deduplication reduces redundant data

EMC Backup-as-a-Service: Applied Best Practices for Service Provider Billing EMC Avamar and EMC Data Protection Advisor

2

Copyright © 2012 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All trademarks used herein are the property of their respective owners.

Part Number: H10789

3 EMC Backup-as-a-Service: Applied Best Practices for Service Provider Billing EMC Avamar and EMC Data Protection Advisor

Table of contents

Executive summary ............................................................................................................................. 5 Overview .......................................................................................................................................... 5 Business case .................................................................................................................................. 5 Solution overview ............................................................................................................................ 5 Key results/ recommendations ........................................................................................................ 6

Introduction ....................................................................................................................................... 7 Purpose ........................................................................................................................................... 7 Scope .............................................................................................................................................. 7 Audience.......................................................................................................................................... 7 Terminology ..................................................................................................................................... 7

Backup-as-a-Service billing options .................................................................................................... 9 Baseline billing recommendations ................................................................................................... 9 Billing models .................................................................................................................................. 9

Single-tiered primary protected data report ................................................................................. 9 Back-end deduplicated capacity ................................................................................................ 10 Multi-tiered primary protected data report ................................................................................. 10

Premium uplifts/billing options ..................................................................................................... 13

Billing implementation ..................................................................................................................... 14 Billing implementation ................................................................................................................... 14

Avamar built-in reports .............................................................................................................. 14 Avamar Postgres and MCS databases ........................................................................................ 14 Data Protection Advisor ............................................................................................................. 14 Avamar Management Console Command Line Interface ............................................................. 14 Primary protected data reports .................................................................................................. 15 Back-end Capacity report .......................................................................................................... 16 DPN Summary report ................................................................................................................. 16 Multi-tiered primary protected data report ................................................................................. 18

Automating reporting ....................................................................................................................... 19 Automating reporting ..................................................................................................................... 19 Using Avamar reports ..................................................................................................................... 19 Using DPA ...................................................................................................................................... 19 Creating reports through ODBC ...................................................................................................... 19

Conclusion ....................................................................................................................................... 20 Summary ....................................................................................................................................... 20 Findings ......................................................................................................................................... 20


4

References ....................................................................................................................................... 21 White papers ................................................................................................................................. 21 Product documentation .................................................................................................................. 21


Executive summary

A service provider’s ability to successfully and competitively monetize an “as-a-service” offering in the marketplace is one of the most critical aspects to its operational success. The EMC® Avamar® backup solution is an enterprise backup solution that is popular in the Backup-as-a-Service (BaaS) market. One of the reasons for Avamar’s popularity is its deduplication efficiency.

Several options are:

• Service provider charge each customer for deduplicated space utilization.

• Customers are charged based on non-deduplicated space utilization.

• Customer are charged based on the space being processed (also known as protected) on their systems.

Service providers are using each of these options operationally. Which is the correct approach for your business model? While this white paper cannot answer that question, it outlines a variety of potential billing models that you can consider. The discussion of each model includes its benefits and drawbacks along with a discussion about how you can implement it.

Service providers that develop and deliver as-a-service solutions have a common requirement for the billing processes. There must be an effective way to track, report, and bill their customers based on the usage rates agreed to in the contracts. When it comes to “standard” storage components and Storage-as-a-Service (STaaS) offerings, this can be a straightforward process. Monthly bills are based on the amount of raw storage consumed by the user and are determined from the base storage subsystem.

When you view BaaS, a key driver in cost reductions for the service provider is to use solutions that employ data deduplication. This reduces the amount of data that needs to be retained and stored by the system. This enables service providers to dramatically reduce the amount of storage infrastructure needed to support the backup processes yet still provide the same levels of recovery capabilities, which yields significant cost savings. When you create a billing process, it is no longer a simple one-to-one ratio of data to storage, because of the deduplication technology used during the backup processes. Multiple backup agents may reference the same data objects across datasets, which makes it difficult to count the effective used storage.

Different types of data deduplicate at different rates, some higher and some lower. When you couple these characteristics with the retention policies, you can add a lot of variability into the storage usage profile.

Within the EMC data protection solutions, there are different billing methods that can be supported based on the service provider’s needs, including:

• Protected front-end primary data

• Back-end deduplicated data

• The types of data being stored and their deduplication efficiency

Overview

Business case

Solution overview


6

• Some combination of these methods

Different cost tiers can be created for different types of data based on:

• How well data deduplicates

• Retention periods

• The amount of data a client sends to the service provider during a backup session

The service provider must decide which model to use. It is important to understand the benefits and risks for each billing model so you can plan the cost structures appropriately to drive a profitable BaaS business.

This solution provides several multi-tiered billing models for service providers that can:

• Provide a more effective way to manage billing for customers

• Reduce backup costs through different types of billing options

• Simplify reporting by automating the process

Key results/ recommendations


Introduction

This white paper provides a detailed discussion of the different billing models and corresponding implementation options a service provider must consider when building a BaaS solution.

The scope of this white paper is to:

• Show how a service provider can build a billing model for structured and unstructured data

• Provide overviews of typical billing models and introduce additional multi-tiered models

• Use Avamar’s automation mechanisms to generate billing data

This white paper targets the business and technical architects of service providers s, who are responsible for developing and implementing the billing aspects of a BaaS solution. It is expected that the reader will have baseline knowledge of Avamar, EMC Data Protection Advisor (DPA), and the terms associated with disk-based deduplication techniques.

This white paper includes the following terminology.

Table 1. Terminology

Term Definition

Deduplication Data deduplication is a method of reducing storage needs by eliminating redundant data. Only one unique instance of the data is retained on storage media. Redundant data is replaced with a pointer to the unique data copy.

Garbage collection Improves write performance by eliminating the need to perform whole-block erasure before every write. Garbage collection works in the background and accumulates data blocks previously marked for deletion, performs a whole block erasure on each "garbage" block, and returns the reclaimed space for reuse by subsequent write operations.

Retention policies The rules that are used to determine how long data is maintained on the system and available for recovery.

Service provider A company in the IT industry that provides organizations with communications, storage, processing, or other services. Although the term service provider can refer to organizational subunits, it is generally used to refer to third-party or outsourced suppliers.

Structured data Data that is identifiable because it is organized in a structure. The most common form of structured data or structured data records (SDR) is a database where specific information is stored, based on a method of columns and rows.

Tenant A tenant is one of potentially many unrelated customers that are being serviced by the service provider’s shared infrastructure.

Purpose

Scope

Audience

Terminology


8

Term Definition

Unstructured data Data that has no identifiable structure. For example, images, videos, email, documents, and text are all considered unstructured data within a dataset.


Backup-as-a-Service billing options

It is important that you create the billing structure with a base cost derived for a particular base type of data with a specified base retention policy. This allows a low-cost charge for customers who do not need advanced data capabilities, but provides uplifts to cover the costs for customers who do require advanced data capabilities. As outlined in this chapter, these premium uplifts can be structured separately.

Often, service providers want to use a simple single-price or primary-GB costing model for their customers. What this means is that when a customer backs up data, regardless of the data type in the dataset, the customer is charged at a common rate based on a fixed retention policy. When creating the costing structure, the service provider must make assumptions about the amount of data that will be unstructured (such as data that deduplicates well) versus the amount of data that will be structured (databases or highly unique file types such as JPGs that do not deduplicate well).

If the data mix turns out to contain more structured data than what was assumed, the monthly price point will not deliver positive profits. Alternatively, if the data mix is more unstructured than planned, the data mix will return a better profit to the service provider. Therefore, a single price tier for all types of primary source data is risky.

Before delving into the various use cases for Avamar billing implementations, the following is a breakdown of what Avamar BaaS service providers are using:

• Ninety-five percent use Avamar’s Bytes Protected report (also known as Primary Protected report).

• Four-point-nine percent use a combination of Avamar’s Bytes Protected report with Avamar’s v_dpnsummary mod_sent value. This specifies how many bytes were transmitted from a backup client to the Avamar grid for a specific backup job.

• Zero-point-one percent use Avamar’s Back-End Capacity report (this feature was added in Avamar 5.1).

This white paper outlines the following billing models:

• Single-tier primary protected data report

• Back-end deduplicated capacity

• Multi-tiered primary protect data report (two- and three-tiered)

Single-tiered primary protected data report

This is the most popular billing mechanism implemented by service providers for Avamar-based BaaS solutions. Avamar incorporates several mechanisms to report on the amount of data being protected. In addition to being discussed in this white paper, this report is detailed in the Reporting section of the EMC Avamar 6.1 Administration Guide. There are several variations of the Bytes Protected report, which enable this report to run on a system-by-system basis with or without a date range. Each of these reports will be discussed in further detail in subsequent sections of this document.

Baseline billing recommendations

Billing models


10

You can report on primary protected data with Avamar alone or with Avamar and DPA. Avamar standard reports provide basic primary-capacity reports and you can use them as a starting point to develop custom SQL queries. This may be necessary because the basic reports do not include the Avamar domain to which a particular client belongs. Once the report is compiled, DPA can also provide this information, without the use of custom SQL queries, and can be used to upload the data to a billing system.

Back-end deduplicated capacity

The best way to create a billing process is to base it on the amount of data being stored on the back end by each customer. Because we are using deduplicated storage, there are going to be data objects shared across customers. This means that you cannot simply account for each used byte of data. More accurately, you have to count each used byte for each customer; otherwise, one customer is paying for shared data objects from which other customers would benefit.

Within the Avamar solution, we used the Back-end Capacity report to determine the amount of deduplicated storage used on the system by each customer. This takes into account data deduplication within all the customers’ agents being protected by the Avamar system. When you total the amount of data represented by the unique data objects, you can provide the output of consumed deduplicated bytes.

Because different types of data deduplicate at different rates, you will not know how much back-end storage is going to be used as a sole function of protected primary data. This is not an issue with the Back-end Capacity report, as each customer is charged based on back-end utilization. In addition, this report counts all the data kept on the system for retention purposes. By summing up all deduplicated storage along with the storage that is associated with retention, you can determine an individual customer’s exact Avamar storage use.

While customers are aware that deduplication percentages vary greatly based on file type, they cannot accurately detail what types of files they have. Because of this, it is difficult for a service provider to gauge, during the sales process, how much storage space a customer’s data will consume and be billed for until the end of the first month’s billing cycle.

The Back-end Capacity report is not a simple real-time SQL query of the Avamar database. The Back-end Capacity report involves a multi-step process that simulates a selective data replication for each set of customer servers. Running this report can take a significant amount of time and depends on the number of servers and retention policies. Because this report details deduplicated storage for a specified set of clients, it is best run on a per tenant basis.

Note You cannot use DPA information in the Back-end Capacity report.

Multi-tiered primary protected data report

Because of the risks of having a single price tier for all data types, a better alternative is to create a tiered pricing structure for different types of data. In general, a three-tier model makes the most logical sense, but you can also use a two-tier model.


The multi-tiered models have the following attributes:

• Two-tiered

Structured data

Unstructured data

• Three-tiered

Structured data

Unstructured data without exclusion

Unstructured data with exclusion

The fundamental goal of these multi-tiered reports is to provide service providers with the ability to separate unstructured and structured data.

For these reports, the unstructured and structured data will be determined by the type of Avamar agent used to perform the backup. All OS agents back up unstructured data, while agents for Microsoft SQL Server, Microsoft Exchange, Oracle, DB2, Sybase, and so on, back up structured data.

A service provider must carefully consider the average change rates for structured and unstructured data. The typical change rate for an OS agent client is three-tenths of one percent per day, while the average change rate for a database is typically six percent. This is a large difference, which has a significant impact on:

• Backup windows

• The amount of data required for retention windows

• The amount of network traffic a client consumes

When you compare the single-tier primary protected report against the two- and three-tiered reports, the previous change-rate discussion becomes critical and justifies why a multi-tiered reporting mechanism may be the best solution.

The difference between the two- and three-tiered reports provides a way to implement exclusion lists into the backups. You can use the exclusion lists to separate data types that:

• Incorporate compression, encryption, or other techniques

• Eliminate white space within the file

• Do not deduplicate or compress well

By providing a way to bill separately, based on these datafile types, you can better manage the cost per GB.

Common file types for unstructured data includes 7Z, JPG, AVI, MOV, TGZ, and so on. Unstructured data that deduplicates well and typically would not be in the exclusion list, includes file types such as DOCX, PDF, DOC, PPT, PPTX, and so on.


12

By using multi-tiered data reporting, you can specify different billing rates for the different data types based on deduplication efficacy. By charging directly based on usage for the different data types, the costs charged will cover the appropriate costing structures. Reporting for this type of billing structure requires custom SQL scripting through Avamar’s Open Database Connectivity (ODBC) interface. This enables you to group the data based on the available fields maintained in the Avamar database.

Combining this data provides the information required by the service provider’s billing infrastructure to generate the appropriate invoices and display usage reports for the different tenants.


When delivering backup services, some customers require expanded capabilities to support their business needs. The costs for premium services should be billed separately or as a different type of Service Level Agreement (SLA) only to those customers requiring the services. Table 2 describes the available premium services.

Table 2. Premium services

Service Description

Data restores Many service providers provide a specific number of data restores during the monthly billing period. Restores above that level incur a cost or restoration fee. This maintains control over customers who misuse the backup system to provide disaster recovery services by performing daily server restores to an alternate location.

Data output to tape Using extended retention, through a media access node, data can be written to tape on a defined, periodic basis (generally only on a monthly basis), which provides longer-term retentions on lower-cost media. The cost to write to tape is based on price/GB written, and can be tiered based on the data amounts that are written.

Longer retention policies The service provider can increase the price/GB or percentage uplift of the base price/GB charge to cover a longer retention policy on a disk. Typical Avamar BaaS deployments use a 30-day retention period. You must consider the implications of longer retention periods in storage space utilization. EMC recommends you assume a three-tenths of one percent daily change rate for file server type workloads and a six percent daily change rate for application-specific backups.

Replication If customers want their data replicated offsite, there is an additional price/GB to cover this service. The service provider can offer this type of service in a variety of ways. Replicating a customer’s Avamar system to a service provider’s Avamar system in a different geographic area has recently been generating interest. Another alternative is to provide customers with the ability to replicate their data from one of the service provider’s data centers to another data center located in a different geographic area.

Premium uplifts/billing options


14

Billing implementation

Depending on your environment and operational requirements, you have several options for generating the Avamar billing reports discussed in the previous chapter.

You can use Avamar to generate billing-related information based on your requirements.

Avamar built-in reports

Avamar provides many built-in reports that you can generate and modify directly from the Avamar Management Console. You can customize these reports to create and gain access to customer-specific data. It is also possible to use DPA to provide additional reporting capabilities for Avamar. Despite the capabilities of Avamar and DPA, neither provides the ability to generate new reports that combine information from existing Avamar reports.

Avamar Postgres and MCS databases

Avamar uses a Postgres database to track of all its activities. The Management Console Server (MCS) datafile name is mcdb and is located on the utility node in the /usr/local/Avamar/var/mc/server_data/postgres folder. The MCS database provides read-only access through defined public views and tables. You can access the information in this database using custom SQL calls through ODBC. You can create highly customized reports when you access mcdb information.

Avamar provides several MCS database views. These public views are documented in Appendix C of the EMC Avamar 6.1 Administration Guide. You can access some views through the Avamar management GUI. For example, the Backup Statistics screen provides statistics by using data from the v_activities_2 database view.

The v_reports view lists all the MCS database views, along with the SQL calls used to generate them. You can find additional information about this view in Appendix C of the EMC Avamar 6.1 Administration Guide.

We used this view into the mcdb to generate the customer queries needed to create several reports discussed in this white paper.

Data Protection Advisor

DPA provides a mechanism to automate the collection, analysis, and reporting of Avamar grid usage by tenant, and can be used to customize many of the reports that Avamar provides, without creating custom SQL queries.

Avamar Management Console Command Line Interface

The Avamar Management Console Command Line Interface (MCCLI) provides an essential capability to the successful integration of Avamar into a service provider’s portal. During the development of our reference portal and BaaS implementation, we used the MCCLI extensively.

Note MCCLI is not built as a reporting tool and has no mechanism to create, edit, or run Avamar reports.

Billing implementation


Previous sections of this document have discussed the various types of reports that are either used by service providers or that EMC recommends while designing a BaaS solution. Each of those reports, in addition to one hybrid, is described in this section.

Primary protected data reports

Billing the customer based on the amount of data protected by the BaaS solution is the most popular billing mechanism in production. For more information about this billing method see Chapter 8 of the EMC Avamar 6.1 Administration Guide. There are several variations of the Bytes Protected reports, which enable these reports to run on a system-by-system basis with or without a date range.

These reports provide the maximum number of bytes protected for each customer. The Activities – Bytes Protected Client report provides the maximum number of bytes protected by the Avamar system in the last two weeks for each client.

Alternatively, the Activities – Bytes Protected Client – 2 report specifies the same information for activity that occurred during a specified date range. You can run either report on a daily basis or once per month. Service providers who run the report on a daily basis typically do so to:

• Provide daily updates to the self-service portal

• Use the data to obtain the maximum number of bytes protected during a 30-day period, for which they bill the customer

Recommendations EMC recommends that you run the Activities – Bytes protected Client – 2 report for the preceding month on a daily basis, and update the self-service portal based on the results of that report.

EMC also recommends, though not strictly a billing issue, that you display the output of the Activities – No Activities and Activities – No Checkins information on the self-service portal. This ensures that the customer is aware of systems that have not been backed up recently.

These two reports do not include any storage used on the Avamar grid for retention purposes. EMC recommends that you build a rate that includes the length of retention for the Avamar infrastructure into the price per GB protected.

If you are going to bill a tenant based on the quantity of primary protected storage, EMC recommends that you bill the customer using one of the following models:

• Run the Activities – Bytes Protected 2 report for the preceding month to obtain the largest amount of data protected on each system.

• Bill based on an average of the Activities – Bytes Protected report run on a daily basis for each system. If run at the root domain, the output of the Bytes protected Client and the Bytes Protected Client 2 reports list each server that was backed up and the corresponding amount of storage protected.


16

Creating a per-tenant (Avamar domain) report requires additional work because the report lists the servers, not the Avamar domains, to which they belong. To collect this data on a per-tenant basis:

• Use a report template (for example, Clients Report template) that includes the client domain in the report.

• Use the Activities Report template that states that the client’s domain can be included.

• Customize the report to include each tenant instead of the root domain.

• From the report, extract the client name and, using Postgres/ODBC calls, map the name to its domain. You can use a view such as v_group_members, which includes client_name and full_client_name.

Back-end Capacity report

The Back-end Capacity report provides information on the deduplicated storage usage by systems or tenants. The Back-end Capacity report performs a simulated replication operation of an empty Avamar grid for the specified systems or tenants. From this report, you can determine the exact Avamar grid usage and include any deduplication benefits of the specified targets. This information includes all retention data and any usage of globally deduplicated items.

Some service providers script the Back-end Capacity report to run once a month for all their tenants. By scripting the Back-end Capacity report to run each tenant sequentially, the variability in how long each run takes is irrelevant. While we feel this is appropriate for small- and medium-sized Avamar BaaS deployments, this solution is not yet highly scalable and should not be deployed in large BaaS environments with hundreds of tenants.

Notes

• With Avamar 6.0 and 6.1, you cannot use this report to determine the back-end capacity used by a system being backed up to an EMC Data Domain® system.

• Only one instance of this report can be run at a time, requiring individual runs for each domain or client grouping. Only one instance of the Back-end Capacity report can be run simultaneously, because the system has to parse through all its metadata to determine how much of the back-end capacity is being used by the targeted systems.

DPN Summary report

You can use the DPN Summary report for billing through Avamar’s MCS report, Activities – DPN Summary, or by directly accessing the v_dpnsummary MCS database view through ODBC calls. You can use the information available from the DPN Summary report by itself or combined with other report data, such as the Primary Protected report. Table 3 describes the data available in the DPN Summary report.


Table 3. DPN summary report

Variable name Description

Host The client hostname

Mod_sent The number of bytes of files that were modified since the last backup and sent to the Avamar grid for protection

Modnotsent The number of bytes of files that were modified since the last backup but were not sent to the Avamar grid due to global deduplication

Totalbytes Number of bytes processed

Note You can use the data in this report to generate the Primary Protected dataset

size on a per-host basis.

By running the DPN Summary report for a specified monthly billing period and summarizing mod_sent, you can calculate the amount of data a client has sent to the Avamar grid. However, this number does not include deduplication. To collect deduplication information, the modnotsent variable needs to be used so that it is possible to distinguish between what Avamar is protecting and what is captured in the primary protected reports.

The report does not consider data that has been expired on the Avamar grid because of the report’s retention policies. In addition, the report does not consider the amount of Avamar space being used for data retention.

Example As an example of the challenges inherent with using the mod_sent method for billing, consider the use case of a BaaS environment in which a customer backs up a 1 TB database. Assuming reasonable deduplication efficiency, the Avamar client sends 300 GB to the Avamar grid for the initial seeding of this file on day one. You can also assume that data retention is set to 30 days and that there is a three percent day-to-day change rate on the file. Once the initial seeding of 300 GB is complete, only 3 GB is sent on a daily basis. You have a total mod_sent of 387 GB = 300 GB + (29 * 3 GB) for the first month. That also equals the usage of the grid from a retention period, which is reasonable.

The concern for the service provider occurs in month two, where only the change-rate data is sent. The mod_sent for month two is 90 GB = (30 * 3 GB). The customer is satisfied, while the service provider is not, as the total usage of the backed Avamar grid, at the end of month two is 387 GB = 300 GB + (29 * 3 GB).

Note There is more post processing required of DPN summary reports as they report on a per-host basis. The tenant needs to summarize this before uploading to the billing system.

Custom reports You may want to generate custom reports based on a combination of primary protected and mod_sent data. One typical use case that tracks mod_sent is to use that information to validate what the daily change rate is for a particular customer. You can do this by tracking mod_sent in combination with totalbytes and modnotsent. Taken together, you can use totalbytes and modnotsent to determine


18

the daily change rate for systems and tenants. By having this change rate data, you can fine tune the billing assumptions around the quantity of storage used for data retention.

Multi-tiered primary protected data report

EMC recommends a custom multi-tiered billing model as an alternative to a higher-risk single-price approach to billing. The recommended tiers are:

• Unstructured data with exclusions of specific, low deduplicatable data types, whose typical deduplication efficiencies are relatively low

• Unstructured data with no exclusions types, whose typical deduplication efficiencies are typically very high

• Structured datasets

There are no existing reports that collect this information, so you must create a custom report using ODBC access to the Avamar database (MCDB), then using the database views. You must collate and collect information from individual backup jobs, including:

• The type of agent plug-ins used for the backups (OS agents versus application agents)

• The size of the file

• Dataset names (identify which datasets have exclusions versus no exclusions)

• Customer domain as set up within Avamar

By collecting this information for each back-up job, you can determine:

• The amount of data, by data type, that was sent to the Avamar grid

• The type of agent plug-in used

• The customer domain

You can then group the data, according to typical deduplication efficiency and plug-in used, to be billed back to the customer. Custom SQL scripting through Avamar’s ODBC interface is required to collate and organize the information. Once collected, the information is forwarded to your billing infrastructure to generate the appropriate invoices and display usage reports for the different tenants.


Automating reporting

In order for you to cost-effectively scale out an as-a-service offering, automation is a key requirement. The recommendations are not specific to any of the reports previously listed; they are a general overview of what automation options are available.

You can create Avamar reports using the Avamar Admin > Tools > Manage Reports dialog box, and specify the attributes desired. You can create this report at the root domain to include all Avamar domains or a separate instance of this report for each Avamar domain. Your environment and the amount of post processing you wish to perform will dictate which method to use.

Creating a mechanism within Avamar to automate the execution of a report requires that you use a custom event profile. For more information, refer to the sections “Creating a customer event profile” and “Events, Notifications, and Profiles” in the Avamar Admin Guide.

As part of the event profile creation process, you select a triggering event code. EMC recommends that you use an event code such as “garbage collection initiated” or “garbage collection completed” as the trigger.

The automated mechanism requires that the reports be emailed. EMC recommends that you email the reports to a service-provider-controlled mailbox that saves the attachments to a local file, then you can process the reports as required.

You can create the same reports using DPA. DPA provides additional reporting capabilities without customer scripts. It also provides more capabilities for automating report generation than Avamar.

The most powerful and flexible automation option is to access the data from Avamar’s database directly. You create the report through ODBC/SQL calls against the Avamar Postgres database. Appendix C of the EMC Avamar 6.1 Administration Guide provides a list of precreated views into the Avamar database. Avamar uses many of these views for the prepackaged Avamar reports.

For example, the v_dpnsummary MCS database view includes the underlying data used to create the Activities – Bytes Protected Client reports. The critical data is host, activity, and totalbytes. Totalbytes provides the number of bytes processed on the client.

Automating reporting

Using Avamar reports

Using DPA

Creating reports through ODBC


20

Conclusion

There must be an effective way to track, report, and bill service providers’ customers based on the usage rates agreed to in their contracts. Different types of data deduplicate at different rates, some higher and some lower. When you couple these characteristics with the retention policies, you can add a lot of variability into the storage usage profile. The financial model and reports used by the service provider must accurately capture and bill customers based on their usage.

This white paper provided an overview of several multi-tiered billing models for use with Avamar-based BaaS solutions. These multi-tiered reports provide service providers with a flexible set of billing alternatives that can be customizes for their specific environment.

This solution provides several multi-tiered billing models that can:

• Streamline data backup and restoration by reducing wasted storage

• Provide a more effective way to manage billing for customers

• Simplify reporting by automating the process

Summary

Findings


References

For more information, see the following white papers:

• EMC Backup-as-a-Service: EMC Avamar, EMC Data Protection Advisor and EMC Homebase

• EMC Avamar Technical Deployment Considerations for Service Providers

• EMC Avamar Business Deployment Considerations for Service Providers

• Creating “Backup as a Service” (BaaS) Solutions Leveraging EMC Avamar

For more information, see the following product documents:

• EMC Avamar 6.1 Administration Guide

White papers

Product documentation

Technology

White Paper: EMC Backup-as-a-Service: Applied Best Practices for Service Provider Billing - EMC Avamar and EMC Data Protection Advisor