Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống

Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống là chọn đúng đối tượng (file, database, cấu hình), chọn mô hình one-way hoặc replication có chủ, rồi tự động hóa bằng rsync/rclone, DB replica hoặc object storage trung tâm. Đồng bộ không có nghĩa copy mù hai chiều mọi thư mục – cần xử lý xung đột, mã hóa kênh và giám sát job thất bại.

Khi hệ thống mở rộng từ một VPS sang nhiều máy (web, worker, staging, region khác), dữ liệu dễ lệch: upload có trên A nhưng không có trên B, cấu hình khác nhau, database chỉ nằm một chỗ.

Bài viết hướng dẫn Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống: chọn mô hình, công cụ, bảo mật kênh, xử lý xung đột, checklist triển khai và lỗi hay gặp.

Phạm vi tập trung vận hành thực dụng cho team nhỏ và vừa. Cluster doanh nghiệp lớn (Kubernetes + shared SAN) chỉ nhắc ngắn để định vị.

Vì sao cần đồng bộ giữa nhiều VPS?

Load balancing web cần cùng mã nguồn và file upload. Worker riêng cần cùng cấu hình job và đôi khi cùng dữ liệu đầu vào.

Disaster recovery: máy phụ giữ bản gần realtime hoặc gần thời điểm để failover. Staging cần dữ liệu mẫu định kỳ từ production (đã che PII nếu cần).

Đa region: user gần region nào thì đọc dữ liệu cục bộ; ghi có thể về primary rồi replicate.

Không đồng bộ có kế hoạch dẫn tới “sửa trên máy này, quên máy kia” – sự cố khó debug hơn downtime phần cứng.

Thêm VPS mà chưa có sơ đồ data flow thường xảy ra khi team scale gấp. Hãy coi sync là hạng mục go-live giống DNS và SSL – không phải việc làm sau khi đã lệch dữ liệu.

Đồng bộ cũng phục vụ bàn giao: member mới nhìn sơ đồ primary/replica hiểu hệ thống nhanh hơn đọc từng máy một.

Đồng bộ cái gì? Phân loại dữ liệu

Bảng này là bước đầu của Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống: sai loại data thì sai tool.

Quy tắc vàng: chọn một nguồn sự thật (source of truth) cho mỗi loại. Hai máy cùng ghi một file không có cơ chế khóa sẽ sinh xung đột.

Ghi chú PII và dữ liệu thanh toán riêng. Loại này có thể cần đồng bộ ít node hơn, mã hóa mạnh hơn, và cấm đưa sang staging nguyên bản.

Các mô hình đồng bộ phổ biến

1. One-way: Primary → Secondary

Máy chính ghi; máy phụ chỉ nhận. Phù hợp backup nóng, read replica file, mirror tĩnh. Đơn giản, ít xung đột.

Dùng rsync/rclone theo cron hoặc inotify khi cần gần realtime. Secondary không cho app ghi vào thư mục đang sync ngược.

Đặt tên rõ trên inventory: `vps-web-primary`, `vps-web-mirror`. Tránh gọi cả hai là “web1/web2” mà không biết ai được ghi media.

2. Hub trung tâm (object storage / NFS có kiểm soát)

Mọi VPS đọc/ghi media qua S3-compatible hoặc storage chung. Các VPS app không giữ bản “thật” local, hoặc chỉ cache.

Giảm bài toán đồng bộ file giữa máy. Đổi lại phụ thuộc độ trễ và chi phí storage; cần quyền IAM chặt.

3. Database replication

Primary nhận ghi; replica phục vụ đọc hoặc standby. Công cụ native MySQL/Postgres hoặc managed nếu có.

Không đồng bộ bằng cách copy thư mục data khi DB đang chạy. Dùng replica đúng cách hoặc dump/restore có cửa sổ.

4. Event / queue

Thay vì sync cả ổ, phát sự kiện “user uploaded file X” để worker trên VPS khác kéo về. Phù hợp microservice nhẹ.

