Object Storage có chống mất dữ liệu không? Cơ chế và lưu ý

Object Storage giúp giảm nguy cơ mất dữ liệu nhờ nhiều lớp bảo vệ, từ dự phòng phần cứng, kiểm tra toàn vẹn đến khôi phục phiên bản và kiểm soát quyền truy cập. Tuy nhiên, không có một cơ chế đơn lẻ nào xử lý được mọi rủi ro. Để bảo vệ dữ liệu hiệu quả, doanh nghiệp cần hiểu rõ nguyên nhân gây mất dữ liệu, giới hạn của từng tính năng và cách kết hợp Object Storage với chiến lược backup phù hợp.

Dữ liệu trên Object Storage có thể mất vì những nguyên nhân nào?

Dữ liệu trên Object Storage vẫn có thể bị mất, hỏng hoặc không thể khôi phục nếu hệ thống gặp sự cố vượt quá khả năng dự phòng, người dùng thao tác nhầm hoặc cơ chế bảo vệ chưa được cấu hình đúng. Vì vậy, muốn đánh giá khả năng chống mất dữ liệu, doanh nghiệp cần xác định rõ từng nhóm rủi ro thay vì chỉ nhìn vào số lượng bản sao.

Có thể thấy, khả năng chống mất dữ liệu không chỉ phụ thuộc vào hạ tầng lưu trữ. Hệ thống cần kết hợp dự phòng, phát hiện lỗi, bảo vệ trước thao tác nguy hiểm và phương án phục hồi khi sự cố xảy ra.

Độ bền (durability) khác tính sẵn sàng (availability) như thế nào?

Durability là khả năng bảo vệ dữ liệu khỏi mất mát trong thời gian lưu trữ, còn availability là khả năng truy cập dịch vụ hoặc dữ liệu khi có nhu cầu. Hai chỉ số này có liên quan nhưng không thể thay thế cho nhau.

1. Con số “11 số 9” cho biết điều gì?

Con số “11 số 9” tương ứng với độ bền dữ liệu được thiết kế ở mức 99,999999999%. Đây là chỉ số được sử dụng trong ngành lưu trữ đám mây để mô tả mức độ bền dữ liệu dự kiến theo mô hình và điều kiện thiết kế của nhà cung cấp.

Chẳng hạn, tài liệu của Amazon S3 công bố độ bền được thiết kế ở mức 99,999999999% đối với các lớp lưu trữ tương ứng. Đây là thông số của dịch vụ cụ thể, không phải cam kết mặc định cho mọi hệ thống tương thích S3.

Điều quan trọng là không diễn giải con số này thành lời bảo đảm rằng dữ liệu không bao giờ mất. Độ bền được thiết kế dựa trên các giả định về kiến trúc, dự phòng, phát hiện lỗi và phục hồi. Những rủi ro như xóa nhầm, lộ thông tin xác thực hoặc lỗi ứng dụng vẫn cần được xử lý bằng các cơ chế riêng.

Khi đánh giá một nhà cung cấp, doanh nghiệp nên hỏi rõ:

• Chỉ số durability được tính hoặc ước tính dựa trên mô hình nào?
• Dữ liệu được dự phòng trên nhiều ổ đĩa, máy chủ hay địa điểm?
• Nhà cung cấp có cơ chế phát hiện và sửa lỗi dữ liệu không?
• Chỉ số công bố có được bảo đảm bằng hợp đồng hay chỉ là mục tiêu thiết kế?

Không nên so sánh các dịch vụ chỉ dựa trên số lượng chữ số 9 nếu chưa biết phạm vi và điều kiện áp dụng của từng chỉ số.

2. Vì sao hệ thống vẫn truy cập được mà dữ liệu vẫn có thể mất và ngược lại?

Tính sẵn sàng và độ bền giải quyết hai vấn đề khác nhau nên có thể xảy ra những tình huống sau:

• Dịch vụ hoạt động nhưng dữ liệu bị thay đổi: Người dùng xóa nhầm đối tượng hoặc ứng dụng ghi đè lên tệp cũ. Hệ thống vẫn trả lời yêu cầu bình thường nhưng nội dung ban đầu có thể không còn nếu không có phiên bản hoặc bản backup.
• Dữ liệu vẫn tồn tại nhưng không truy cập được: Sự cố mạng, lỗi xác thực hoặc gián đoạn dịch vụ khiến người dùng không thể lấy dữ liệu dù dữ liệu chưa bị mất.
• Cả khả năng truy cập và dữ liệu đều bị ảnh hưởng: Một sự cố nghiêm trọng tại địa điểm lưu trữ có thể làm dịch vụ ngừng hoạt động, đồng thời gây mất dữ liệu nếu kiến trúc dự phòng không đủ khả năng chịu lỗi.

