This article discusses best practices for planning and sizing Rapid Recovery repositories.
A repository is used to store the snapshots that are captured from your protected workstations and servers. The repository can reside on different storage technologies such as Storage Area Network (SAN), Direct Attached Storage (DAS), or Network Attached Storage (NAS).
When you create a repository, the Core pre-allocates the storage space required for the data and metadata in the specified location. You can create up to 255 independent repositories on a single core that span across different storage technologies; in addition, you can further increase the size of a repository by adding new file extents or specifications. An extended repository can contain up to 4096 extents that span across different storage technologies.
Key repository concepts and considerations include:
NOTE: Rapid Recovery repositories should be stored on primary storage devices. Archival storage devices such as Data Domain are not supported due to performance limitations. Similarly, repositories should not be stored on NAS filers that tier to the cloud as these devices tend to have performance limitations when used as primary storage. If the repository is planned to reside within an SMB/CIFS share the repo should not exceed 2 TB due to MS sizing guidelines.
The repository uses deduplication volume manager (DVM) to implement a volume manager that provides support for multiple volumes, each of which could reside on different storage technologies. The scalable object store behaves as a records-based file system, where the unit of storage allocation is a fixed-sized data block called a record. This architecture lets you configure block-sized support for compression and deduplication. Rollup operations are reduced to metadata operations from disk intensive operations because the rollup no longer moves data but only moves the records.
The DVM can combine a set of object stores into a volume and they can be expanded by creating additional file systems. The object store files are pre-allocated and can be added on demand as storage requirements change. It is possible to create up to 255 independent repositories on a single AppAssure 5 Core and to further increase the size of a repository by adding new file extents. An extended repository may contain up to 4,096 extents that span across different storage technologies. The maximum size of a repository is 32 Exabytes. Multiple repositories can exist on a single core.
For more information on this topic, please see:
All non-transactional servers can be backed up every 12 or 24 hours. There will be no additional benefit by using a more frequent protection interval. For transactional servers the best practice is to back up every two hours.
Using the following guidelines, small businesses will generate a 2% change rate. Mid-sized businesses will see a change rate of around 6%. The same applications hosted in a Managed Service Provider will experience a change rate of up to 10%.
By using Rapid Recovery, you can define a granular retention policy for the periodic snapshots. As the snapshots age, the Rapid Recovery rollup process automatically rolls them to the next retention tier. The retention tiers are hourly, daily, weekly and monthly. You can choose the retention interval that will perfectly fit all your needs.
The process of protecting a server starts with an initial base image of the targeted volumes followed by periodic incremental snapshot backups. These incremental snapshots capture only the disk blocks that have changed since the previous snapshot backup. The more that the data changes, the larger the size of the snapshot will be, and vice versa.
To calculate the amount of snapshots that will be stored during all protection period you can use the following formula:
P=N+H+D+W+M
Where:
M = Number of monthly snapshots. The default is 1.
W = Number of weekly snapshots. The default is 1.
D = Number of daily snapshots. The default is 3.
H = Number of hourly snapshots. The default is 2.
N = Number of base image snapshots. The number is always 1.
To calculate the total amount of data, use the following formula:
T = Sb + Si
Where:
T – total size of all data located in Volume Images
Sb – sum of all base image sizes
Si – sum of all incremental sizes
The size of the base image is the final deduplicated size of the initial base image. You can estimate the size of the base image by using the following formula:
Where:
Ti = Total used space of data across all the disk volumes in bytes for a specific element.
C = Deduplication and Compression Ratio. This is expressed as a percentage between 1 and 100. For example, if you set C to 65, representing 65 percent compression, the compressed data would be 35 percent of its original size.
Nb = Number of base image snapshots.
Size of all the incremental snapshots is the final deduplicated size of all taken snapshots. You can estimate the size of the incremental by using the following formula:
Where:
Sb= size of the base image
Nb = Number of base image snapshots
R = Total estimated Change Rate. This is expressed as a percentage between 1 and 100. For example, if you set R to equal 10, then this setting indicates that 10% of the data changed within a recovery point.
Ni = Number of incremental snapshots.
Depending upon your environment and the amount of data to back up, Quest recommends that you plan the size of the repositories required to store base images and incremental snapshots. As a baseline, it is recommended that you allocate 1.0-1.5x of the total of all backed up data to maintain the default retentions. Rapid Recovery also allows you to increase the size of your repositories by adding new repository storage locations so that you can scale your repositories.
You will experience the highest de-duplication gains by having one repository. You can also mitigate failures by creating separate repositories. For example, you could create separate repositories for Exchange and SQL servers; however, if the storage originates from the same location, you are probably gaining little by doing so.
For more information about creating and managing repositories, see the User Guide, which is on the Technical Documentation page.
© 2025 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center