You can create a one-time archive on demand at any time.
You can also define requirements for continual scheduled archive. This action creates an archive of recovery points for the machines you select, in the location you designate. Additional recovery points for those machines are then continually appended to the archive on a schedule you define (on a daily, weekly, or monthly basis).
When you create an archive, you specify where you want to save it. You can store an archive in a file system (locally or on a network), or in a storage account in the cloud.
|
|
NOTE: Before archiving to a cloud account, you must first add the credentials to the storage account on your Rapid Recovery Core. For more information about defining a cloud account in the Core, see Adding a cloud account. |
If storing your archive in an Amazon cloud storage account, you must define the storage class when creating the account. To archive directly to Amazon Glacier, you can specify Glacier storage when defining the location in the Archive Wizard. For more information about Amazon storage classes, see Amazon storage options and archiving.
- One-time archives are read-only. When creating a one-time archive, the destination location you specify must be empty.
- When using scheduled archive, the Core appends additional recovery points to the existing archive.
- If the storage medium you selected runs out of space, Rapid Recovery pauses the archive job, letting you specify another location. Your archive is then split into segments, which can reside in different locations, as space allows.
When archiving data in an Amazon Simple Storage Service (S3) account, you can choose from various storage classes. Each has different associated costs, benefits, and access restrictions. Prices may differ by region. Rapid Recovery release 6.2 extends support of Amazon storage accounts to all storage classes. This is useful when planning to store Rapid Recovery archives in the Amazon cloud.
Understanding storage classes available and the difference in lead times to access those classes is critical to control storage costs effectively while being able to access your archives within acceptable time frames.
|
|
NOTE: Quest provides this information as a courtesy to its Rapid Recovery customers to help raise awareness of storage pricing factors. These concepts can help you plan and budget accordingly. You are responsible for all storage costs on Amazon or for any other cloud service provider. Since Amazon can change prerequisites, requirements, costs, storage tier definitions, and so on, use the Amazon website as the primary and authoritative source for that information. |
In general, Amazon currently offers the following storage classes.
Standard. This storage class is for data you plan to access frequently or access quickly. This class is the default storage option from all Rapid Recovery wizards, windows, and dialog boxes. There are no separate fee to retrieve information in the standard storage class.
Standard Infrequent Access (IA). This storage class is more economical than standard, intended for data that you do not intend to access frequently. There is a retrieval fee associated with accessing data in the storage class. However, availability is immediate. Amazon charges fees for objects deleted from Infrequent Access storage before 30 days.
Glacier. This storage class is for long-term storage of data that does not require real-time access. It is most economical for long-term storage of data that is rarely retrieved. There is a retrieval fee associated with accessing data in this storage class. Amazon charges fees for objects deleted from Glacier before 90 days. Retrieval of data stored in Glacier is not immediate. Standard retrieval times require 3 to 5 hours; bulk retrieval for large amounts of data can take up to 12 hours. Expedited retrievals can take up to 5 minutes. Fees apply to each retrieval option.
|
|
NOTE: Unlike the other Amazon storage classes, Rapid Recovery does not support the creation of a cloud account that is specific to Glacier. To archive data in Glacier, choose an Amazon cloud account, and select the Use Glacier storage option in the Location page of the Archive Wizard. |
Reduced Redundancy Storage (RRS). This category is a lower-cost storage class is designed for noncritical reproducible data with less redundancy than the standard storage class. There is a minimal retrieval fee associated with accessing data in this storage class. A fractional percentage (Amazon cites as much as .01%) of objects stored in this class are expected to be unrecoverable.
For the most recent information, always review materials on Amazon's website.
In general, the following guidelines apply:
- If you expect to restore data on any regular basis from a Rapid Recovery archive, Standard is likely to be the best option.
- From a cost perspective, if you plan to restore data occasionally, consider Standard Infrequent Access.
- Glacier is intended for cold storage of archived recovery points from which you rarely expect to restore. A good example of when to use Glacier storage is when saving data for regulatory compliance. Glacier is available as an archive option from the Archive Wizard.
- For storage of noncritical, reproducible data, consider RRS.
Before creating your archive, you must decide on the proper approach for recovery point chains. Use the following information to determine which option you select in the Options page of the Archive Wizard.
- Build complete recovery point chains, including referenced base images outside the date range. If you select the option to build complete recovery point chains, then you can perform the full range of restore actions for any recovery point in the archive. This range includes file-level restore, volume-level restore, and bare metal restore. When you select this option, full recovery point chains are saved with your archive. You can restore data even if the base image corresponding to the selected recovery point is earlier than the date range of your archive. However, the file size of this archive is larger, to ensure that you have access to data in the full recovery point chain.
- Include only the recovery points in the date range. This saves space, but you are responsible for archiving any needed base images. If you include only the recovery points in the specified date range in your archive, the file size of the archive is smaller. For data in which the base image is included in the date range you specified, you have access to the full range of restore options. However, if you want to recover data captured in a base image from a date earlier than the date range you specified, you may be restricted to file-level recovery only. Data outside the range of the archive is orphaned.
For more information on recovery point chains, see the topic Recovery point chains and orphans.
When you need to access the data in an archived recovery point, you have two options.
- For archives created with Rapid Recovery Core version 6.0.1 and later, you can attach the archive. The attached archive is displayed in the left navigation menu of the Core Console. You can browse the recovery points in the archive, and take the same actions on that data as with any other recovery points currently in your repository, without importing that data into your repository.
- You can import an archive, restoring those recovery points to your repository. You can then take the same actions on that data as with any other recovery points currently in your Core. Rapid Recovery Core is backward compatible, supporting import of archives from all AppAssure and Rapid Recovery versions.
|
|
Caution: Since the Core recognizes the original dates of recovery points in an archive, recovery points imported from an archive may be rolled up or deleted during the next nightly job period, if their age exceeds the retention period. If you want to retain older recovery points imported from an archive, you can disable rollup or extend the retention period for the relevant protected machines. |
When you need to access the data in an archived recovery point, you can attach (for Rapid Recovery 6.x and later) or import the archive, restoring those recovery points to your repository.