Phức tạp hơn cron rsync nhưng scale sạch khi số máy tăng.

5. Two-way sync (cân nhắc kỹ)

Syncthing hoặc sync hai chiều tiện cho thư mục làm việc team, rủi ro cao với production DB và upload có xung đột.

Chỉ dùng khi hiểu conflict resolution và không phải dữ liệu giao dịch nghiêm ngặt.

Nếu bắt buộc cộng tác file trên nhiều VPS, cân nhắc thư mục tách biệt “shared-work” không chứa database hay secret. Giới hạn phạm vi two-way giúp giảm bán kính thiệt hại khi conflict.

Công cụ thường dùng

• rsync over SSH: file one-way, incremental, phổ biến trên Linux.
• rclone: đồng bộ với S3/Backblaze/Drive; cũng sync VPS ↔ object storage.
• Syncthing: peer-to-peer, gần realtime; cần chặn expose public không kiểm soát.
• scp/sftp theo lịch: đơn giản nhưng kém tối ưu hơn rsync cho thư mục lớn.
• DB dump + transfer hoặc streaming replication: cho database.
• Ansible/Git: đồng bộ cấu hình có phiên bản, không phải “copy đè” mù.

Chọn tool team vận hành được lúc 2 giờ sáng. Tool “xịn” mà không ai debug được vẫn làm hệ thống lệch lâu.

Mọi job sync nên log và alert. Im lặng khi fail là nguyên nhân secondary “tưởng đã mới”.

Version control cho script sync giống version control app. Đổi flag rsync trên production không qua review dễ gây `–delete` sai chiều.

Giữ “dry-run” trong SOP: mọi thay đổi rule sync lớn chạy dry-run trước, dán log vào ticket, rồi mới bỏ dry-run.

Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống – quy trình 6 bước

• Bước 1: Liệt kê loại data và nguồn sự thật từng loại.
• Bước 2: Chọn mô hình (one-way, hub, DB replica, event).
• Bước 3: Thiết kế mạng: SSH key, WireGuard/VPN nội bộ, firewall chỉ mở giữa các VPS.
• Bước 4: Viết script/playbook; loại trừ cache, tmp, log thừa.
• Bước 5: Chạy PoC trên staging; đo thời gian, dung lượng, xung đột.
• Bước 6: Bật lịch + monitor; thử failover/restore giả định.

Đây là khung triển khai thực dụng trước khi copy production. PoC tránh phá dữ liệu thật bằng rule `–delete` sai chỗ.

Ghi runbook: lệnh sync tay, cách kiểm tra lệch, ai được phép chạy `–delete`.

Thêm bước rollback: nếu sync làm secondary hỏng, biết cách tách khỏi load balancer và khôi phục từ backup thay vì sync tiếp đè lên bản lỗi.

Bảo mật kênh đồng bộ

Ưu tiên SSH key hoặc VPN giữa các VPS trong hệ thống. Không mở rsync daemon public không auth.

Tách user sync với quyền tối thiểu trên thư mục cần thiết. Tránh root rsync toàn bộ `/`.

Mã hóa dữ liệu nhạy cảm at-rest trên secondary nếu secondary ít được cứng hóa bằng primary.

Khi VPS nằm nhiều region (ví dụ trên Dyvi.Cloud), traffic sync đi qua internet – VPN/SSH và rate limit giúp giảm rủi ro và bão băng thông.

Xoay key khi nhân sự nghỉ. Inventory máy nào còn trust key sync cũ.

Xử lý xung đột và tính nhất quán

One-way gần như không xung đột nếu secondary read-only. Two-way cần quy tắc: last-write-wins, hoặc từ chối ghi song song.

Database: một primary ghi. Multi-primary chỉ khi hiểu conflict và latency – không mặc định cho shop nhỏ.

File upload: nếu hai node cùng nhận upload, dùng tên file unique + storage trung tâm thay vì sync đè.

Đặt RPO cho sync: chấp nhận lệch tối đa bao nhiêu phút? Cron 5 phút khác realtime. Kỳ vọng sai tạo cảm giác “đồng bộ hỏng”.

