Backup dữ liệu là gì? Tại sao nó rất quan trọng với doanh nghiệp

Dữ liệu là một trong những tài sản quan trọng nhất của hệ thống CNTT. Website, Database, máy chủ, máy ảo, email, tài liệu nội bộ, ERP, CRM và các ứng dụng doanh nghiệp đều phụ thuộc vào khả năng lưu trữ và truy xuất dữ liệu.

Tuy nhiên, dữ liệu có thể bị mất hoặc hư hỏng bởi nhiều nguyên nhân:

• HDD/SSD hỏng
• Server gặp sự cố
• Storage lỗi
• Xóa nhầm dữ liệu
• Database corruption
• Lỗi ứng dụng
• Malware
• Ransomware
• Lỗi cấu hình
• Sự cố Data Center
• Thiên tai
• Lỗi của con người

Một hệ thống có RAID, SAN Storage hoặc Cloud vẫn không đồng nghĩa dữ liệu đã được Backup.

Để bảo vệ dữ liệu thực sự, doanh nghiệp cần xây dựng một chiến lược Backup & Recovery dựa trên mức độ quan trọng của từng workload.

Vậy Backup dữ liệu là gì? Backup hoạt động như thế nào? Full, Incremental và Differential Backup khác nhau ra sao? Snapshot có phải Backup không? Và một hệ thống Backup doanh nghiệp cần được thiết kế như thế nào?

Backup dữ liệu là gì?

Backup dữ liệu là gì?

Backup dữ liệu (Data Backup) là quá trình tạo và duy trì một hoặc nhiều bản sao có thể khôi phục của dữ liệu gốc nhằm phục vụ quá trình Recovery khi dữ liệu production bị mất, hỏng, xóa nhầm hoặc không còn đáng tin cậy.

Dữ liệu được Backup có thể bao gồm:

• File
• Folder
• Database
• Email
• Virtual Machine
• Operating System
• Application
• Configuration
• Server
• Container/Persistent Data
• Cloud Workload
• NAS
• Endpoint

Ví dụ:

Doanh nghiệp có một File Server chứa:

10 TB dữ liệu

Thay vì chỉ lưu dữ liệu trên Server đó, hệ thống Backup tạo thêm các restore point trên một Backup Repository độc lập.

Khi File Server gặp sự cố, dữ liệu có thể được Restore từ Repository.

Về mặt kỹ thuật:

Production Data → Backup Process → Backup Repository → Restore Point → Recovery

Điểm quan trọng nhất là:

Backup không chỉ là copy dữ liệu. Mục tiêu cuối cùng là tạo ra dữ liệu có thể khôi phục được khi Production gặp sự cố.

Tại sao Backup dữ liệu lại quan trọng?

Một hệ thống CNTT có thể được thiết kế với phần cứng rất tốt nhưng vẫn không thể loại bỏ hoàn toàn nguy cơ mất dữ liệu.

Hỏng phần cứng

Các thiết bị như:

• HDD
• SSD
• RAID Controller
• Server
• NAS
• SAN

đều có thể gặp sự cố.

RAID giúp tăng khả năng chịu lỗi của hệ thống Storage nhưng RAID không phải Backup.

Ví dụ RAID 1 có hai ổ đĩa mirror:

Disk 1 ↔ Disk 2

Nếu Disk 1 hỏng, Disk 2 vẫn còn dữ liệu.

Nhưng nếu người dùng xóa nhầm một thư mục, thao tác xóa cũng được phản ánh trên hệ thống RAID.

RAID bảo vệ chủ yếu trước một số lỗi phần cứng.

Backup bảo vệ dữ liệu theo một mục tiêu khác.

Xóa nhầm dữ liệu

Một nhân viên có thể vô tình xóa:

/Customer_Data/

hoặc Administrator có thể thực hiện nhầm lệnh.

Nếu có Backup, doanh nghiệp có thể Restore dữ liệu về restore point trước khi xảy ra thao tác xóa.

Ransomware

Ransomware có thể mã hóa:

• File Server
• Endpoint
• Database
• Network Share
• Virtual Machine

Nếu Backup Repository cũng có thể bị attacker truy cập và xóa/mã hóa, doanh nghiệp vẫn có nguy cơ mất khả năng Recovery.

Do đó, hệ thống Backup hiện đại cần quan tâm đến:

• Immutability
• Offline Copy
• Air Gap
• MFA
• Separate Credentials
• Network Segmentation
• Least Privilege

Database Corruption

Database có thể gặp lỗi logic hoặc corruption.

Ví dụ Database đang hoạt động bình thường lúc:

09:00

và bị corruption lúc:

10:30.

Nếu có restore point hoặc transaction log phù hợp, Administrator có thể khôi phục Database về thời điểm trước sự cố.

Backup và Restore là gì?

Hai khái niệm này luôn đi cùng nhau.

Backup

Backup là quá trình tạo dữ liệu phục vụ khôi phục.

Luồng cơ bản:

Production → Backup Repository

Restore

Restore là quá trình đưa dữ liệu từ Backup trở lại hệ thống.

Luồng:

Backup Repository → Production/Recovery Environment

Ví dụ:

File bị xóa → File-Level Restore

VM bị lỗi → VM Restore

Database lỗi → Database Restore

Server hỏng → Bare Metal Recovery

Data Center gặp sự cố → Disaster Recovery

Do đó:

Backup thành công chưa đồng nghĩa Recovery chắc chắn thành công.

Một hệ thống Backup chuyên nghiệp cần kiểm tra cả:

Backup Success + Backup Integrity + Restore Test.

Backup hoạt động như thế nào?

Một kiến trúc Backup cơ bản gồm ba thành phần.

Source

Source là dữ liệu cần bảo vệ.

Ví dụ:

• Physical Server
• Virtual Machine
• Database
• NAS
• Endpoint
• Cloud VM
• SaaS Data

Backup Software hoặc Backup Server

Đây là thành phần điều phối quá trình Backup.

Nó có thể thực hiện:

• Scheduling
• Changed Block Tracking
• Compression
• Deduplication
• Encryption
• Retention
• Catalog
• Monitoring
• Recovery

Backup Repository

Repository là nơi lưu dữ liệu Backup.

Có thể là:

• HDD
• Backup Server
• NAS
• SAN
• Object Storage
• Cloud Storage
• Tape

Kiến trúc đơn giản:

Production Server

↓

Backup Server

↓

Backup Repository

↓

Offsite / Immutable / Tape / Cloud Copy

Trong hệ thống lớn, kiến trúc có thể có thêm Proxy, Gateway, Media Server và nhiều lớp Storage.

Restore Point là gì?

Restore Point là trạng thái dữ liệu tại một thời điểm mà hệ thống có thể sử dụng để Recovery.

Ví dụ hệ thống Backup chạy lúc:

• 00:00
• 06:00
• 12:00
• 18:00

thì có thể có các restore point tương ứng.

Nếu Server lỗi lúc:

20:00

Administrator có thể Restore về:

18:00.

Trong trường hợp đó, dữ liệu phát sinh từ 18:00 đến 20:00 có nguy cơ không nằm trong restore point.

Đây chính là lý do cần hiểu RPO.

>> Xem thêm: Dịch vụ bảo mật dữ liệu của VDO

RPO là gì?

RPO – Recovery Point Objective xác định mức mất dữ liệu theo thời gian mà tổ chức đặt ra làm mục tiêu có thể chấp nhận sau sự cố.

Ví dụ:

RPO = 24 giờ

→ Chiến lược bảo vệ phải được thiết kế để đáp ứng mức mất dữ liệu mục tiêu tương ứng.

RPO = 4 giờ

→ Restore point cần được tạo thường xuyên hơn.

RPO = 15 phút

→ Có thể cần Backup, replication, transaction log hoặc CDP với tần suất cao hơn.

Có thể hiểu:

RPO quyết định “có thể mất bao nhiêu dữ liệu?”.

RPO càng thấp thì yêu cầu đối với hạ tầng bảo vệ dữ liệu thường càng cao.

RTO là gì?

RTO – Recovery Time Objective là mục tiêu thời gian để khôi phục dịch vụ sau sự cố.

Ví dụ:

Server bị lỗi lúc:

10:00

RTO = 2 giờ

thì kiến trúc Recovery phải hướng tới việc đưa dịch vụ trở lại trong khoảng thời gian mục tiêu đã xác định.

Có thể hiểu:

RTO = Hệ thống cần hoạt động trở lại nhanh đến mức nào?

RPO và RTO giải quyết hai bài toán khác nhau:

Hai chỉ số này là nền tảng khi thiết kế Backup và Disaster Recovery.

Các phương pháp Backup dữ liệu phổ biến

Ba phương pháp cơ bản là:

• Full Backup
• Incremental Backup
• Differential Backup

Full Backup là gì?

Full Backup sao lưu toàn bộ tập dữ liệu được lựa chọn.

Ví dụ Server có:

2 TB dữ liệu

Một Full Backup logic sẽ bảo vệ toàn bộ dataset 2 TB đó.

Ưu điểm Full Backup

• Restore đơn giản
• Ít phụ thuộc Backup Chain
• Quản lý dễ hơn
• Phù hợp làm baseline

Nhược điểm Full Backup

• Backup Window dài
• Sử dụng nhiều Storage
• Sử dụng nhiều Network Bandwidth
• Tạo tải lớn hơn lên Source

Do đó, với hệ thống hàng chục hoặc hàng trăm TB, thực hiện Active Full thường xuyên có thể không hiệu quả.

Incremental Backup là gì?

Incremental Backup chỉ sao lưu dữ liệu thay đổi kể từ lần Backup gần nhất.

Ví dụ:

Chủ nhật: Full – 2 TB

Thứ hai: Incremental – 50 GB

Thứ ba: Incremental – 30 GB

Thứ tư: Incremental – 40 GB

Backup Chain:

Full → Inc 1 → Inc 2 → Inc 3

Ưu điểm:

• Backup nhanh
• Tiết kiệm Storage
• Giảm Network Traffic
• Backup Window nhỏ

Nhược điểm:

• Phụ thuộc Backup Chain
• Restore có thể phức tạp hơn

Differential Backup là gì?

Differential Backup lưu tất cả dữ liệu thay đổi kể từ Full Backup gần nhất.

Ví dụ:

Chủ nhật: Full

Thứ hai: thay đổi CN → T2

Thứ ba: thay đổi CN → T3

Thứ tư: thay đổi CN → T4

Do đó Differential Backup thường lớn dần cho đến khi Full Backup mới được tạo.

So sánh Full, Incremental và Differential Backup

Trong hệ thống hiện đại còn có các mô hình:

• Forward Incremental
• Forever Forward Incremental
• Reverse Incremental
• Synthetic Full

Synthetic Full Backup là gì?

Synthetic Full tạo một Full Backup mới bằng dữ liệu đã có trên Backup Repository thay vì đọc lại toàn bộ dữ liệu từ Production.

Ví dụ:

Full + Inc1 + Inc2 + Inc3 → Synthetic Full

Điều này giúp giảm:

• Production I/O
• Network Traffic
• Backup Window phía Source

Tuy nhiên, Backup Repository phải thực hiện thêm các tác vụ xử lý dữ liệu.

Backup Chain là gì?

Backup Chain là chuỗi các Backup File có quan hệ với nhau.

Ví dụ:

Full → Incremental 1 → Incremental 2 → Incremental 3

Mỗi thành phần có thể tương ứng với các restore point khác nhau.

Nếu một thành phần cần thiết trong chain bị mất hoặc corruption, khả năng Restore một số restore point phụ thuộc vào nó có thể bị ảnh hưởng.

Vì vậy cần:

• Health Check
• Backup Verification
• Repository Monitoring
• Restore Test

Không nên tự ý xóa từng Incremental Backup khỏi Repository mà không hiểu cơ chế Retention của phần mềm Backup.

Backup khác Snapshot như thế nào?

Đây là một trong những khái niệm dễ nhầm nhất.

Snapshot không mặc định đồng nghĩa với Backup.

Snapshot ghi nhận trạng thái dữ liệu tại một thời điểm và thường phụ thuộc vào Storage hoặc hệ thống nguồn.

Backup hướng tới việc tạo dữ liệu có thể phục hồi và thường được lưu trên hạ tầng độc lập hơn.

Ví dụ:

VM chạy trên Datastore A.

Snapshot:

VM → Snapshot trên Datastore A

Backup:

VM → Backup Repository B

Nếu Datastore A hỏng hoàn toàn, Snapshot nằm trên cùng hệ thống có thể không còn khả dụng.

Trong khi Backup Repository B độc lập có khả năng vẫn còn dữ liệu.

Vì vậy:

Snapshot rất hữu ích nhưng không nên tự động xem Snapshot là sự thay thế cho Backup.