Vì vậy, doanh nghiệp cần đánh giá riêng chỉ số availability, cơ chế bảo vệ dữ liệu và phương án khôi phục sau sự cố. SLA uptime cao không đồng nghĩa với việc mọi dữ liệu đều có thể phục hồi trong mọi tình huống.

Chống hỏng phần cứng: Replication và Erasure Coding

Replication và Erasure Coding là hai cơ chế phổ biến giúp giảm nguy cơ mất dữ liệu khi ổ đĩa, máy chủ hoặc thành phần lưu trữ gặp sự cố. Chúng khác nhau về cách tổ chức dữ liệu, mức tiêu thụ dung lượng và khả năng chịu lỗi.

1. Replication hoạt động như thế nào và chịu lỗi ra sao?

Replication là cơ chế tạo và duy trì nhiều bản sao của dữ liệu trên các thiết bị hoặc vị trí lưu trữ khác nhau. Khi một thiết bị gặp lỗi, hệ thống có thể tiếp tục phục vụ dữ liệu từ bản sao còn hoạt động và tái tạo mức dự phòng khi điều kiện cho phép.

Ví dụ, nếu một đối tượng được lưu thành ba bản sao trên ba thiết bị độc lập, việc một thiết bị hỏng không nhất thiết khiến dữ liệu bị mất. Hai bản sao còn lại có thể giúp hệ thống tiếp tục hoạt động trong khi tiến hành thay thế hoặc tái tạo bản sao.

Tuy nhiên, hiệu quả của replication phụ thuộc vào cách bố trí bản sao. Ba bản sao nằm trên cùng một ổ đĩa không tạo ra mức bảo vệ tương đương với ba bản sao được phân bố trên các thiết bị và phạm vi lỗi độc lập.

Doanh nghiệp nên tìm hiểu:

• Bản sao được đặt trên các ổ đĩa, máy chủ hay cụm lưu trữ khác nhau?
• Hệ thống có tự động phát hiện và tái tạo bản sao khi xảy ra lỗi không?
• Quá trình tái tạo mất bao lâu và trong thời gian đó dữ liệu chịu thêm rủi ro gì?
• Các thao tác xóa hoặc ghi đè có được đồng bộ sang bản sao hay không?

Replication phù hợp khi cần tăng khả năng chịu lỗi và duy trì khả năng truy cập. Tuy nhiên, nó không tự động bảo vệ dữ liệu trước mọi lỗi logic hoặc hành động phá hoại.

2. Erasure Coding 4+2 khác gì replication 3 bản?

Erasure Coding chia dữ liệu thành các phần dữ liệu và phần dư thừa dùng để tái tạo dữ liệu khi một số phần bị mất. Thay vì lưu nguyên vẹn nhiều bản sao, hệ thống phân bố các phần này trên nhiều thiết bị hoặc vị trí theo thiết kế.

Ví dụ, cấu hình Erasure Coding 4+2 sử dụng bốn phần dữ liệu và hai phần parity. Nếu phân bố và triển khai đúng theo cấu hình này, hệ thống có thể tái tạo dữ liệu khi mất tối đa hai phần trong nhóm, với điều kiện các phần còn lại vẫn đủ để phục hồi.

Xét riêng dung lượng lưu trữ lý thuyết:

Ví dụ, với 1 TB dữ liệu gốc, Erasure Coding 4+2 cần khoảng 1,5 TB dung lượng thô, còn replication ba bản cần khoảng 3 TB. Các con số này chưa tính metadata, dung lượng dự phòng, overhead vận hành và những yếu tố triển khai thực tế.

Không nên kết luận Erasure Coding luôn tốt hơn replication. Erasure Coding thường giúp tiết kiệm dung lượng, trong khi replication có thể đơn giản hơn trong một số mô hình truy cập và phục hồi. Lựa chọn phù hợp phụ thuộc vào yêu cầu hiệu năng, khả năng chịu lỗi, chi phí và kiến trúc của nhà cung cấp.

3. Kiểm tra toàn vẹn dữ liệu và phát hiện bit rot

Bit rot là hiện tượng dữ liệu bị thay đổi hoặc hỏng theo thời gian do lỗi phần cứng, đường truyền hoặc các vấn đề khác trong quá trình lưu trữ. Nếu không được phát hiện, dữ liệu hỏng có thể tiếp tục tồn tại và gây khó khăn khi phục hồi.

