Proper sizing for local backup repositories is a critical step in building a complete backup and disaster recovery as a service solution (DRaaS). Below, we will list the most accurate way of determining what your data change rate is and how large the repository should be. While no method can anticipate every future event in your data, we have found that following these three steps leads to the best possible estimate for local backup repository sizing.

The main factors that impact your storage requirement include the size of you VMs, the frequency of your backups, your retention policy. You will need to estimate your compression and deduplication ratios which usually result in a 40% to 60% reduction. And you will need to know your approximate daily data change rate, but Veeam offers a great tool to address this to address this.

Using this information, you can plan for the required disk space. But, you should always allow a safe margin for future growth, and for moving VMs or restoring VMs, etc.

Step One – Run Veeam ONE

 

Veeam ONE is a free reporting and planning tool included in the Veeam Availability Suite that monitors both VMware and Hyper-V virtual environments. Veeam ONE will report the daily data change rate by server in your environment. Ideally you should run Veeam ONE over a period covering normal activity levels.

This example shows the daily data change rates for a group of servers. The total daily change rate is 214GB.

Sizing for Local Backup Repositories

Though not shown in this report the total size of these servers as reported by vSphere is 2.5TB, but as an example, this screenshot shows sizing data for a different group of servers in vSphere:

Sizing for Local Backup Repositories

Sizing data for a group of servers in vSphere.

Step Two – Apply a Retention Policy

 

We have written at length in this blog about retention policies. Organizations may vary in specific retention needs, but let’s work from the following fairly typical or standard retention policy: Local Restore Points: every 6 hours for 2 days, plus 10 dailies, and one monthly. Remote Restore Points: 10 dailies, one monthly, unlimited monthly archive.

Visit The Restore Point Simulator at http://rps.dewin.me/

Given the data size, change rate and estimated compression rates, this very clever tool can complete the calculation we need. We’ll give it these inputs:

Style = Incremental
Used Size GB = 2500GB
Retention Points = 21
Change Rate = 8%
Data left after reduction = 60%
Interval = Daily
Time Growth Simulation = 10% per year

The simulator reports below that we need 5.475TB:

restore point simulator

Step Three – Reasonableness Test

 

We always apply a reasonableness test. Depending on what we know about the data, we’ll estimate storage requirement of roughly four times the storage reported in vSphere. In this case that 10TB. For this example, we’d recommend a repository with 8 to 10 TB of storage. This would allow for room to grow and would accommodate any unexpected data growth or high change rates.

Here are some other articles we’ve written about retention policies and related ideas:

Developing A Data Retention Policy What Data Do You Have to Backup

Data Backup Developing an Effective Data Retention Policy

Checklist for Developing an Effective Data Retention Policy

In a future post, we’ll discuss specs for the repository hardware as well as specs for the server performing the backups.

Summarizing the Steps

  • Get your data change rate from Veeam ONE
  • Use the Restore Point Simulator to estimate storage required
  • Apply a reasonableness test as a final check

Let us know if you have questions. And we welcome your thoughts and real world experiences.