This article describes how Tencent Cloud Object Storage (COS) addresses data layer disaster recovery.
1. Cross-AZ Disaster Recovery
If your application is already deployed in Tencent Cloud, you can use COS's multi-AZ capabilities to improve the data layer availability. Multi-AZ refers to the multi-AZ storage architecture offered by COS, which can provide IDC-level disaster recovery capabilities for your data.
In this architecture, data will be split into multiple chunks, and corresponding coding chunks will be calculated based on the erasure code algorithm. The original data chunks and coding chunks will be mixed up and evenly distributed to IDCs in different AZs in a region for storage and intra-region disaster recovery.
The multi-AZ feature provides 99.9999999999% (12 nines) designed data reliability and 99.995% designed service availability. When you upload data objects to COS, you can store them in a multi-AZ region simply by specifying the storage class.
After the multi-AZ feature is enabled, your data will be distributed among IDCs in multiple AZs in a region. When an IDC fails due to extreme situations such as natural disasters or power outages, other IDCs can still guarantee normal data reads and writes, thereby ensuring persistent storage, business continuity, and high availability.
2. Cross-Region Disaster Recovery
In addition to the multi-AZ feature of COS, you can also save data copies in different regions to further improve the data layer availability.
COS's cross-region bucket replication feature asynchronously replicates data across regions. It is a bucket-level configuration item, where rules can be configured to replicate incremental objects from one bucket to another bucket automatically and asynchronously.
With cross-bucket replication, COS can accurately replicate exactly the same object content, along with object metadata and version IDs, from the source bucket to the destination bucket. Additionally, object operations such as adding or deleting objects can also be synced to the destination bucket.
With cross-region bucket replication, when the IDC in one region is damaged due to force majeure, the IDC in another region can still provide data copies for your use, implementing cross-region disaster recovery.
In addition to high availability, cross-region bucket replication can also meet industry-specific requirements for data compliance. If you have end users accessing objects from different regions, you can maintain object copies in buckets closest to them geographically, so as to minimize the access latency and deliver a better user experience.
3. Versioning
If data is deleted accidentally, it will be lost permanently even if cross-AZ or cross-region disaster recovery is implemented.
To avoid data loss due to accidental deletion or application failure, COS has launched the versioning feature. It allows you to store multiple versions of an object in the same bucket. For example, you can store multiple objects with the same object key "picture.jpg" but different version IDs like "100000", "100101", and "120002" in a bucket. Then, you can query, delete, or restore objects in the bucket by version ID. This enables you to recover from data loss caused by accidental deletion or application failure. For example, when you delete an object with versioning enabled:
• If you need to delete the object (not permanently), COS will insert a delete marker for the deleted object. The marker will serve as the current object version and can be used for version restoration.
• If you need to replace the object, COS will insert a new version ID for the newly uploaded object. You can still restore the replaced object with the version ID.
There are three versioning states for a bucket:
• Versioning not enabled: Bucket versioning is not enabled by default.
• Versioning enabled: When bucket versioning is enabled, it will be applied to all the objects in the bucket. After versioning is enabled for the first time, new objects uploaded to the bucket will be assigned a unique version ID.
• Versioning suspended: After versioning is suspended (it cannot be disabled once enabled), new objects uploaded to the bucket will no longer be subject to versioning.
You can upload, query, and delete objects no matter which versioning state the bucket is in.
4. Anti-Overwrite for Upload
Besides force majeure, data exceptions may also occur due to operations that don't seem risky. COS maintains the eventual consistency by overwriting an existing file when another file with the same name is uploaded. To avoid unexpected overwrites, you need to maintain a complete name check system in your business logic. Alternatively, you can enable versioning, which leads to a more complex logic for object management and extra storage usage though. More often than not, you only need to forbid overwrites of certain files, which makes versioning unnecessary in terms of functionality.
To this end, COS provides an anti-overwrite mechanism at bucket and object levels. You can enable bucket-level anti-overwrite, then the bucket will forbid uploads of any files with the same name. Specifically, when a file with the same name is uploaded, COS will deny the upload request to ensure that the existing file in the bucket will not be overwritten. If you only want to prevent certain files in the bucket from being overwritten, you can add a special header to the upload request, which checks whether any file in the bucket has the same name as the file to be uploaded, and if so, the upload will fail. After anti-overwrite is enabled, you can still rename or delete files.
5. Object Lock
In some compliance scenarios, anti-overwrite is far from enough though. For example, in the finance field, compliance regulations require file retention for a certain period of time and prohibit file overwrite, deletion, and modification. In this case, you can use object lock to meet the requirements. After it is enabled, within the retention period:
1.Objects cannot be deleted or modified;
2.The storage class of objects cannot be modified;
3.The HTTP headers and user metadata of objects cannot be modified, including "Content-Type", "Content-Encoding", "Content-Language", "Content-Disposition", "Cache-Control", "Expires", and "x-cos-meta-".
Object lock perfectly meets compliance requirements.
Compared with local secondary IDCs, cloud-based disaster recovery features higher reliability, availability, and security and gets rids of repeated hardware, computing, networking, and software. It greatly reduces the TCO while guaranteeing the RPO and RTO.
Read more at: https://www.tencentcloud.com/dynamic/blogs/sample-article/100379
Top comments (0)