Checksum là một trong những phương pháp giúp kiểm tra tính toàn vẹn dữ liệu. Hệ thống tính giá trị kiểm tra từ nội dung dữ liệu và đối chiếu khi truyền tải, lưu trữ hoặc đọc lại theo cơ chế được triển khai.

Tuy nhiên, phát hiện dữ liệu sai khác không đồng nghĩa với việc tự động khôi phục được dữ liệu đúng. Để sửa lỗi, hệ thống cần có nguồn dữ liệu đáng tin cậy, chẳng hạn bản sao nguyên vẹn hoặc phần dữ liệu dự phòng đủ để tái tạo.

Khi đánh giá Object Storage, doanh nghiệp nên hỏi nhà cung cấp có kiểm tra checksum khi tải lên hay không, có kiểm tra định kỳ dữ liệu đã lưu không và cơ chế xử lý khi phát hiện lỗi là gì.

>>>> Đọc thêm bài viết: Object Storage hoạt động như thế nào?

Chống xóa nhầm, ghi đè và ransomware: Versioning và Object Lock

Replication và Erasure Coding chủ yếu giúp hệ thống chịu lỗi ở tầng lưu trữ. Để xử lý rủi ro do thao tác người dùng, ứng dụng hoặc tấn công có chủ đích, doanh nghiệp cần những cơ chế bảo vệ ở tầng đối tượng, tiêu biểu là Versioning và Object Lock.

1. Versioning giữ lại những gì?

Versioning cho phép lưu giữ nhiều phiên bản của cùng một đối tượng khi dữ liệu được cập nhật hoặc ghi đè. Nhờ đó, người dùng có thể khôi phục phiên bản trước thay vì chỉ phụ thuộc vào bản hiện tại.

Ví dụ, một ứng dụng ghi đè tệp báo cáo tháng trước bằng nội dung sai. Nếu bucket đã bật Versioning và phiên bản cũ vẫn được lưu giữ, người quản trị có thể xác định phiên bản cần khôi phục và thực hiện phục hồi theo khả năng của dịch vụ.

Tuy nhiên, Versioning không phải giải pháp bảo vệ tuyệt đối. Khả năng khôi phục phụ thuộc vào chính sách lưu giữ, quyền truy cập và việc các phiên bản cũ có bị xóa hay không. Nếu tài khoản bị xâm phạm có quyền xóa phiên bản hoặc quản lý cấu hình bảo vệ, dữ liệu vẫn có thể gặp rủi ro.

Versioning cũng có thể làm tăng dung lượng sử dụng vì nhiều phiên bản của cùng một đối tượng được lưu lại. Doanh nghiệp cần xây dựng chính sách vòng đời phù hợp, tránh xóa phiên bản cần thiết quá sớm hoặc giữ mọi phiên bản vô thời hạn mà không kiểm soát chi phí.

2. Object Lock và mô hình WORM hoạt động như thế nào?

Object Lock là cơ chế bảo vệ đối tượng khỏi việc xóa hoặc thay đổi trong một khoảng thời gian hoặc theo chính sách lưu giữ được hỗ trợ. Cơ chế này thường được thiết kế theo mô hình WORM (Write Once, Read Many), tức dữ liệu đã ghi được bảo vệ để có thể đọc nhưng không bị sửa đổi hoặc xóa trái phép trong thời gian áp dụng.

Ở mức khái niệm, cần phân biệt hai chế độ thường gặp:

• Governance: Cho phép áp dụng biện pháp bảo vệ nhưng vẫn có thể có những quyền đặc biệt để vượt qua chế độ này theo điều kiện của nền tảng.
• Compliance: Đặt ra giới hạn nghiêm ngặt hơn đối với việc thay đổi hoặc xóa dữ liệu trong thời gian lưu giữ, kể cả với quản trị viên, tùy quy định cụ thể của nền tảng.

Legal Hold là cơ chế giữ lại đối tượng mà không nhất thiết gắn với thời hạn lưu giữ cố định. Nó có thể được sử dụng khi dữ liệu cần được bảo toàn để phục vụ kiểm toán, điều tra hoặc yêu cầu pháp lý.

Không phải mọi dịch vụ S3-compatible đều hỗ trợ đầy đủ các chế độ này hoặc có hành vi hoàn toàn giống nhau. Doanh nghiệp cần xác minh tài liệu kỹ thuật trước khi dựa vào Object Lock cho những yêu cầu tuân thủ quan trọng.