Với đơn hàng: ưu tiên replication DB đúng hơn sync file. File hóa đơn/PDF có thể lệch vài phút; lệch bảng order lâu hơn RPO là sự cố nghiêm trọng.

Ghi SLA nội bộ theo loại data. Không dùng một chu kỳ cron cho mọi thứ chỉ vì tiện.

Giám sát và kiểm chứng đồng bộ

Theo dõi exit code job, thời gian chạy, dung lượng chuyển. Alert khi job fail 2 lần liên tiếp hoặc bản secondary già hơn ngưỡng RPO.

Định kỳ so sánh checksum mẫu (một số file/thư mục) hoặc đếm record DB primary vs replica.

Sau bảo trì lớn: chạy sync tay có log, xác nhận app trên secondary đọc đúng dữ liệu mới.

Dashboard đơn giản (uptime + last sync timestamp) đủ cho nhiều team trước khi dựng hệ quan sát phức tạp.

Tình huống mẫu

Hai VPS web + một DB

DB primary một máy (hoặc managed). File media qua object storage hoặc rsync từ node nhận upload tới node còn lại. Code deploy bằng CI lên cả hai.

Không rsync cả WordPress lẫn database files giữa hai web node khi MySQL đang chạy.

VPS app + VPS worker

Config và secret qua Git/secret store. Hàng đợi (Redis/Rabbit) chia việc. Artifact dùng chung registry. Sync file chỉ với dữ liệu worker thật sự cần local.

Production + staging

Dump ẩn danh định kỳ về staging. Không sync ngược staging lên production. Firewall chỉ cho phép chiều prod → staging nếu cần.

Đa region

Primary ghi gần nơi xử lý giao dịch; replica đọc vùng khác. File lớn ưu tiên CDN/object storage thay vì sync full giữa region liên tục.

Đo latency sync xuyên region. Có thể cần lịch ngoài giờ cao điểm để tránh nghẽn băng thông user-facing.

Khi thêm region thứ ba, cập nhật sơ đồ trước khi copy script cũ. Topology “hình sao” (mọi thứ về primary) thường dễ hiểu hơn lưới full-mesh khi team còn nhỏ.

Sai lầm phổ biến

• Rsync hai chiều thư mục upload đang ghi liên tục không khóa
• Dùng `–delete` trên nhầm chiều làm xóa dữ liệu gốc
• Copy raw files database đang online
• Sync cả log và cache làm đầy băng thông
• Không alert khi cron sync chết sau đổi timezone
• Mở port sync ra 0.0.0.0/0
• Coi secondary đã sync = đã test failover

Tránh các lỗi trên giúp đồng bộ trở thành lớp tin cậy, không phải nguồn mất dữ liệu.

Sau sự cố do sync: viết postmortem ngắn – chiều sync, flag đã dùng, dữ liệu bị ảnh hưởng, cách ngăn lần sau. Đây là phần ít làm nhưng giảm tái diễn mạnh.

Checklist vận hành hàng tuần

• Xem log sync / replication lag.
• Kiểm tra dung lượng disk hai đầu.
• Xác nhận backup offsite vẫn chạy song song sync.
• Review quyền SSH/VPN còn thừa không.
• Thử đọc một mẫu dữ liệu trên secondary.

Checklist ngắn duy trì Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống sau khi đã setup – phần nhiều sự cố đến từ bỏ quên giám sát.

Gắn sync vào cùng văn hóa bảo trì VPS: patch, backup, monitor. Ba việc này bổ trợ nhau.

Khi onboarding VPS mới vào cụm, checklist bắt buộc gồm: khóa SSH sync, thử dry-run, ghi inventory, bật alert – rồi mới nhận traffic.

Gợi ý với hạ tầng Dyvi.Cloud

Dyvi.Cloud (dyvi.cloud) cung cấp Cloud VPS nhiều khu vực theo thông tin công bố. Khi dựng vài máy trong một hệ thống, hãy lên sơ đồ sync trước khi đổ dữ liệu production.