Backup khác Replication như thế nào?

Replication tạo hoặc duy trì một bản sao dữ liệu/hệ thống trên hạ tầng khác để hỗ trợ availability và recovery.

Ví dụ:

Server A → Replication → Server B

Replication có thể giúp RTO thấp vì bản sao đã tồn tại ở hệ thống đích.

Tuy nhiên, Replication không mặc định thay thế Backup.

Nếu:

File bị xóa → thay đổi được replicate

hoặc:

Dữ liệu bị mã hóa → dữ liệu mã hóa được replicate

thì bản sao cũng có thể nhận thay đổi đó, tùy kiến trúc.

Backup với nhiều restore point cho phép quay lại trạng thái dữ liệu trước sự cố.

Có thể hiểu:

Backup tập trung vào khả năng phục hồi dữ liệu theo thời điểm.

Replication tập trung nhiều hơn vào việc duy trì bản sao phục vụ availability/recovery.

Một kiến trúc tốt có thể sử dụng cả hai.

Backup khác RAID như thế nào?

RAID cũng thường bị nhầm với Backup.

Ví dụ RAID 5 hoặc RAID 6 có khả năng chịu lỗi một số ổ đĩa tùy cấu hình.

Nhưng RAID không bảo vệ hiệu quả trước:

• Xóa nhầm
• Ransomware
• Database corruption
• Administrator Error
• Server bị mất
• Cháy Data Center

Do đó:

RAID = Availability/Storage Resilience

Backup = Data Recovery

RAID không thay thế Backup.

File-Level Backup và Image-Level Backup

File-Level Backup

Backup từng:

• File
• Folder
• Directory

Phù hợp khi chỉ cần bảo vệ dữ liệu cụ thể.

Image-Level Backup

Backup toàn bộ image của:

• VM
• Volume
• Server

Có thể bao gồm:

• OS
• Application
• Configuration
• Data

Image-Level Backup rất hữu ích khi cần khôi phục toàn bộ Server hoặc VM.

Application-Consistent Backup là gì?

Với Database hoặc ứng dụng transactional, chỉ copy file chưa chắc tạo ra Backup có thể phục hồi chính xác.

Ví dụ:

Database đang có transaction chưa hoàn tất khi Backup xảy ra.

Nếu Backup chỉ ghi dữ liệu ở trạng thái bất kỳ trên disk, restore có thể gặp vấn đề consistency.

Application-Consistent Backup phối hợp với ứng dụng để đưa dữ liệu về trạng thái phù hợp trước khi tạo Backup.

Điều này đặc biệt quan trọng với:

• Microsoft SQL Server
• Oracle
• PostgreSQL
• Exchange
• Active Directory
• ERP
• Transactional Applications

Do đó, Backup Database cần được thiết kế dựa trên cơ chế của Database Engine chứ không đơn giản là copy file database.

Backup Database cần chú ý điều gì?

Một chiến lược Database Backup có thể bao gồm:

• Full Backup
• Incremental/Differential
• Transaction Log
• Archive Log
• Point-in-Time Recovery

Ví dụ hệ thống yêu cầu:

RPO = 15 phút

Nếu chỉ Full Backup mỗi đêm lúc 00:00 thì không đáp ứng được mục tiêu.

Có thể cần:

Full Backup + Log Backup mỗi 15 phút

tùy Database.

Khi đó, Administrator có khả năng phục hồi Database tới một thời điểm gần với lúc xảy ra sự cố hơn.

Quy tắc Backup 3-2-1

Một nguyên tắc phổ biến trong Data Protection là:

3 bản dữ liệu

1 Production + 2 Backup Copy.

2 loại phương tiện hoặc hệ thống lưu trữ

Giảm nguy cơ lỗi chung.

1 bản Offsite

Lưu ngoài địa điểm chính.

Ví dụ:

Production Storage

Local Backup Repository

Offsite Object Storage/Tape

Nếu Data Center chính gặp sự cố vật lý, Offsite Copy vẫn có thể phục vụ Recovery.

Backup 3-2-1-1-0 là gì?

Trong môi trường có Ransomware, mô hình 3-2-1 thường được mở rộng thành cách tiếp cận như 3-2-1-1-0.

Có thể hiểu theo hướng:

3 – Có ít nhất 3 bản dữ liệu.

2 – Lưu trên 2 loại phương tiện/hệ thống.

