After you create a cloud tiering schedule, you can edit the schedule by completing the following steps.
To edit a cloud tiering schedule
- In the navigation menu, expand Cloud Storage, and then click Cloud Tier.
The Cloud Tier page displays.
- On the Cloud Tier page, to reveal the scheduling options, click Schedule.
- For each time you want to change, do either of the following steps:
- To delete a time, click the trash can symbol.
- To change a time, click the box, select a new time, and then click Set.
- When finished, click Save.
- To hide the schedule options, click Schedule.
Before deleting a cloud tier, review the details below:
- Only the files for whom the on-premises retention age applies and the file data which resides in the cloud will be removed locally.
- Data in the cloud bucket has to be deleted manually.
- Cloud policy settings on the source containers will be removed and the source container made available for cloud replication to a new cloud or archive tier.
Deleting a cloud tier from the GUI
To delete a cloud tier, complete the following steps.
- In the navigation menu, click Cloud Storage to expand the menu, then click Cloud Tier.
- Click Delete.
- When prompted to confirm, click Delete.
- In the Passphrase field, enter the passphrase used for Cloud Tier encryption. This provides validation that the person deleting the cloud tier has the appropriate authorization.
- Review the containers linked to the cloud tier and confirm that data in these containers can be deleted. Any containers with managed replication configured must be deleted manually before the cloud tier can be deleted.
- Click Delete.
Deleting a cloud tier from the CLI
- Access the QoreStor CLI. Refer to Accessing the CLI commands for more information.
- Delete your cloud tier using the command below. Refer to the QoreStor Command Line Reference Guide for more information.
cloud_tier --delete
- At the prompt, enter y for yes and press [Enter].
Cloud and archive and tiers can be configured via the UI or via the cloud_tier command in the QoreStor CLI. Before configuring an archive tier, ensure the following requirements are met:
- Your cloud storage must be configured prior to configuring a cloud or archive tier.
- Archive tier is not supported when QoreStor is installed in Cloud Optimized mode or Object Direct Small mode.
- Permissions for your cloud storage must be correctly configured. Refer to Configuring required permissions to restore from Archive Tier for more information.
- Only RDA, VTL, and Object containers can be configured to tier data to Archive Tier.
|
|
NOTE: QoreStor's archive tier functionality relies on Amazon S3 Glacier and/or Amazon S3 Glacier Deep Archive storage. Before configuring an archive tier, your cloud archive storage must be properly configured. Please refer to the Amazon S3 documents below for more information:
|
For QoreStor to perform batch operations for restoring objects to Amazon S3 storage from Amazon S3 Glacier or Amazon S3 Glacier Deep Archive storage, you must configure an AWS IAM policy with the required permissions and then attach the policy to your AWS account used to access the for accessing AWS S3 storage.
|
|
NOTE: When crating an archive tier after upgrading to QoreStor 7.1, the default mode of restores is Lambda. If you create the archive tier before upgrading to QoreStor 7.1, the upgrade automatically switches the restores from Batch operations to Lambda. To change this option, see Editing an archive tier restore mode using the command line interface. |
To configure required permissions to restore from Archive Tier
- From the AWS console, go to the IAM dashboard.
- On the IAM dashboard, go to the Policies page, and then click Create Policy.
- On the Create policy page, click the JSON tab, and then copy and enter the text from the following JSON document:
|
|
NOTE: Enter the "AWS Account ID" and the "S3 Archive Tier Bucket Name" as appropriate. Using "*" as a placeholder for the "S3 Archive Tier Bucket Name" may cause an unimportant warning, which you can ignore. |
JSON Create Policy document
{ |
"Version": "2012-10-17", |
"Statement": [ |
{ |
"Sid": "VisualEditor0", |
"Effect": "Allow", |
"Action": [ |
"s3:GetObject", |
"s3:RestoreObject", |
"lambda:InvokeFunction" |
], |
"Resource": [ |
"arn:aws:lambda:*:<AWS Account ID>:function:*", |
"arn:aws:s3:::<S3 Archive Tier Bucket Name | *>/*" |
] |
}, |
{ |
"Sid": "VisualEditor1", |
"Effect": "Allow", |
"Action": "s3:PutObject", |
"Resource": "arn:aws:s3:::<S3 Archive Tier Bucket Name | *>/batch/*" |
} |
] |
} |
- Note the name of the new policy for the next steps. For example, GlacierTierRolePolicy.
- On the IAM dashboard Roles page, click Create Role.
- Select a trusted entity, select Custom trust policy, and then copy and enter the following JSON document:
JSON Custom Trust Policy document
{ |
"Version": "2012-10-17", |
"Statement": [ |
{ |
"Effect": "Allow", |
"Principal": { |
"Service": "batchoperations.s3.amazonaws.com" |
}, |
"Action": "sts:AssumeRole" |
}, |
{ |
"Effect": "Allow", |
"Principal": { |
"Service": "lambda.amazonaws.com" |
}, |
"Action": "sts:AssumeRole" |
} |
] |
} |
- Add permissions by searching and selecting the policy you created, and then click Next.
- Give the new role a name and then note the ARN of the IAM Role for next steps. For example, arn:aws:iam::<AWS Account ID>:role/GlacierTierRole.
- Return to the Policies page of the IAM dashboard and click Create Policy.
- Select JSON for permissions, and then replace the JSON text with the following policy document and save it:
|
|
NOTE: In the "Resource" portion, for "AWS Account ID" and "IAM Role Name," enter the specific Account ID and ARN of the role. Do not use the lambda function for batch restores. AWS requires you to use "*" in place of the bucket name. |
JSON Create Policy document
{ |
|
"Version": "2012-10-17", |
|
"Statement": [ |
|
{ |
|
"Sid": "VisualEditor0", |
|
"Effect": "Allow", |
|
"Action": [ |
|
"lambda:CreateFunction", |
|
"iam:GetRole", |
|
"lambda:InvokeFunction", |
|
"lambda:GetFunction", |
|
"lambda:UpdateFunctionConfiguration", |
|
"s3:RestoreObject", |
|
"s3:CreateBucket", |
|
"lambda:GetFunctionConfiguration", |
|
"s3:ListBucket", |
|
"lambda:PutFunctionConcurrency", |
|
"lambda:UpdateFunctionCode", |
|
"s3:PutObject", |
|
"s3:GetObject", |
|
"iam:PassRole", |
|
"lambda:GetFunctionConcurrency", |
|
"lambda:DeleteFunction", |
|
"lambda:DeleteFunctionConcurrency", |
|
"s3:DeleteObject", |
|
"s3:DeleteBucket" |
|
], |
|
"Resource": [ |
|
"arn:aws:iam::<AWS Account ID>:role/<IAM Role Name>", |
|
"arn:aws:lambda:*:<AWS Account ID>:function:QorestorArchiveRestore", |
|
"arn:aws:s3:::*" |
] |
|
}, |
|
{ |
|
"Sid": "VisualEditor1", |
|
"Effect": "Allow", |
|
"Action": "s3:ListAllMyBuckets", |
|
"Resource": "*" |
|
}, |
|
{ |
|
"Sid": "VisualEditor2", |
|
"Effect": "Allow", |
|
"Action": [ |
|
"s3:DescribeJob", |
|
"s3:UpdateJobPriority", |
|
"s3:UpdateJobStatus" |
|
], |
|
"Resource": "arn:aws:s3:*:<AWS Account ID>:job/*" |
|
}, |
|
{ |
|
"Sid": "VisualEditor3", |
|
"Effect": "Allow", |
|
"Action": [ |
|
"s3:ListJobs", |
|
"s3:CreateJob" |
|
], |
|
"Resource": "arn:aws:s3:*:<AWS Account ID>:job/*" |
|
} |
|
] |
|
} |
The policy creation is complete. Check that the permissions you entered are saved in the policy JSON document.
- To create an IAM User for the archive tier, go to the Users page of the IAM dashboard, click Add User, and complete the following steps:
- On the Add user page under Select AWS access type, to generate the access_key and secret_key, select Programmatic access.
- On the Permissions page, select Attach existing policy directly, and then select the policy you created in Step 10 to attach to this user.
- Following the directions in the remaining two tabs to finish creating the user.
|
|
NOTE: Be sure to download the access_keys for this user to use when creating an archive tier in QoreStor. |
Modifying an Archive Tier after an upgrade
If you created an Archive Tier after an upgrade to QoreStor 7.1, then the default mode of restores is Lambda. If you created the Archive Tier prior to upgrading to QoreStor 7.1, then the upgrade process automatically switched the default restore mode from Batch operations to Lambda. To revert this change back to the Batch option, complete the following procedure in the CLI.
To modify an Archive Tier after an upgrade
- In the CLI, use the following commands:
Restore mode change commands
cloud_tier --update |
[--cloud_password] |
|
[--cloud_archive] |
|
[--archive_retention_in_warm <1 to 365 days>] |
|
[--archive_role_arn <archive role arn>] |
|
[--archive_restore_type <Batch|Lambda>] |
|
[root@jayant-ol82-tst1 ~] |
# cloud_tier --update --archive_role_arn arn:aws:iam::177436582181:role/GlacierTierRole --archive_restore_type Lambda --cloud_archive |
Validating Role-arn string format for group name DefaultCloudArchiveTier ... |
Role-arn string format is valid We do basic format validation for the role ARN string. We cannot validate permissions at the time of addition/update – AWS does that during restore operation itself. |
Archive Tier updated successfully. |
[root@jayant-ol82-tst1 ~] |
# |
|
|
-
[root@jayant-ol82-tst1 ~] |
# cloud_tier --show --verbose --cloud_archive |
Cloud_tier Entry ID : 8 |
Cloud_tier Name : DefaultCloudArchiveTier |
Cloud_tier Compression Type : Fast |
Cloud_tier Encryption Set : On |
Cloud_tier Encryption Type : Static |
Cloud_tier Rotate Period : 0 |
Cloud_tier Passphrase set : Yes |
Cloud_tier Type : Cloud |
Cloud_tier Cloud container name : jayantcloud1 |
Cloud_tier Cloud provider name : AWS-S3 |
Cloud_tier Cloud archive service name : S3-Glacier |
Cloud_tier Archive retention in warm : 2 days |
Cloud_tier Archive role ARN string : arn:aws:iam::177436582181:role/GlacierTierRole |
Cloud_tier Archive Restore Type : Lambda Function |
Cloud_tier Cloud connection string : loglevel=trace;region=us-east-1; |
Cloud_tier Created On : Mon Aug 9 14:29:07 2021 PDT |
Cloud_tier Created Bld : 24E2B069 |
Cloud_tier status : Online |
Storage_group Is Storage Agent Group : No |
DefaultCloudArchiveTier's Containers |
------------------------------------ |
None |
|
[root@jayant-ol82-tst1 ~] |
# |
