Oracle Cloud Infrastructure offers two distinct storage class tiers to address the need for both performant, frequently accessed "hot" storage, and less frequently accessed "cold" storage. Storage tiers help you maximize performance where appropriate and minimize costs where possible.
- Use Archive Storage for data to which you seldom or rarely access, but that must be retained and preserved for long periods of time. The cost efficiency of the Archive Storage offsets the long lead time required to access the data.
- Use Object Storage for data to which you need fast, immediate, and frequent access. Data accessibility and performance justifies a higher price point to store data in the Object Storage. For more information, see Overview of Object Storage.
About Archive Storage
Archive Storage is ideal for storing data that is accessed infrequently and requires long retention periods. Archive Storage is more cost effective than Object Storage for preserving cold data for:
- Compliance and audit mandates
- Retroactively analyzing log data to determine usage pattern or debug problems
- Historical or infrequently accessed content repository data
- Application generated data that requires archival for future analysis or legal purposes
Unlike Object Storage, Archive Storage data retrieval is not instantaneous.
Using Archive Storage
You interact with the data stored in the Archive Storage using the same resources and management interfaces that you use for data stored in Object Storage.
The following summarizes the Object Storage resources you use to store and manage Archive Storage data:
Buckets are logical containers for storing objects. A bucket is associated with a single A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. that has An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. that determine what actions a user can perform on a bucket and on all the objects in the bucket.
You decide which storage tier (Archive Storage or standard Object Storage) is appropriate for your data when you initially create the bucket container for your data. The storage tier is expressed as a property of the bucket. A bucket's storage tier property sets the initial storage tier of objects added to the bucket. However, objects placed in standard tier buckets can be archived automatically by Object Storage (while remaining in the standard tier bucket) if they meet the criteria of an object lifecycle policy rule in effect for the bucket.
Once set, you cannot change the storage tier property for a bucket:
- An existing Object Storage bucket cannot be downgraded to an Archive Storage bucket.
- An Archive Storage bucket cannot be upgraded to an Object Storage bucket.
In addition to the inability to change the storage tier designation of a bucket, there are other reasons why storage tier selection for buckets requires careful consideration:
- The minimum retention requirement for Archive Storage is 90 days. If you delete objects from Archive Storage before the minimum retention requirements are met, you are charged a deletion penalty. The deletion penalty is the prorated cost of storing the data for the full 90 days.
- While Archive Storage is more cost effective than Object Storage for cold storage, understand that when you restore objects, you are returning those objects to Object Storage. You are billed for that storage service class while the objects reside in that tier.
You can use object lifecycle policy rules to automatically delete objects in an Archive Storage bucket based on the age of the object.
You cannot use object lifecycle policy rules to automatically restore archived objects to the regular Object Storage tier. See Restoring and Downloading Objects for information on restoring objects.
See Managing Buckets for detailed instructions on creating an Archive Storage bucket.
Any type of data, regardless of content type, is stored as an object. The object is composed of the object itself and metadata about the object. Each object is stored in a bucket.
You upload objects to an Archive Storage bucket the same way you upload objects to a standard Object Storage bucket. The difference is that when you upload an object to an Archive Storage bucket, the object is immediately archived. You must first restore the object before you can download it.
Archived objects are displayed in the object listing of a bucket. You can also display the details of each object.
See Managing Objects for detailed instructions on uploading objects to an Archive Storage bucket.
To download an object from Archive Storage, you must first restore the object. Restoration takes about four hours from the time an Archive Storage restore request is made, to the time the first byte of data is retrieved. The retrieval time metric is measured by Time To First Byte (TTFB). How long the full restoration takes, depends on the size of the object. You can determine the status of the restoration by looking at the object Details. Once the status shows as Restored, you can then download the object.
After an object is restored, you have a window of time to download the object. By default, you have 24 hours to download an object, but you can alternatively specify a time from 1 to 240 hours. You can find out how much of the download time is remaining by looking at Available for Download in object Details. After the allotted download time expires, the object returns to Archive Storage. You always have access to the metadata for an object, regardless of whether the object is in an archived or restored state.
See Managing Objects for detailed instructions on restoring, checking status of, and downloading Archive Storage objects.
Archive Storage and Object Storage share the same management interfaces:
The Console is an easy-to-use, browser-based interface. To access Archive Storage in the console, do the following:
- Sign in to the Console.
Open the navigation menu. Under Core Infrastructure, click Object Storage. A list of the buckets in the compartment you're viewing is displayed. If you don’t see the one you're looking for, verify that you’re viewing the correct compartment (select from the list on the left side of the page).
- Click the name of the Archive Storage tier bucket you want to manage.
The command line interface (CLI) provides both quick access and full functionality without the need for programming. For more information, see Command Line Interface (CLI).
The syntax for the CLI commands include specifying a service. You will use the Object Storage service designation:
oci osto manage Archive Storage using the CLI.
- The REST API provides the most
functionality, but requires programming expertise. API Reference and Endpoints provides endpoint details and links to the available API reference documents. For general information about
using the API, see REST APIs. Archive Storage is accessible with the following APIs:
- Object Storage Service API
- Amazon S3 Compatibility API
- Swift API (for use with Oracle RMAN)
- Oracle Cloud Infrastructure provides SDKs that interact with Archive Storage and Object Storage without you having to create a framework. For general information about using the SDKs, see Software Development Kits and Command Line Interface.
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up A collection of users who all need a particular type of access to a set of resources or compartment., A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization., and An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
For administrators: Users that need to restore archived objects require the OBJECT_RESTORE permission. See Details for Object Storage, Archive Storage, and Data Transfer for more information.
You can achieve WORM compliance with Archive Storage by applying IAM policy permissions so that data once written, cannot be overwritten.
For administrators: There is not a direct way to disallow OBJECT_OVERWRITE. To achieve WORM compliance, you must specifically grant groups OBJECT_CREATE, OBJECT_READ, and OBJECT_INSPECT permissions to keep the data from being overwritten. For example, you can allow groups to inspect objects using a policy like the following:
Allow group <group_name> to inspect in compartment <compartment_name>
See Details for Object Storage, Archive Storage, and Data Transfer for more information. If you are new to policies, see Getting Started with Policies and Common Policies.
Limits on Archive Storage Resources
See Service Limits for a list of applicable limits and instructions for requesting a limit increase.
Additional limits include:
- Number of namespaces per root compartment: 1
- Maximum object size: 10 TiB
- Maximum object part size: 50 GiB
- Maximum size of object metadata: 2 K