Hiểu sao lưu và phục hồi dữ liệu, full, incremental, differential và đồng bộ cloud; thực hành restic để khôi phục hai phiên bản và kiểm tra đúng dữ liệu.
Một thư mục đã đồng bộ lên đám mây vẫn có thể mất tệp khi thao tác xóa được đồng bộ sang các thiết bị khác. Một ổ sao lưu luôn cắm vào máy cũng có thể chịu ảnh hưởng khi máy bị chiếm quyền. Muốn đánh giá tính khả dụng của dữ liệu, cần hỏi có thể phục hồi phiên bản nào, mất bao lâu và ai giữ quyền thực hiện.
Sau bài này, bạn giải thích full, incremental và differential backup; phân biệt sao lưu với đồng bộ; chọn phạm vi lưu giữ và kiểm chứng phục hồi. Kiến thức tiên quyết gồm quyền tệp, mã hóa lưu trữ và cách xử lý máy nghi nhiễm ở các bài trước.
Bài tham chiếu mục tiêu 023.4 của giáo trình Security Essentials 020-100, PDF phiên bản 2026-04-15, trang in 177–191. Tình huống và lab được viết độc lập, nguồn đối chiếu ngày 23/10/2026. Phần thực hành dùng restic 0.18.1 từ gói Ubuntu trong container Ubuntu 26.04.1 ARM64 riêng. Không kiểm thử OneDrive, S3, dịch vụ cloud, snapshot máy ảo hoặc sao lưu cơ sở dữ liệu đang chạy.
Bản sao lưu giữ dữ liệu để phục hồi khi bản đang dùng mất, hỏng hoặc bị sửa không mong muốn. Sao chép thành công chưa xác nhận dữ liệu nguồn đúng, bản sao đủ hoặc ứng dụng có thể mở lại. Nếu phần mềm chép một cơ sở dữ liệu giữa lúc các tệp đang thay đổi, tập hợp nhận được có thể không nhất quán; phải dùng phương pháp được ứng dụng hỗ trợ.
RPO mô tả mức mất dữ liệu chấp nhận được theo thời gian; RTO mô tả thời gian mục tiêu để khôi phục hoạt động. IBM giải thích các mục tiêu phục hồi cùng sự phụ thuộc vào cách sao lưu. Chúng là yêu cầu cần kiểm chứng, không tự trở thành cam kết chỉ vì đã ghi trong kế hoạch.
Tình huống giả định DEMO-B35: nhóm hỗ trợ chấp nhận mất tối đa bốn giờ cập nhật và cần đọc lại sổ công việc trong hai giờ. Lịch sao lưu hàng đêm khó đáp ứng RPO bốn giờ vào cuối ngày. Tải đủ dữ liệu về cũng chưa chứng minh RTO nếu còn phải tìm khóa, cấp quyền, cài ứng dụng và nhờ người dùng xác nhận.
| Kiểu | Dữ liệu được ghi | Bộ cần khi phục hồi một mốc |
|---|---|---|
| Full, toàn bộ | Toàn bộ tập dữ liệu đã chọn | Bản full của mốc đó |
| Incremental, gia tăng | Thay đổi từ lần sao lưu trước phù hợp trong chuỗi | Full nền và các phần gia tăng cần thiết |
| Differential, chênh lệch | Thay đổi kể từ full nền | Full nền và differential của mốc đích |
Giả sử full được tạo tối Chủ Nhật, incremental tiếp theo có ở tối thứ Hai và thứ Ba. Máy hỏng sáng thứ Tư trước khi tạo bản mới thì chuỗi này chỉ đưa bạn tới mốc sao lưu thứ Ba. Không thể lấy phần cập nhật sáng thứ Tư từ một bản thứ Tư chưa tồn tại. Nếu cần ít mất dữ liệu hơn, phải thiết kế thêm tần suất hoặc cơ chế phù hợp.
Với differential, bản tối thứ Ba chứa thay đổi tính từ full nền; bản thứ Hai không phải bước bắt buộc trong mô hình này. Kích thước và thời gian thực tế phụ thuộc dữ liệu thay đổi, nén, chống trùng lặp và công cụ. Không nên biến “incremental nhanh hơn” thành quy luật tuyệt đối cho mọi sản phẩm.
Các hệ thống hiện đại có thể trình bày từng snapshot như một ảnh đầy đủ nhưng bên dưới chia sẻ các khối dữ liệu. Lab restic minh họa khôi phục snapshot do công cụ quản lý, không yêu cầu người học tự nối những tệp incremental. Thuật ngữ của một sản phẩm cần được đọc theo tài liệu sản phẩm đó.
Snapshot trên cùng kho lưu trữ hỗ trợ quay lại trạng thái trước, nhưng vẫn có thể mất cùng thiết bị hoặc quyền quản trị bị chiếm. Snapshot được sao chép và bảo vệ độc lập có thể là thành phần của giải pháp sao lưu; chỉ có tên “snapshot” chưa chứng minh mức độc lập đó.
RAID giúp xử lý một số lỗi thiết bị tùy cấu hình, không tự giữ lịch sử khi người dùng xóa nhầm. Đồng bộ giúp các vị trí hội tụ về trạng thái mới, có thể truyền cả thay đổi không mong muốn. Lịch sử phiên bản và thùng rác là tính năng riêng, phụ thuộc thời hạn, gói dịch vụ và quyền quản trị; đồng bộ không mặc định bảo đảm lịch sử vô hạn.
Một tệp hiện tên trong File Explorer chưa chắc có đủ byte ở máy. Microsoft mô tả OneDrive Files On-Demand: tệp chỉ trực tuyến cần Internet để mở; chọn luôn giữ trên thiết bị sẽ tải nội dung về. Xóa một tệp chỉ trực tuyến vẫn có thể xóa nó trong OneDrive. “Free up space” và “Delete” có tác động khác nhau, cần đọc đúng thao tác trước khi thực hiện.
Khi lập danh sách sao lưu, ghi rõ công cụ có lấy nội dung tệp chỉ trực tuyến hay chỉ thấy placeholder. Thử mở một bản phục hồi riêng khi ngắt mạng trong lab phù hợp, thay vì dùng danh sách tên tệp làm bằng chứng dữ liệu đã sẵn sàng ngoại tuyến.
Chọn thời gian lưu theo nhu cầu tìm lại phiên bản, dung lượng, nghĩa vụ tổ chức và thời gian có thể phát hiện muộn sự cố. Không áp một mốc bảy hay ba mươi ngày cho mọi dữ liệu. Việc giữ vô hạn cũng làm tăng chi phí và phạm vi thông tin nhạy cảm cần quản lý.
Một điểm xuất phát là nhiều bản sao, nhiều miền lỗi và một bản ở nơi khác. Cần hỏi cụ thể: lỗi ổ đĩa, mất cả địa điểm, mất tài khoản hoặc ransomware có ảnh hưởng đồng thời tất cả bản không? Hai thư mục trên cùng ổ không tạo hai miền lỗi phần cứng. Cloud khác địa điểm nhưng dùng chung tài khoản toàn quyền vẫn có rủi ro chung về danh tính.
Bản ngoại tuyến hạn chế đường truy cập khi đã ngắt; bản bất biến hạn chế sửa hoặc xóa theo cơ chế giữ lại. Chúng không đồng nghĩa. AWS mô tả S3 Object Lock bảo vệ từng object version, với chế độ governance và compliance có quyền vượt hoặc sửa khác nhau. Đây là ví dụ về phạm vi tính năng, không phải cấu hình đã được thử trong bài.
Mã hóa giúp bảo vệ bí mật của bản sao; quyền truy cập và nhật ký vẫn cần thiết. Khóa phục hồi phải có đường truy cập được phê duyệt khi thiết bị nguồn mất. Nếu chỉ để khóa trên máy đã hỏng, bản mã còn nguyên vẫn không dùng được. Nếu kho sao lưu chứa cùng dữ liệu nhạy cảm như nguồn, hãy áp dụng yêu cầu bảo vệ tương ứng.
Lab mở rộng dùng restic 0.18.1 để tạo repository. Chỉ dùng dữ liệu DEMO; mật khẩu công khai bên dưới chỉ phục vụ fixture dùng một lần. Không dùng nó cho dữ liệu thật. Repository nằm cùng môi trường tạm với nguồn, vì vậy lab không tạo bản sao độc lập trước mất thiết bị.
Trong máy lab đã có restic và Bash, chạy khối sau trong một phiên shell. Lệnh sửa dữ liệu chỉ tác động tệp DEMO mới tạo. Dừng nếu một lệnh báo lỗi, không tiếp tục suy đoán kết quả:
set -eu
umask 077
work=$(mktemp -d /tmp/lpi35.XXXXXX)
cd "$work"
export RESTIC_REPOSITORY="$work/repo"
export RESTIC_PASSWORD_FILE="$work/password-demo"
export RESTIC_CACHE_DIR="$work/cache"
printf '%s\n' 'DEMO-only-not-a-real-secret' > "$RESTIC_PASSWORD_FILE"
mkdir data
printf 'DEMO report version 1\n' > data/report.txt
cp data/report.txt expected-v1.txt
restic version
restic init
restic backup data --tag DEMO-v1
printf 'DEMO report version 2\n' > data/report.txt
cp data/report.txt expected-v2.txt
restic backup data --tag DEMO-v2
printf 'DEMO damaged working copy\n' > data/report.txt
restic snapshots
restic check --read-data
restic restore latest --tag DEMO-v1 --target restore-v1
restic restore latest --tag DEMO-v2 --target restore-v2
cmp expected-v1.txt restore-v1/data/report.txt
cmp expected-v2.txt restore-v2/data/report.txt
cmp không in gì và trả 0 khi byte khớp. Hai đích phục hồi phải chứa hai nội dung khác nhau đúng phiên bản; tệp làm việc vẫn giữ dòng “damaged”. Các tệp expected là đối chứng do bài tạo, không phải cơ chế chống sửa dành cho hệ thống thật. Mật khẩu được đặt ngoài thư mục data để không tự đưa nó vào tập sao lưu.
Tài liệu phục hồi restic nêu cách chọn snapshot và đích. Lab dùng đích mới để tránh ghi đè dữ liệu đang dùng; kiểm tra tag, ID và nội dung trước khi áp dụng vào công việc. latest không tự hiểu phiên bản nghiệp vụ bạn muốn nếu phạm vi chọn chứa nhiều máy hoặc nguồn.
Trong lần kiểm chứng, restic 0.18.1 tạo hai snapshot, đọc lại dữ liệu kho không báo lỗi và phục hồi cả hai tệp khớp byte. Harness còn thử mật khẩu sai, bị từ chối; nguồn DEMO bị sửa vẫn giữ nguyên. Container chạy nonroot, mạng tắt, root filesystem chỉ đọc, toàn bộ fixture ở tmpfs. Kết quả không chứng minh thời gian phục hồi dữ liệu lớn, bảo toàn mọi metadata, ứng dụng hoạt động hoặc chống ransomware.
Theo tài liệu kiểm tra repository, kiểm tra cấu trúc và đọc dữ liệu cần được phân biệt. check --read-data trong lab nhỏ đọc dữ liệu thực; chi phí trên kho lớn cần lập lịch. Kiểm tra kho không thay cho mở tệp bằng ứng dụng và xác nhận nghiệp vụ.
Với yêu cầu thật, ghi nguồn, mốc thời gian và múi giờ, snapshot ID, phạm vi, vị trí phục hồi, người được phép nhận dữ liệu và kết quả mở kiểm tra. Nếu đang xử lý ransomware, phối hợp đội ứng cứu chọn môi trường phục hồi sạch trước khi nối lại mạng. Không dùng lần khôi phục thành công để bỏ qua nguyên nhân gây mất dữ liệu.
Tự kiểm tra DEMO-B36: tác vụ tối qua báo thành công nhưng không có tệp cloud chỉ trực tuyến. Phải ghi thiếu phạm vi, không báo đã sao lưu toàn bộ. DEMO-B37: kho mở được, tệp phục hồi khớp hash nhưng ứng dụng báo sai định dạng. Cần kiểm tra tính nhất quán và phiên bản ứng dụng, không đóng yêu cầu chỉ dựa hash.
Một bản bàn giao đạt cần nêu được dữ liệu nào đã phục hồi và phần nào chưa xác nhận. Lưu các giới hạn còn lại để người tiếp nhận không hiểu phép thử tệp nhỏ thành bảo đảm cho toàn hệ thống.
Học bảo vệ quyền riêng tư qua cookie, fingerprinting, hồ sơ và quyền dữ liệu; thực hành quan sát cookie trong lab riêng, phân biệt xóa cục bộ và log server.
Học giao tiếp an toàn qua phishing, tệp đính kèm, phân loại thông tin và quyền cloud; thực hành xác minh người nhận, giảm dữ liệu và xử lý chia sẻ nhầm.
Hiểu danh tính và xác thực với mật khẩu, MFA, passkeys và SSO; đối chiếu NIST 800-63B-4, thực hành salt và băm, lập đường khôi phục tài khoản phù hợp.
Phân biệt mã hóa mạng và ẩn danh với VPN, proxy, Tor và E2EE; đọc ranh giới bảo vệ, hiểu bút danh blockchain qua bốn tình huống thực hành giả định.