No. However, you can enable versioning for your bucket so that you can store multiple versions of an object in a bucket, and extract, delete, or restore a specific object version. Versioning allows you to restore data lost due to accidental deletion or application failures. For more information, please see Setting Versioning.
You can achieve disaster recovery in COS by:
You can set a lifecycle rule and enable Managing historical versions to transition or delete noncurrent object versions.
No. By default, the old object with the same name will be overwritten by the new one. However, you can enable versioning for your bucket so that multiple object versions can be preserved. For more information, please see Versioning Overview.
If you download with APIs or SDKs, add the
versionId request parameter. For the API calling directions, see GET Object.
If you download via the console, set the historical versions to Display in the top navigation bar so that you can download the desired object version.
You can use the COSBrowser tool to one-click delete noncurrent object versions in batches. For more information, please see COSBrowser User Guide for Desktop Version.
You can also configure a lifecycle policy to delete objects that were modified more than 1 day ago for noncurrent object versions.
By default, cross-region replication uses a private network.
Note that cross-region replication incurs traffic fees, which cannot be redeemed with a resource pack yet. The fees incurred will be deducted from your account at 00:00 the next day.
Yes. Resources under the same account can be synced between two regions. You can set cross-bucket replication to replicate objects incrementally.
No. You can use Batch Operation instead.
In a source bucket with cross-bucket replication enabled, COS will replicate the following:
- If you specify an object version to delete in the source bucket by specifying a version ID, COS will not replicate this delete operation.
- If you add a bucket-level configuration such as a lifecycle rule to the source bucket, COS will not replicate any resulting object operations.
For more information, please see Cross-Bucket Replication Actions.
A client-side/COS-managed/KMS key is used to encrypt the file content into ciphertext, which affects performance to some extent (mainly by increasing access delay). The delay does not significantly affect large object reads/writes, but has a certain impact on small object reads/writes.
To get an encrypted object, include an encryption header when reading it. The encryption header differs according to the encryption algorithm. For more information, please see Common Request Headers.
COS data is stored at the underlying layer using multiple replicas or erasure coding (both are imperceptible to users). The storage engines are distributed across multiple availability zones in a region, making the data reliability 99.999999999%.