Description
Backup Exec 20.5 introduces the capability to choose the Storage Tier (Storage Class) as Glacier or Deep Archive apart from the existing storage tiers when configuring a Cloud Storage of type Amazon S3. Once the device is created, all backup jobs targeted to that device will store data in the corresponding storage tier.
Listed below are some notes about when using Glacier and Glacier Deep Archive storage as backup destination in Backup Exec.
1. Configuration
While configuring a cloud storage, Glacier or Deep Archive can be selected in the Storage tier field.
2. Backup set retention
A backup job has retention settings that can be defined by user that determine when a backup set should get expired and deleted.
Backup Exec will delete the backup sets hosted in Glacier or Glacier Deep Archive storage as per these retention settings. However, there is a minimum period for which charges are incurred by Amazon when the data is stored in glacier/deep archive. This period is decided by Amazon and currently its default value is 90 days (3 months).
Example - If the backup set retention is configured as 1 month got a backup, then the backup sets will get deleted after a month.
However, if the minimum period setting in Amazon is 90 days (3 months), then even when Backup Exec has deleted the backup set after 1 month, customer will still incur charges for a period of 90 days.
3. Inventory and Catalog operation
Inventory operation accesses first and last chunk of each backup image along with other metadata images (objects with prefix BEOst_S*). If this data is stored in Glacier or Deep Archive tier, then the inventory operation will run for a long time, sometimes for days. To avoid this, first and last chunk of each backup image and metadata images are stored in the Standard tier of Amazon S3 storage, which allows inventory job to run seamlessly.
Catalog operation reads all the contents of a backup image/media. This can prove to be a very costly operation (in terms of time as well as money) for media residing in Glacier or Deep Archive storage.
Hence the Inventory and Catalog now and Catalog operations are disabled at the storage device level.
The following message is shown in the Backup Exec UI, if user tries to run an Inventory and Catalog operation.
Note: To avoid the steps below, it is recommended to backup the BE Install Path\Data and Catalogs folder from time to time or daily. If a situation arises where the storage has to be imported from scratch, then the backed up Data and Catalogs folder can be placed back in order for the backup set information to show without the need to rerun an inventory and catalog job, which can be time consuming.
Inventory the storage if it is imported into a new Backup Exec Installation to read the header of the media. The Job history has essential information which can help to understand the number of media present in each set. Refer How to find the Family Sequence Number of a particular set section from Backup Exec Catalogs Technote. Find out the last media of each set and execute the command in step 2 by replacing the OST media label. Larger sets can be identified by the method mentioned in Backup Exec Catalogs Technote and cataloged to ensure timely cataloging of the sets.
Workaround:
The Catalog operation is supported for individual media. To catalog individual media, perform the following steps:
1.
Set the registry value of the Backup Exec server to show hidden cloud media.
HKLM\SOFTWARE\Veritas\Backup Exec For Windows\Backup Exec\User Interface
DWORD value: ShowHiddenMedia set it to 1.
2.
Catalog individual media by running the following command from BEMCLI:
4. Restore operation
When running a restore from the backup set hosted on Glacier or Deep Archive, Backup Exec will need to retrieve data from these devices. This can be a time-consuming operation (it takes up to 3 hours of time from the glacier storage and up to 12 hours of time from deep archive).
A relevant note is shown in the Backup Exec UI, to estimate the time it may take for a restore job to be completed.
Backup Exec uses a standard retrieval option. The retrieved data is available for 3 days to run the same restore job quickly. Until the retrieval is completed, the restore job indicates Loading Media status.
Refer Amazon S3 documents restoring-objects for more information.
5. Storage bucket view - S3 console
When the job log reports media OST00000008, the data is stored under BEOST_00000008 folder. The screenshot below indicates that separated objects are stored in Glacier Deep Archive storage class.
Note: The first object (named “0”) and the last object (the maximum number, 3407 in this case) are stored with standard storage class. IMAGE_PROPERTIES and BLOCK_MAP_FILE are also stored with standard storage class. Do not change storage class for these objects.
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.