3. Object Lock liên quan gì đến Versioning và phiên bản đối tượng?

Trong mô hình S3 phổ biến, Object Lock gắn với việc bảo vệ phiên bản đối tượng. Versioning giúp duy trì các phiên bản, còn Object Lock áp dụng chính sách hạn chế xóa hoặc thay đổi đối với phiên bản được bảo vệ.

Hai tính năng có vai trò khác nhau. Versioning giúp phục hồi nội dung cũ, trong khi Object Lock giúp ngăn một số hành động làm mất dữ liệu trong thời gian bảo vệ. Khi kết hợp đúng cách, chúng có thể giảm rủi ro do thao tác nhầm hoặc tài khoản bị xâm phạm.

Tuy nhiên, việc bật hai tính năng không thay thế cho kiểm soát quyền truy cập, quản lý Access Key và quy trình backup. Doanh nghiệp cần kiểm tra điều kiện kích hoạt, quyền có thể thay đổi chính sách, thời gian lưu giữ và cách xử lý khi cần khôi phục dữ liệu.

Replication không thay thế backup: Những rủi ro cần xử lý riêng

Replication giúp duy trì bản sao khi một số thành phần lưu trữ gặp lỗi, nhưng không mặc nhiên tạo ra một bản backup độc lập. Nếu dữ liệu bị xóa, ghi đè hoặc thao tác phá hoại được đồng bộ sang các bản sao, doanh nghiệp có thể mất khả năng phục hồi nếu không có phiên bản hoặc bản backup phù hợp.

1. Sự cố tại một địa điểm và vai trò của bản sao ở vị trí khác

Nếu tất cả dữ liệu chỉ được lưu trong một phạm vi hạ tầng, các sự cố như mất điện diện rộng, hỏng thiết bị mạng hoặc sự cố tại data center có thể làm gián đoạn truy cập và ảnh hưởng đến dữ liệu.

Phân bố dữ liệu sang một địa điểm khác giúp giảm rủi ro khi một địa điểm gặp sự cố. Tuy nhiên, mức độ bảo vệ phụ thuộc vào việc các địa điểm có thực sự độc lập hay không, cơ chế đồng bộ hoạt động như thế nào và hệ thống có thể phục hồi trong tình huống nào.

Khi đánh giá replication khác địa điểm, doanh nghiệp nên xác minh:

• Hai địa điểm có độc lập về hạ tầng và phạm vi sự cố không?
• Dữ liệu được đồng bộ tự động hay cần kích hoạt cấu hình riêng?
• Có độ trễ đồng bộ không và dữ liệu mới nhất có thể bị ảnh hưởng thế nào khi xảy ra sự cố?
• Có quy trình chuyển đổi hoặc phục hồi dịch vụ đã được kiểm thử không?

Sự hiện diện của hai địa điểm không tự động chứng minh rằng hệ thống có khả năng phục hồi sau mọi thảm họa. Cần xem xét cả kiến trúc, cơ chế đồng bộ và quy trình vận hành.

2. Vì sao thao tác xóa có thể ảnh hưởng đến bản sao?

Replication có thể đồng bộ thay đổi từ hệ thống nguồn sang hệ thống đích, tùy cấu hình và loại replication được sử dụng. Vì vậy, khi người dùng xóa nhầm một đối tượng, hành động này có thể được truyền sang bản sao nếu cơ chế đồng bộ hỗ trợ và được cấu hình theo cách đó.

Điều này khác với việc có một bản backup độc lập được lưu giữ theo lịch và có chính sách bảo vệ riêng. Bản backup phù hợp có thể giúp khôi phục trạng thái dữ liệu tại thời điểm trước khi xảy ra sự cố, trong khi bản sao đồng bộ thường hướng đến việc duy trì dữ liệu giữa các hệ thống.

Doanh nghiệp không nên mặc định rằng replication sẽ luôn sao chép thao tác xóa, cũng không nên mặc định rằng nó sẽ giữ lại dữ liệu đã xóa. Cần kiểm tra chính xác hành vi của nền tảng đang sử dụng.

3. Những rủi ro cần kiểm soát từ phía người dùng

Ngay cả khi nhà cung cấp có kiến trúc dự phòng tốt, dữ liệu vẫn có thể gặp rủi ro do cấu hình và vận hành.

Ba nhóm vấn đề thường cần chú ý là:

• Lỗi cấu hình: Phân quyền quá rộng, chính sách lưu giữ chưa phù hợp hoặc cấu hình đồng bộ không đáp ứng yêu cầu phục hồi.
• Lộ Access Key: Kẻ tấn công có thể sử dụng quyền của tài khoản bị xâm phạm để đọc, ghi hoặc xóa dữ liệu tùy phạm vi quyền được cấp.
• Không kiểm thử phục hồi: Doanh nghiệp chỉ phát hiện bản backup không dùng được khi thực sự xảy ra sự cố.

Để giảm thiểu rủi ro, nên cấp quyền theo nguyên tắc tối thiểu, bảo vệ thông tin xác thực, theo dõi hoạt động truy cập, phân tách quyền quản trị khi có thể và kiểm tra định kỳ khả năng phục hồi.

Với dữ liệu quan trọng, doanh nghiệp có thể áp dụng chiến lược backup 3-2-1: duy trì ba bản dữ liệu, sử dụng hai loại phương tiện lưu trữ và có ít nhất một bản ở ngoài địa điểm chính. Đây là nguyên tắc tham khảo, cần điều chỉnh theo yêu cầu vận hành và khả năng phục hồi của hệ thống.

Checklist đánh giá khả năng chống mất dữ liệu của nhà cung cấp

Khi lựa chọn dịch vụ Object Storage, doanh nghiệp nên đánh giá cả kiến trúc, tính năng bảo vệ, khả năng phục hồi và điều khoản dịch vụ. Checklist dưới đây giúp chuyển những tuyên bố kỹ thuật thành các câu hỏi có thể kiểm chứng.

• Kiến trúc dự phòng: Dữ liệu được phân bố trên nhiều ổ đĩa, máy chủ, cụm lưu trữ hay địa điểm như thế nào? Hệ thống có thể chịu lỗi ở cấp độ nào và tái tạo dữ liệu ra sao khi một thành phần gặp sự cố?
• Độ bền dữ liệu (durability): Chỉ số được công bố áp dụng trong điều kiện nào, dựa trên tài liệu nào? Cần phân biệt cam kết durability với SLA uptime, vì khả năng truy cập dịch vụ không đồng nghĩa với việc dữ liệu được bảo toàn trong mọi tình huống.
• Versioning và Object Lock: Dịch vụ có hỗ trợ khôi phục phiên bản cũ, giới hạn quyền xóa hoặc ngăn sửa đổi dữ liệu trong thời gian lưu giữ hay không? Nếu cần Object Lock, hãy xác minh các chế độ được hỗ trợ, điều kiện kích hoạt và quyền quản lý. Đồng thời, cần tính đến dung lượng phát sinh khi lưu nhiều phiên bản.
• Replication giữa các địa điểm: Bản sao được lưu ở đâu, có độc lập với hệ thống chính không và độ trễ đồng bộ là bao lâu? Cần làm rõ cách xử lý thao tác xóa hoặc ghi đè để tránh mặc định rằng dữ liệu ở địa điểm khác luôn có thể dùng để khôi phục.
• Kiểm tra toàn vẹn và phục hồi: Nhà cung cấp có cơ chế kiểm tra checksum, phát hiện dữ liệu hỏng và sửa lỗi không? Doanh nghiệp cũng nên kiểm thử việc tải lại dữ liệu, khôi phục phiên bản và phục hồi từ bản backup theo quy trình thực tế.
• SLA và trách nhiệm khi xảy ra sự cố: Kiểm tra phạm vi cam kết uptime, cách đo lường, các trường hợp loại trừ và điều kiện bồi thường. Không nên hiểu SLA uptime là cam kết tuyệt đối rằng dữ liệu không thể bị mất.

Trước khi ký hợp đồng, doanh nghiệp nên yêu cầu nhà cung cấp làm rõ ba vấn đề: Dữ liệu được bảo vệ trước những loại sự cố nào? Những trường hợp nào vẫn có nguy cơ mất dữ liệu? Quy trình và thời gian phục hồi được xác định ra sao?

S3 Object Storage của LANIT và khả năng bảo vệ dữ liệu

Khi đánh giá S3 Object Storage của LANIT, doanh nghiệp nên đối chiếu các tính năng được giới thiệu trên trang dịch vụ S3 Object Storage với nhu cầu bảo vệ dữ liệu thực tế. Việc lựa chọn không nên chỉ dựa trên khả năng tương thích S3 hoặc dung lượng lưu trữ, mà cần xem xét cả cơ chế khôi phục, kiểm soát truy cập và phương án backup.