1 – Có ít nhất 1 bản Offsite.

1 – Có thêm 1 bản Offline, Air-gapped hoặc Immutable.

0 – Hướng tới 0 lỗi được phát hiện trong quá trình kiểm tra khả năng phục hồi/Backup Verification.

Điểm quan trọng không nằm ở việc ghi nhớ con số, mà ở việc loại bỏ single point of failure khỏi hệ thống Backup.

Immutable Backup là gì?

Immutable Backup là Backup được bảo vệ để không thể bị sửa hoặc xóa trong một khoảng thời gian retention đã xác định, theo cơ chế của nền tảng triển khai.

Mục tiêu là giảm khả năng:

• Ransomware xóa Backup
• Attacker mã hóa Backup
• Administrator xóa nhầm
• Credential bị đánh cắp rồi dùng để phá Backup

Immutability ngày càng quan trọng trong thiết kế Cyber Resilience.

Air-Gapped Backup là gì?

Air Gap tạo sự tách biệt giữa Backup và Production.

Một bản Backup có thể được:

• Offline
• Tách khỏi Network
• Lưu trên Tape
• Cô lập logic
• Bảo vệ bằng kiến trúc hạn chế truy cập

Mục tiêu là ngăn một cuộc tấn công trên Production Network dễ dàng lan sang toàn bộ Backup.

Retention Policy là gì?

Retention Policy xác định Backup được giữ trong bao lâu.

Ví dụ:

Daily: 30 ngày

Weekly: 12 tuần

Monthly: 12 tháng

Yearly: 5 năm

Retention cần được xây dựng dựa trên:

• Business Requirement
• Compliance
• Storage Capacity
• RPO/RTO
• Legal Requirement
• Cost

Giữ quá ít restore point có thể khiến doanh nghiệp không quay lại được trạng thái dữ liệu đủ xa.

Giữ quá nhiều mà không có chiến lược có thể làm tăng đáng kể Storage Cost.

Backup dữ liệu nên lưu ở đâu?

Không có một Storage Tier phù hợp cho mọi loại Backup.

Disk Backup

Ưu điểm:

• Restore nhanh
• Random Access tốt
• Phù hợp Backup Repository chính

NAS

Phù hợp với:

• SMB
• File Backup
• Secondary Repository

Nhưng cần bảo vệ quyền truy cập và Network Segmentation.

Object Storage

Phù hợp với:

• Scale-out Backup
• Offsite Backup
• Cloud
• Immutability/Object Lock tùy nền tảng

Tape

Tape vẫn có giá trị đối với:

• Long-Term Retention
• Archive
• Offline Copy
• Air Gap vật lý

Cloud Backup

Phù hợp khi doanh nghiệp cần:

• Offsite Copy
• Geographic Separation
• Elastic Storage

Nhưng cần tính toán:

• Bandwidth
• Storage Cost
• API Cost
• Retrieval Cost
• Egress
• Restore Time

Compression và Deduplication trong Backup

Compression

Compression giảm kích thước dữ liệu bằng thuật toán nén.

Ví dụ:

1 TB Raw Data → 600 GB Backup

chỉ là một ví dụ; tỷ lệ thực tế phụ thuộc loại dữ liệu.

Video, ảnh JPEG hoặc file đã nén thường khó nén thêm.

Deduplication

Deduplication loại bỏ các block dữ liệu trùng lặp.

Ví dụ 100 VM cùng sử dụng nhiều block OS giống nhau.

Thay vì lưu 100 lần, hệ thống deduplication có thể chỉ cần lưu block duy nhất và tham chiếu lại tùy kiến trúc.

Điều này có thể giúp giảm đáng kể dung lượng Backup trong một số workload.

Encryption trong hệ thống Backup

Backup thường chứa toàn bộ dữ liệu quan trọng của doanh nghiệp.

Do đó cần xem xét mã hóa:

Data in Transit

Mã hóa khi dữ liệu truyền:

Production → Backup Repository

Data at Rest

Mã hóa dữ liệu đã lưu trên:

• Disk
• Tape
• Cloud
• Object Storage

Tuy nhiên, Encryption cũng tạo thêm một yêu cầu quan trọng:

Phải bảo vệ Encryption Key.

Nếu mất Key, doanh nghiệp có thể có đầy đủ Backup nhưng không thể giải mã để Restore.

