| | |
| Specify the storage path in the TOS bucket to which the object will be uploaded. - Current Directory: Uploads the object to the current directory.
- Specified Directory: Customizes the directory name and upload the object to this directory. When naming the directory, be aware of the following:
- Directory names can contain Chinese characters, letters, numbers, and common symbols.
- You can use forward slashes (/) to quickly create subfolders. However, the folder name cannot start with a forward slash (/) or backslash (\) and cannot contain consecutive forward slashes (/).
- .. cannot be used as a folder name.
| |
| Select or drag and drop files or folders from your local device. tip You cannot have duplicate filenames in the same bucket. If you upload a file with the same name as an existing file, the system will process it according to the following rules: - If versioning is disabled: The uploaded file will replace the existing file.
- If versioning is enabled: The uploaded file will become the latest version, and the existing file will be kept as a previous version. For more information, see Versioning.
| |
| | Expand Advanced settings to specify the storage type for the object to be uploaded. By default, objects use the storage type of the bucket they are stored in. The options are as follows: - Inherit Bucket (Default): Objects use the storage type of the bucket they are stored in.
- Standard Storage: High availability, reliability, and performance, suitable for frequently accessed data.
- Intelligent Tiering: Designed for data with unpredictable access patterns, which will incur object monitoring charges. For more information, see Intelligent Tiering.
- Infrequent Access Storage: Designed for frequently accessed data with a minimum storage duration of 30 days.
- Flashback Archive: Optimized for rarely accessed data with a minimum storage duration of 90 days.
- Archive: Suited for long-term storage of rarely accessed data with a minimum storage duration of 90 days. You need to restore data in Archive before reading them.
- Cold Archive: Suited for long-lived, rarely accessed data with flexible latency requirements. The minimum storage duration is 180 days. You need to restore data in Cold Archive before reading them.
- Deep Cold Archive: Cost-effective storage for extremely cold data with ultra-long retention needs. The minimum storage duration is 180 days. You need to restore data in Deep Cold Archive before reading them.
tip - Cold Archive is only supported in China (Beijing), China (Shanghai), and China (Guangzhou).
- Deep Cold Archive is only supported in China (Beijing), China (Shanghai), and China (Guangzhou). Deep Cold Archive is currently in closed beta. Please contact your account manager for access.
- If you have enabled multi-AZ redundancy for the bucket, you can only choose the storage type from the following options: Inherit Bucket, Standard Storage (Multi-AZ), Intelligent Tiering (Multi-AZ), Infrequent Access Storage (Multi-AZ), and Flashback Archive (Multi-AZ). For more information on multi-AZ, see Multi-AZ redundancy.
For detailed information about storage types, please refer to . |
| | Expand Advanced settings to configure the server-side encryption method. The available encryption options are: - Inherit Bucket Encryption Configuration (Default): An object gets the server-side encryption method from its bucket. You can find the server-side encryption method of the bucket in the Basic information section of the bucket's Overview page. You can also change the bucket's server-side encryption method. For instructions, see Setting bucket encryption.
- None: No encryption applied.
- SSE-TOS: TOS-managed encryption. Objects are encrypted automatically upon upload and decrypted during download using TOS-hosted keys. For more information, see Server-side encryption.
- SSE-KMS: Uses keys managed by Volcano Engine's Key Management Service (KMS) to encrypt and decrypt objects. For more information, see Server-side encryption.
tip - SSE-TOS and SSE-KMS are only supported in China (Beijing), China (Shanghai), Asia Pacific (Johor), and Asia Pacific (Jakarta).
- You can only set the server-side encryption method when uploading objects. You cannot change the encryption settings of uploaded objects.
- If you are using SSE-KMS for server-side encryption for the first time, you must first activate KMS. Although activating KMS is free, using the service incurs charges. Using SSE-KMS for server-side encryption generates API call fees, and creating KMS keys generates key management fees. These fees are charged by KMS. For more information, see KMS Billing Overview.
|
| | Expand Advanced settings and select the encryption algorithm for the key. Options include AES256 and SM4. tip - The encryption algorithm parameter only appears when SSE-KMS or SSE-TOS is selected for Server-Side encryption.
- The AES-256 algorithm is only supported in China (Beijing), China (Shanghai), Asia Pacific (Johor), and Asia Pacific (Jakarta). The SM4 algorithm is only supported in China (Beijing) and China (Shanghai).
|
| | Expand Advanced settings to set the encryption key. The default setting is Custom Key. tip The Encryption Key Type parameter only appears when SSE-KMS is selected for Server-Side encryption. |
| | Expand Advanced settings and select a key created in KMS. If you have not created a key yet, proceed to the KMS console to do so. For instructions, see KMS Quickstarts. tip The Encryption Key Type parameter only appears when SSE-KMS is selected for Server-Side encryption. |
| | Expand Advanced settings and click Add Field to configure object metadata. For more information on user-defined object metadata, see Managing object metadata. |
| | The following options are available when setting the access control list (ACL) policy for objects to be uploaded to the bucket: - Inherit bucket: An object inherits the permissions from its bucket, meaning the object's ACL will mirror the bucket's. For details on the relationship between object ACL and bucket ACL, see Inheriting ACL settings from the bucket.
- Private (Default): Only the object owner and authorized accounts have read and write permissions. This is the recommended setting.
- Public read: All users, including those making anonymous requests, can read the object. However, only the owner and authorized accounts can modify it.
- Public read/write: All users, including those making anonymous requests, can have full read and write access to the object.
|