Sao lưu và phục hồi dữ liệu Linux server bằng rsync và tar
Xác định dữ liệu cần sao lưu, dùng rsync và tar có kiểm soát, giữ bản sao riêng và thử restore; hiểu giới hạn đồng bộ, database đang chạy và tùy chọn delete.
Một thư mục đã được sao chép chưa chắc là bản backup có thể phục hồi. Bạn còn cần biết dữ liệu được lấy lúc nào, có nhất quán không, bản sao nằm ở đâu và đã thử khôi phục bằng cách nào. Bài này dùng Ubuntu Server 24.04 LTS để thực hành rsync và tar với dữ liệu tĩnh, sau đó kiểm tra restore vào thư mục riêng.
Xác định thứ cần bảo vệ và mục tiêu phục hồi
Liệt kê dữ liệu ứng dụng, cấu hình, upload, thông tin package và các thành phần cần để dựng lại dịch vụ. Không sao lưu credential vào nơi chia sẻ không được bảo vệ. Bản backup có thể chứa dữ liệu nhạy cảm ngang hoặc nhiều hơn hệ thống gốc, nên cần policy truy cập và mã hóa phù hợp.
Hai câu hỏi thực dụng là chấp nhận mất tối đa bao lâu dữ liệu và cần phục hồi trong bao lâu. Chúng giúp chọn tần suất, nơi lưu và cách kiểm tra. Không cam kết thời gian phục hồi từ dung lượng file mà chưa đo restore cùng bước khởi động ứng dụng.
Trong bài, dữ liệu tĩnh dưới /srv/backup-lab/source là fixture lab, không phải dữ liệu production. Ví dụ không tạo một bản sao toàn bộ hệ điều hành đang chạy và không xử lý tính nhất quán database. Đối chiếu rsync manual để hiểu tùy chọn trước khi mở rộng phạm vi.
Các lệnh giả định tài khoản lab tên labadmin; thay owner/group theo môi trường. Không dùng cùng tên tùy tiện trên máy quản lý danh tính tập trung. Thư mục copies cùng ổ chỉ để thực hành cú pháp, chưa đáp ứng yêu cầu bản sao độc lập khỏi lỗi máy nguồn.
Trước khi chạy, kiểm tra source và destination bằng ls -ld, findmnt -T và df -h. Một mount backup không được gắn có thể khiến tác vụ ghi nhầm vào filesystem root. Với đích từ xa, xác minh host key và quyền đích bằng quy trình SSH đã học.
-n dry-run hiển thị thay đổi dự kiến nhưng không thay dữ liệu. Dấu / cuối source trong ví dụ yêu cầu sao chép nội dung thư mục; bỏ nó có thể tạo thêm một cấp tên thư mục tại đích tùy cách gọi. Luôn kiểm tra cấu trúc đích thực tế trước khi đưa lệnh vào lịch.
-a bảo toàn một nhóm thuộc tính theo archive mode; không tự bao gồm mọi thứ như ACL, extended attributes hoặc hard link. Nếu ứng dụng cần các thuộc tính đó, xem các tùy chọn tương ứng và khả năng filesystem đích hỗ trợ. Sao chép owner/group theo danh tính cũng cần quyền phù hợp và đối chiếu UID/GID giữa các máy.
Một lần chạy exit 0 là tín hiệu tốt cho tác vụ, nhưng chưa chứng minh toàn bộ hệ thống có thể phục hồi. Exit code khác 0 phải được xem xét; không bỏ qua vì “phần lớn file đã copy”. Dữ liệu đang thay đổi có thể tạo kết quả không nhất quán dù lệnh sao chép cơ bản làm đúng công việc của nó.
Mô hình kỹ thuật để giải thích cơ chế; không phải bằng chứng kiểm thử.
Vì sao đồng bộ không thay thế backup có phiên bản
Mirror phản ánh trạng thái nguồn ở một thời điểm. Nếu file nguồn bị sửa sai và tác vụ tiếp theo chép đè bản tốt, bạn mất khả năng quay về. Tương tự, nếu dùng tùy chọn xóa đồng bộ, việc xóa nhầm ở nguồn có thể lan tới đích.
--delete có thể xóa file ở destination không còn ở source. Chỉ cân nhắc khi mục tiêu thực sự là mirror, đã kiểm tra dry-run và source/destination đúng. Không gắn tùy chọn này vào lệnh mặc định của bài nhập môn. Đặc biệt, source rỗng do mount lỗi có thể làm một thao tác đồng bộ xóa nhiều dữ liệu đích ngoài ý định.
Giữ bản theo thời điểm hoặc dùng công cụ backup có retention, kiểm tra và quản lý phiên bản khi nhu cầu tăng. Không coi việc đổi tên thư mục thủ công mãi mãi là chiến lược dài hạn; cần có người chịu trách nhiệm kiểm tra dung lượng, thời hạn giữ và khả năng restore.
Tạo archive tar cho một mốc dữ liệu tĩnh
Tạm dừng thay đổi fixture rồi chạy:
tar -czf /srv/backup-lab/copies/source-lab.tar.gz -C /srv/backup-lab source
tar -tzf /srv/backup-lab/copies/source-lab.tar.gz
sha256sum /srv/backup-lab/copies/source-lab.tar.gz
Đặt archive ngoài cây source để tránh tự đưa file backup đang tăng vào chính nó. -C giúp lưu đường dẫn tương đối dễ khôi phục vào nơi khác. Đọc danh sách archive trước restore để xác định cấu trúc và phạm vi.
Checksum giúp đối chiếu nội dung archive trước/sau chuyển và phát hiện nhiều dạng hỏng dữ liệu. Nếu người tấn công sửa được cả archive lẫn checksum, nó không tự cung cấp tính xác thực. Dùng nơi lưu được kiểm soát, cơ chế xác minh phù hợp và mã hóa nếu dữ liệu nhạy cảm.
Một archive không được mã hóa không trở nên an toàn chỉ vì dùng đuôi .gz. Compression là nén dữ liệu, không phải encryption. Khi chuyển ra nơi lưu khác, kiểm tra policy của đơn vị và cách bảo vệ khóa giải mã; backup không phục hồi được vì mất khóa cũng là thất bại.
diff không có khác biệt nội dung chưa chứng minh owner, ACL và extended attributes đều đúng. Kiểm tra các thuộc tính ứng dụng cần và thử thao tác bằng đúng user dịch vụ. Trong lab cùng user, tar có thể khôi phục mode phù hợp; restore owner trên môi trường khác cần quyền và mapping UID/GID được xem xét.
Không giải nén một archive không tin cậy bằng root vào /. Trước hết kiểm tra nguồn, danh sách đường dẫn và phạm vi, rồi giải vào thư mục cách ly có quyền hạn chế. Bài này dùng archive do chính bạn tạo từ fixture đã biết.
Để chứng minh restore có tác dụng, đổi nội dung hoặc xóa đúng một file fixture sau backup, khôi phục từ archive vào restore-test và đối chiếu với nội dung kỳ vọng đã ghi nhận trước đó. Không cần làm hỏng dữ liệu nguồn production để chứng minh quy trình.
Sơ đồ chẩn đoán: kiểm tra theo từng lớp trước khi thay đổi cấu hình.
Chuyển bản sao ra khỏi máy nguồn
Khi đã kiểm tra local, chuyển archive cùng bản ghi checksum tới máy hoặc dịch vụ lưu trữ riêng có kiểm soát. Ví dụ rsync qua SSH cần user, host và đường dẫn đích thực tế; không đưa credential vào lệnh. Dùng key có phạm vi phù hợp thay vì chia sẻ key quản trị production cho tác vụ backup.
Kiểm tra dung lượng đích, quyền đọc và việc archive thực sự có mặt ở phía nhận. Thử lấy lại một bản từ nơi lưu đó vào môi trường khác, không chỉ mở bản local vẫn còn trên máy nguồn. Đây mới là phép thử gần với tình huống máy nguồn bị mất.
Quyền xóa bản sao và quyền ghi bản mới nên được thiết kế theo rủi ro ransomware hoặc tài khoản nguồn bị chiếm. Các cơ chế bất biến hay offline có thể hữu ích nhưng cần cấu hình và kiểm chứng riêng; không tự gọi một thư mục chỉ đọc trên cùng máy là backup bất biến.
Database và dữ liệu đang chạy cần quy trình riêng
Sao chép trực tiếp thư mục dữ liệu database đang chạy có thể tạo tập file không nhất quán. Dùng công cụ dump hoặc physical backup được database hỗ trợ, với cơ chế nhất quán phù hợp. Các ứng dụng gồm database và upload còn cần xác định cách ghép hai phần tại cùng mốc logic.
Nếu dừng service để backup, nêu rõ thời gian gián đoạn và kiểm tra ứng dụng sau khi khởi động lại. Snapshot storage không tự thay thế toàn bộ yêu cầu nhất quán ứng dụng. Khi chưa biết cách tạo bản nhất quán, ghi giới hạn và chuyển cho người phụ trách database.
Biên bản nghiệm thu một bản backup
Ghi nguồn, thời điểm, phạm vi, loại dữ liệu, công cụ, exit code, checksum, nơi lưu và kết quả restore. Đo thời gian phục hồi đủ cả bước đưa ứng dụng về hoạt động nếu mục tiêu là khôi phục dịch vụ. Không công bố nội dung dữ liệu hoặc đường dẫn có thông tin bí mật.
Hoàn thành khi lấy được bản sao từ nơi lưu độc lập, restore vào nơi riêng, nội dung và quyền cần thiết đúng, và chức năng liên quan dùng được. Lập lịch ở bài kế tiếp chỉ sau khi script chạy thủ công và restore thử đã qua kiểm tra.