Có thể đánh giá dịch vụ theo từng nhóm tiêu chí:

• Khả năng khôi phục dữ liệu: Tìm hiểu cách bật và sử dụng Versioning, phạm vi hỗ trợ Object Lock, quyền quản lý phiên bản và điều kiện lưu giữ.
• Khả năng chịu lỗi hạ tầng: Xác nhận kiến trúc đồng bộ giữa các địa điểm, mức độ độc lập của các vị trí lưu trữ và cách hệ thống xử lý khi một địa điểm gặp sự cố.
• Bảo mật và truy vết: Làm rõ cơ chế mã hóa, quản lý Access Key, phân quyền và phạm vi thông tin được ghi log.
• Tính sẵn sàng: Đối chiếu uptime công bố với SLA, cách tính, các trường hợp loại trừ và chính sách xử lý khi không đạt cam kết.
• Phương án backup: Xác định dữ liệu có cần được sao lưu thêm sang một hệ thống độc lập hay không, cách kiểm thử phục hồi và trách nhiệm vận hành của từng bên.

Cần nhấn mạnh rằng uptime 99,99% là chỉ số về tính sẵn sàng theo phạm vi cam kết, không phải chỉ số durability. Tương tự, có Versioning hoặc Object Lock không đồng nghĩa mọi thao tác xóa đều bị ngăn chặn trong mọi điều kiện. Doanh nghiệp nên xác minh cách các tính năng này được triển khai và phối hợp với nhau trên dịch vụ thực tế.

Object Storage có bao giờ bị mất dữ liệu không?

Có. Object Storage được thiết kế để tăng độ bền dữ liệu thông qua dự phòng và các cơ chế bảo vệ, nhưng vẫn có thể gặp rủi ro do lỗi vượt quá khả năng chịu đựng của hệ thống, thao tác xóa, ghi đè, lỗi ứng dụng hoặc cấu hình không phù hợp. Doanh nghiệp cần kết hợp các lớp bảo vệ và phương án backup để giảm thiểu nguy cơ.

Erasure Coding và Replication nên chọn cái nào?

Erasure Coding thường có lợi thế về hiệu quả sử dụng dung lượng, trong khi replication lưu nhiều bản sao đầy đủ và có thể phù hợp với những yêu cầu vận hành nhất định. Lựa chọn phụ thuộc vào hiệu năng, khả năng chịu lỗi, chi phí, cách phân bố dữ liệu và kiến trúc của nhà cung cấp.

Bật Versioning đã đủ chống ransomware chưa?

Chưa đủ. Versioning giúp giữ lại phiên bản cũ để hỗ trợ khôi phục, nhưng tài khoản bị xâm phạm vẫn có thể gây rủi ro nếu có quyền xóa phiên bản hoặc thay đổi cấu hình. Doanh nghiệp nên kết hợp kiểm soát quyền truy cập, Object Lock khi phù hợp, giám sát hoạt động và backup độc lập.

Replication sang vùng khác có thay thế backup không?

Không mặc nhiên. Replication giúp duy trì bản sao ở vị trí khác, nhưng các thay đổi hoặc thao tác xóa có thể được đồng bộ tùy cấu hình. Backup có chính sách lưu giữ và khả năng phục hồi độc lập giúp doanh nghiệp quay lại trạng thái dữ liệu trước sự cố.

Đã dùng Object Storage thì có cần backup riêng không?

Với dữ liệu quan trọng, doanh nghiệp vẫn nên đánh giá nhu cầu backup riêng. Object Storage có thể là nơi lưu bản backup, nhưng cần xác định bản backup có độc lập với dữ liệu nguồn không, có được bảo vệ trước thao tác xóa hoặc tài khoản bị xâm phạm không và có thể phục hồi thành công hay không.

Object Storage chống mất dữ liệu bằng cách kết hợp nhiều cơ chế, từ Replication và Erasure Coding để chịu lỗi phần cứng, đến Versioning và Object Lock để bảo vệ dữ liệu trước những thao tác không mong muốn. Tuy nhiên, mỗi cơ chế có giới hạn riêng và không thể thay thế hoàn toàn các lớp bảo vệ còn lại.

Khi đánh giá một dịch vụ, doanh nghiệp cần phân biệt durability với availability, kiểm tra kiến trúc dự phòng, chính sách bảo vệ phiên bản, khả năng phục hồi và điều kiện SLA. Đặc biệt, replication không mặc nhiên thay thế backup độc lập.