Ransomware có thể tấn công Backup không?

Có.

Một hệ thống Backup kết nối trực tiếp với Production Domain và sử dụng credential có đặc quyền cao có thể trở thành mục tiêu của attacker.

Kịch bản có thể là:

Compromise Admin Account

↓

Access Backup Server

↓

Delete Restore Points

↓

Encrypt Production

Lúc này doanh nghiệp có Backup về mặt lý thuyết nhưng không còn restore point khả dụng.

Do đó, Backup Architecture cần được coi là một phần của Cybersecurity Architecture, không chỉ là Storage.

Những sai lầm phổ biến khi Backup dữ liệu

Lưu Backup trên cùng Server

Ví dụ:

Production:

D:\Data

Backup:

E:\Backup

nhưng D và E đều nằm trên cùng một Physical Server.

Nếu Server gặp sự cố nghiêm trọng, cả hai có thể mất.

Cho rằng RAID là Backup

RAID tăng availability nhưng không tạo historical restore point độc lập.

Cho rằng Snapshot là đủ

Snapshot rất hữu ích nhưng nếu phụ thuộc cùng Storage, nó vẫn có thể bị ảnh hưởng bởi lỗi Storage hoặc sự cố quản trị.

Không kiểm tra Restore

Backup Job hiển thị:

Success

không phải bằng chứng tuyệt đối rằng toàn bộ quy trình Disaster Recovery sẽ thành công.

Cần thực hiện:

Restore Test.

Không giám sát Backup

Một Backup Job có thể fail nhiều ngày vì:

• Repository Full
• Network Error
• Credential Expired
• Snapshot Error
• Storage Failure

Nếu không Monitoring, Administrator có thể chỉ phát hiện khi cần Restore.

Một hệ thống Backup doanh nghiệp nên được thiết kế như thế nào?

Không nên bắt đầu bằng câu hỏi:

“Mua bao nhiêu TB Storage?”

Nên bắt đầu từ Business Requirement.

Quy trình hợp lý là:

Bước 1 – Inventory

Xác định hệ thống cần bảo vệ.

Bước 2 – Classification

Phân loại:

• Critical
• Important
• Standard
• Archive

Bước 3 – Xác định RPO

Có thể mất bao nhiêu dữ liệu?

Bước 4 – Xác định RTO

Hệ thống phải phục hồi trong bao lâu?

Bước 5 – Chọn Backup Method

• Full
• Incremental
• Synthetic Full
• Log Backup
• Snapshot Integration

Bước 6 – Thiết kế Repository

Tính:

• Capacity
• Throughput
• IOPS
• Retention
• Growth
• Compression
• Deduplication

Bước 7 – Thiết kế Secondary Copy

• Offsite
• Cloud
• Tape
• Object Storage

Bước 8 – Bảo vệ Backup

• Immutability
• Encryption
• MFA
• Segmentation
• Separate Credentials

Bước 9 – Monitoring

Theo dõi:

• Job Success
• Repository Capacity
• Backup Duration
• SLA
• RPO
• Error
• Security Event

Bước 10 – Restore Testing

Kiểm tra định kỳ:

• File Restore
• VM Restore
• Database Restore
• Application Recovery
• Full Disaster Recovery

Ví dụ kiến trúc Backup cho doanh nghiệp

Giả sử doanh nghiệp có:

20 VM

Tổng dữ liệu:

10 TB

Change Rate:

5%/ngày

Yêu cầu:

RPO = 4 giờ

RTO = 2 giờ đối với hệ thống quan trọng

Kiến trúc có thể được thiết kế theo hướng:

VMware/Hyper-V

↓

Backup Proxy/Server

↓

Local Backup Repository

↓

Immutable/Offsite Backup Copy

↓

Cloud hoặc Secondary Site

Lịch Backup có thể sử dụng Incremental theo tần suất đáp ứng RPO, kết hợp Synthetic Full và Retention Policy phù hợp.

Tuy nhiên, cấu hình cuối cùng phải được sizing dựa trên:

• Change Rate thực tế
• Backup Throughput
• Network
• Storage Performance
• Retention
• Compression Ratio
• Deduplication
• Restore SLA

Backup dữ liệu có phải Disaster Recovery không?

Không hoàn toàn.

Backup là một thành phần của Disaster Recovery.

Backup trả lời:

“Dữ liệu để phục hồi nằm ở đâu?”

Disaster Recovery còn phải giải quyết:

• Server chạy ở đâu?
• Network phục hồi thế nào?
• DNS?
• Firewall?
• IP?
• Application dependency?
• Authentication?
• Database?
• Thứ tự khởi động dịch vụ?
• Người nào chịu trách nhiệm?
• Khi nào kích hoạt DR Site?

Do đó:

Backup ≠ Disaster Recovery Plan.

Một doanh nghiệp có Backup nhưng không có quy trình Recovery vẫn có thể mất nhiều thời gian để đưa hệ thống hoạt động trở lại.

Câu hỏi thường gặp về Backup dữ liệu

Backup dữ liệu là gì?

Backup dữ liệu là quá trình tạo và duy trì bản sao có thể phục hồi của dữ liệu nhằm khôi phục khi dữ liệu gốc bị mất, hỏng, xóa nhầm hoặc không còn sử dụng được.

Backup và sao lưu dữ liệu có giống nhau không?

Có. Trong CNTT, “sao lưu dữ liệu” là cách gọi tiếng Việt phổ biến của Data Backup.

RAID có phải Backup không?

Không. RAID chủ yếu giúp tăng khả năng chịu lỗi và availability của Storage trước một số lỗi ổ đĩa. RAID không tạo ra các restore point độc lập để bảo vệ trước xóa nhầm, ransomware hoặc corruption.

Snapshot có phải Backup không?

Không phải trong mọi trường hợp. Snapshot thường phụ thuộc vào Storage hoặc hệ thống nguồn. Một Backup độc lập cần được thiết kế để dữ liệu vẫn có thể phục hồi khi Production gặp sự cố.

Nên Backup bao lâu một lần?

Không có một con số áp dụng cho mọi doanh nghiệp. Tần suất Backup phải dựa trên RPO của từng workload.

Backup nên giữ bao lâu?

Phụ thuộc vào Retention Policy, yêu cầu kinh doanh, pháp lý, compliance, Storage Capacity và chi phí.

Backup có chống được Ransomware không?

Backup giúp Recovery sau Ransomware, nhưng chỉ khi Backup không bị attacker phá hủy. Vì vậy cần kết hợp Immutability, Offline/Air-gap, phân quyền, MFA, Network Segmentation và Restore Testing.

Có Backup rồi có cần Replication không?

Tùy RTO/RPO. Backup và Replication giải quyết những mục tiêu khác nhau và có thể được sử dụng đồng thời trong hệ thống yêu cầu Business Continuity cao.

Kết luận

Backup dữ liệu là quá trình tạo và duy trì các bản sao có thể khôi phục của dữ liệu nhằm đảm bảo doanh nghiệp có khả năng Recovery khi Production Data bị mất, hỏng, xóa nhầm hoặc bị tấn công.

Một chiến lược Backup chuyên nghiệp không chỉ là:

Copy dữ liệu từ Server A sang Storage B.

Nó phải giải quyết toàn bộ chuỗi:

Data Classification → RPO → RTO → Backup Method → Repository → Retention → Offsite Copy → Immutability → Monitoring → Restore Testing → Disaster Recovery.

Trong đó cần đặc biệt phân biệt:

RAID không phải Backup.

Snapshot không mặc định thay thế Backup.

Replication không thay thế hoàn toàn Backup.

Backup Job Success không đồng nghĩa Recovery chắc chắn thành công.

Đối với doanh nghiệp, câu hỏi quan trọng nhất vì vậy không phải là:

“Chúng ta có Backup chưa?”

Mà là:

“Nếu toàn bộ hệ thống gặp sự cố ngay bây giờ, dữ liệu nào có thể khôi phục, khôi phục về thời điểm nào và mất bao lâu để đưa dịch vụ trở lại?”

Nếu hệ thống Backup có thể trả lời chính xác ba câu hỏi đó – khôi phục cái gì, về thời điểm nào và trong bao lâu – doanh nghiệp mới thực sự bắt đầu xây dựng được một chiến lược Data Protection có giá trị.

Từ khóa liên quan: Backup dữ liệu, sao lưu dữ liệu, Data Backup, Backup Server, Full Backup, Incremental Backup, Differential Backup, Backup và Restore, RPO RTO, Disaster Recovery, 3-2-1 Backup, Snapshot, Immutable Backup.