Ví dụ: VPS VN nhận upload + DB primary; VPS khác làm worker/replica; object storage hoặc rsync có lịch cho media. Snapshot từng máy không thay replication có chủ đích.

Áp dụng quy trình 6 bước trên mọi cụm VPS mới. Máy thêm vào cluster mà chưa vào inventory sync sẽ sớm thành nguồn lệch cấu hình.

Kết hợp bài backup tự động: sync giảm downtime khi một node lỗi; backup offsite bảo vệ khi cả cụm hoặc logic xóa nhầm.

Khi nâng cấp OS từng VPS trong cụm: tạm dừng job sync hoặc chuyển read-only theo runbook, tránh nửa primary nửa secondary đang patch gây lệch khó hiểu.

Đặt lịch diễn tập failover quý một lần nếu secondary mang vai trò DR. Sync tốt trên giấy nhưng failover chưa thử vẫn là rủi ro.

Câu hỏi thường gặp

Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống với WordPress?

Tách DB (một primary), media nên object storage hoặc sync one-way thư mục uploads, code deploy đồng nhất bằng Git/CI. Tránh copy toàn bộ site hai chiều.

Nên dùng rsync hay Syncthing?

Rsync one-way phù hợp mirror/backup có lịch. Syncthing tiện gần realtime hai chiều nhưng cần kiểm soát conflict và bảo mật. Production nhiều team chọn rsync/hub storage.

Đồng bộ realtime có bắt buộc không?

Không. Phụ thuộc RPO. Nhiều hệ chấp nhận lệch vài phút. Realtime đắt hơn về độ phức tạp và băng thông.

Có thể chỉ dùng snapshot nhà cung cấp không?

Snapshot hữu ích rollback từng máy. Không thay đồng bộ logic giữa các role (web/worker/db) đang chạy song song.

Làm sao biết hai VPS đã khớp dữ liệu?

So timestamp job, replication lag, checksum mẫu, đếm file/record. Định nghĩa ngưỡng “khớp đủ dùng” theo RPO.

Windows VPS đồng bộ thế nào?

Có thể dùng công cụ tương đương (Robocopy theo lịch, client S3, DB backup). Vẫn cần nguồn sự thật và kênh mã hóa – nguyên tắc giống Linux.

Bao nhiêu VPS thì nên chuyển sang storage trung tâm?

Khi số node web > 2–3 và media lớn, hub object storage thường rẻ công vận hành hơn lưới rsync chằng chịt. PoC chi phí và latency trước khi đổi.

Kết luận

Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống bắt đầu bằng phân loại dữ liệu và chọn nguồn sự thật, rồi mới chọn rsync, replica hay object storage.

One-way và hub trung tâm ít rủi ro hơn two-way mù. Database cần replication đúng cách. Bảo mật kênh và alert job fail là bắt buộc.

Triển khai theo 6 bước, PoC staging, checklist tuần. Đồng bộ có giám sát mới đáng tin khi failover.

Trên Dyvi.Cloud hay hạ tầng khác, sơ đồ sync nên nằm cạnh sơ đồ mạng ngay từ lúc thêm VPS thứ hai.

Hệ thống nhiều máy bền vững khi dữ liệu chảy theo quy tắc rõ – không khi mỗi node là một “đảo” tự chỉnh tay.

Review sơ đồ sync mỗi khi thêm VPS hoặc đổi region – đó là thói quen giữ Cách đồng bộ dữ liệu giữa nhiều VPS trong cùng hệ thống luôn khớp thực tế vận hành.

Bắt đầu đồng bộ cụm VPS có kiểm soát

Vẽ nguồn sự thật từng loại data, chọn mô hình one-way hoặc replica, bật monitor. Dyvi.Cloud hỗ trợ Cloud VPS để bạn dựng các node trong cùng hệ thống với kế hoạch sync rõ.

Tham khảo thêm cách backup dữ liệu VPS tự động và VPS có cần bảo trì thường xuyên không.