Tự xây dựng hệ thống sao lưu của riêng mình – Phần 1: Chiến lược trước khi viết script

• Tầm quan trọng của sao lưu thường bị đánh giá thấp
• Nhiều người yên tâm với việc phụ thuộc vào đám mây mà không nhận thức được trách nhiệm bảo vệ dữ liệu thuộc về mình
• Nếu không lập kế hoạch sao lưu mà chỉ dựa vào sao chép đơn thuần, rủi ro sẽ rất cao
• Mỗi cách sao lưu toàn bộ đĩa hoặc từng tệp riêng lẻ đều có ưu và nhược điểm riêng
• Một bản sao lưu đáng tin cậy cần lấy snapshot và có lưu trữ bên ngoài làm yếu tố cốt lõi

---

Tầm quan trọng và thực tế của sao lưu

• Sao lưu là lĩnh vực mà nhiều người không xem trọng đúng mức
• Rất nhiều dữ liệu bị mất do cách làm sai hoặc hiểu lầm về khái niệm (ví dụ: RAID không phải là sao lưu)
• Dữ liệu là tài sản quan trọng và phải được lưu giữ bằng nhiều cách khác nhau

Những hiểu lầm về đám mây và sao lưu

• Nhiều người giao toàn bộ dữ liệu cho đám mây nhưng lại không hỏi dữ liệu thực sự được bảo vệ như thế nào
• Ngay cả các nhà cung cấp đám mây lớn cũng áp dụng mô hình trách nhiệm chia sẻ
  • Họ bảo vệ hạ tầng, nhưng trách nhiệm bảo vệ dữ liệu thuộc về người dùng
• Trong các môi trường như đám mây, máy chủ riêng, Kubernetes..., rủi ro do không có sao lưu vẫn xảy ra thường xuyên

Kinh nghiệm khôi phục dữ liệu của tác giả

• Tác giả đã trải qua nhiều trường hợp mất dữ liệu như cháy trung tâm dữ liệu, phòng máy bị ngập, động đất, ransomware, tấn công ác ý và lỗi của quản trị viên
• Với các máy chủ kết nối Internet (thương mại điện tử, email...), cả tính toàn vẹn dữ liệu lẫn tính liên tục dịch vụ đều quan trọng
• Sao lưu không phải chỉ là sao chép đơn thuần. Đặc biệt, việc sao chép tệp cơ sở dữ liệu đang hoạt động có thể khiến khả năng khôi phục thất bại tăng cao

Những câu hỏi bắt buộc khi xây dựng chiến lược sao lưu

• "Bạn chấp nhận rủi ro đến mức nào?", "Cần bảo vệ những dữ liệu nào?", "Nếu mất dữ liệu thì có thể chấp nhận downtime bao lâu?", "Có bao nhiêu dung lượng lưu trữ sẵn có?"
• Cách để bản sao lưu trên cùng một máy sẽ vô dụng nếu máy đó gặp sự cố. Sao lưu sang lưu trữ bên ngoài sẽ an toàn hơn
• Cũng cần cân nhắc các yếu tố thực tế như băng thông mạng, tốc độ khôi phục và dung lượng lưu trữ

Sao lưu toàn bộ đĩa vs sao lưu theo từng tệp

Sao lưu toàn bộ đĩa

• Ưu điểm
  • Có thể khôi phục hoàn chỉnh. Hệ thống có thể được phục hồi nhanh về trạng thái trước đó
  • Hữu ích khi kết hợp với hệ thống ảo hóa. Proxmox và các nền tảng tương tự hỗ trợ kiểu sao lưu toàn bộ này khá dễ dàng
  • Một số giải pháp còn hỗ trợ khôi phục từng tệp riêng lẻ từ bản sao lưu toàn bộ
• Nhược điểm
  • Với máy chủ vật lý, sẽ cần downtime
  • Tốn nhiều dung lượng, kể cả lưu cả dữ liệu không cần thiết
  • Tùy đặc tính hệ thống tệp, có thể chậm hoặc phát sinh vấn đề tương thích

Sao lưu theo từng tệp

• Ưu điểm
  • Có thể thực hiện bằng các tiện ích hệ thống cơ bản (tar, cp, rsync...)
  • Có thể chỉ sao lưu phần thay đổi, giúp giảm dung lượng và lưu lượng truyền
  • Linh hoạt cho khôi phục từng phần, di chuyển, nén và khử trùng lặp
  • Có thể vận hành mà không cần dừng hệ thống
• Nhược điểm
  • Sao chép đơn thuần sẽ cần nhiều dung lượng lưu trữ
  • Nếu sao lưu hệ thống tệp đang hoạt động mà không có snapshot, có thể phát sinh không nhất quán và lỗi

Sao lưu bằng snapshot

• Khi đối tượng sao lưu là hệ thống tệp đang hoạt động, dữ liệu có thể thay đổi giữa thời điểm bắt đầu và kết thúc sao lưu, làm mất tính nhất quán dữ liệu
• Các cơ sở dữ liệu đang mở như MySQL, lịch sử trình duyệt... có thể không khôi phục được nếu chỉ sao chép tệp
• Để đảm bảo bản sao lưu nhất quán, trước tiên cần tận dụng chức năng snapshot của hệ thống tệp
• Các cách tiêu biểu
  • Snapshot hệ thống tệp native (các hệ thống hỗ trợ BTRFS, ZFS)
  • LVM snapshot: có thể lãng phí dung lượng và có nguy cơ làm gián đoạn hệ thống khi xóa snapshot
  • DattoBD: đôi lúc có vấn đề về độ ổn định, nhưng có thể dùng kết hợp với UrBackup

Phương thức sao lưu: Push vs Pull

• Push: máy cần sao lưu kết nối tới máy chủ và gửi dữ liệu đi
• Pull: máy chủ sao lưu trung tâm kết nối tới từng máy để thực hiện sao lưu
• Về bảo mật, cách Pull an toàn hơn vì máy chủ sao lưu có thể chặn truy cập từ bên ngoài và chỉ truy cập client khi cần
  • Để ngăn dữ liệu sao lưu bị xóa khi có xâm nhập hoặc ransomware, snapshot của chính máy chủ sao lưu cũng nên được giữ riêng trong thời gian dài

Những đặc điểm chính của hệ thống sao lưu được khuyến nghị

• Khôi phục tức thì và xử lý tốc độ cao
• Lưu trên lưu trữ bên ngoài (tuy nhiên, snapshot cục bộ vẫn nên giữ để rollback ngay lập tức)
• Khuyến nghị không dùng đám mây thương mại như Google Drive, Dropbox. Dữ liệu nên do chính bạn nắm giữ
• Quản lý dung lượng hiệu quả bằng nén, khử trùng lặp
• Cần tối thiểu hóa các thành phần bổ sung cần thiết để hệ thống hoạt động

Kế hoạch cho loạt bài tiếp theo

• Tác giả dự định giới thiệu nhiều kịch bản sao lưu khác nhau, các máy chủ đang dùng thực tế, thiết lập chính và nhiều phần mềm, công nghệ liên quan
• Phần tiếp theo sẽ trình bày cách xây dựng máy chủ sao lưu dựa trên FreeBSD

[GN⁺]

Ý kiến Hacker News

• Với các máy bắt buộc phải sao lưu theo kiểu “push”, cần giới hạn để chúng chỉ có thể truy cập đúng không gian của mình; và quan trọng hơn là máy chủ backup phải tự giữ snapshot filesystem của chính nó trong một khoảng thời gian vì lý do bảo mật, để ngay cả trong kịch bản tệ nhất khi workload bị xâm phạm rồi truy cập được vào máy chủ backup và xóa backup nhằm đòi tiền chuộc, trên máy chủ vẫn còn snapshot; cách tôi thích là chỉ cho client ghi backup mới và hoàn toàn không được xóa, còn việc xóa thì xử lý bằng quy trình riêng (thủ công hoặc qua cron), kiểu này có thể triển khai trên rsync/ssh bằng tính năng allowed command trong .ssh/authorized_keys

  • Tôi dùng cả hai cách, vì dù sao cũng cần giữ backup ở hai nơi, và kiến trúc backup kép này vốn là điều tôi hướng tới: các nguồn backup sẽ push vào một điểm trung gian, rồi kho backup chính sẽ pull từ đó; điểm trung gian giữ snapshot nhưng chỉ có dung lượng nhỏ, còn storage chính và nguồn thì hoàn toàn không xác thực được với nhau, tức là mỗi bên chỉ xác thực được với điểm trung gian và không có xác thực theo chiều ngược lại; nếu một hoặc hai trong ba nơi này bị hack thì khả năng cao phần còn lại vẫn an toàn; backup chứng chỉ được xử lý hoàn toàn riêng để không bao giờ nằm hết trên máy chủ có kết nối Internet; dữ liệu thực sự quan trọng còn được backup offline thêm một lớp nữa; đúng là việc tách kiến trúc như vậy khiến kiểm tra backup thực tế hơi phiền, nhưng storage backup sẽ định kỳ kiểm tra checksum rồi gửi kết quả về host trung gian, so sánh với hash do host gốc tạo ra để phát hiện sự cố hỏng dữ liệu; với cấu hình này, tôi có một kiểu backup “offline mềm”, nơi nguồn không thể trực tiếp phá hoại chính snapshot backup

  • Một cách khác là dùng container riêng hoặc user chỉ dành cho backup; lấy systemd-nspawn làm ví dụ thì nó có thể dùng như một lightweight chroot jail, và bên trong có thể chặn luôn việc chạy rm; chỉ cần tạo chroot bằng pacman/pacstrap, rồi quản lý bằng systemd-nspawn/my machinectl; cách này cho phép nhiều kiểm soát rất linh hoạt mà vẫn gần như systemd bình thường: kiểm soát truy cập, giới hạn đường dẫn file, giới hạn bộ nhớ/CPU, chỉ cho phép truy cập từ một số dải IP nhất định, tinh chỉnh điều kiện khởi động, v.v.; cũng có thể tận dụng BTRFS subvolume, và nếu cần thì tách hẳn cả hệ thống bằng systemd-vmspawn; tự động hóa nhân bản bằng importctl cũng rất tiện

  • Tôi thích kiểu pull, nơi “máy chủ backup hoàn toàn không có bất kỳ quyền nào với máy chủ cần backup”; ngay cả khi máy chạy production bị chiếm quyền root thì hệ thống backup vẫn không bị ảnh hưởng

  • Tôi dùng rclone copy cho backup, chỉ dùng API key không có quyền xóa object; nếu đồng bộ kiểu rclone sync thì có thể xóa mất dữ liệu, nên cách này an toàn hơn

  • Tôi ước syncoid có tùy chọn kiểu “client chỉ được sao chép snapshot/backup, còn việc xóa do máy chủ backup tự quản lý”; hiện tại phải cấp quyền xóa nên khá tiếc

• Nhiều người coi nhẹ backup đến mức đáng kinh ngạc, từ công ty lớn đến nhỏ đều vậy; một công ty doanh thu 1 tỷ euro/năm mà tôi tư vấn còn không có backup nội bộ, chỉ dựa vào việc nhà cung cấp datacenter thỉnh thoảng copy đĩa một cách thất thường; họ cũng chưa bao giờ tự thử khôi phục; cách đây không lâu, do lỗi người dùng mà toàn bộ production DB bị xóa sạch, và bản backup mới nhất đã là từ 4 ngày trước nên phải tái hiện toàn bộ transaction trong khoảng đó; vậy mà dù xảy ra sự cố như thế, chẳng ai bị sốc cả, mọi chuyện vẫn trôi qua như bình thường

  • Có vẻ họ nghĩ miễn là chưa thật sự chí mạng với kinh doanh thì vẫn ổn

  • Tôi cũng thường thấy người ta làm cho yêu cầu backup trở nên quá phức tạp

  • Cũng có thể là do vấn đề pháp lý; vì kiện tụng hoặc nghĩa vụ lưu trữ pháp lý, bản thân backup đôi khi lại trở thành một yếu tố rủi ro

  • Đây là tác dụng phụ của các chính sách khôi phục thảm họa đạt kiểm toán soc2; công ty tôi từng làm cũng rà soát chính sách khôi phục thảm họa của mọi team (đều đã được soc2 phê duyệt), và cuối cùng đi đến kết luận rằng nếu có sự cố thật sự lớn thì đóng cửa công ty rồi về nhà còn nhanh hơn là phục hồi đúng nghĩa

  • Nếu chuyện mất toàn bộ 4 ngày dữ liệu production DB là thật, tôi muốn hỏi khách hàng đã không nổi giận sao; ở quy mô công ty đó thì thực tế có vẻ là đòn cực nặng, nên tôi rất tò mò họ đã xử lý thế nào

• Cảm ơn vì đã chia sẻ nội dung này; sau 10 năm phát triển phần mềm backup và khôi phục thảm họa, câu cửa miệng luôn xuất hiện là “đừng bao giờ bảo bạn bè tự xây giải pháp backup/DR”; việc xây BCDR đầy những cái bẫy rất dễ bỏ sót; tôi muốn chia sẻ vài điểm cốt lõi: backup không phải là “khôi phục thảm họa”; khi sự cố thực sự xảy ra thì phải phục hồi được ngay trong vài phút đến vài giờ mới giữ được niềm tin của doanh nghiệp; thời gian khôi phục (RTO) và điểm khôi phục (RPO) mới là mấu chốt; sao chép file kiểu rsync copy không phải backup theo thời điểm vì filesystem vẫn liên tục thay đổi; một backup theo thời điểm đúng nghĩa cần backup “crash-consistent” hoặc “application-consistent”, trong đó loại sau yêu cầu ứng dụng quan trọng ghi trạng thái xuống đĩa và tạm dừng trong lúc backup; các tính năng như Microsoft VSS xử lý phần này; tuyệt đối không được mù quáng tin vào rsync copy hay ngay cả backup crash-consistent; với thiết bị lưu trữ thì Murphy luôn đúng, nên nhất định phải có backup ở nhiều nơi (chiến lược 3-2-1); từ trải nghiệm thực tế của tôi thì loại đĩa nào rồi cũng hỏng, NVMe SSD > SSD > HDD về độ bền nhưng không có ngoại lệ; còn nhiều điều muốn viết nữa nhưng muộn rồi nên dừng ở đây

  • So sánh 3-2-1 là cách nói kiểu cũ; bây giờ vị trí lưu dữ liệu gần như không giới hạn, nên snapshot cục bộ, sao chép từ xa và backup kép, ba lớp theo các phương thức khác nhau còn quan trọng hơn; tôi dùng snapshot mặc định của zfs và thêm Borg, với tổ hợp đó thì gần như đủ cho mọi loại thảm họa

  • Câu cửa miệng đó làm tôi nhớ đến lúc nghe một câu tương tự trong buổi diễn của Alice in Chains; giải pháp BCDR là biểu tượng của niềm tin giữa các doanh nghiệp; những hệ thống kiểu này bảo vệ lượng dữ liệu trị giá hàng chục đến hàng trăm nghìn tỷ, và nếu là CTO thì bạn sẽ không bao giờ giao backup công ty cho một cách làm open source; chi tiêu IT của doanh nghiệp thường tăng dần theo giá trị tài sản và chiến lược chống vendor lock-in; theo kinh nghiệm chuyên môn của tôi, trong phòng chống ransomware thì immutability và backup WORM là then chốt, và tôi cũng từng thấy nhiều trường hợp IT chính phủ gặp rắc rối vì không tuân thủ quy định; các nhà cung cấp BCDR dùng ransomware như điểm bán hàng, nhưng tính bất biến thật sự được chứng minh ở việc sao chép dữ liệu qua nhiều không gian khác nhau; đó là lúc chiến lược 3-2-1 phát huy giá trị; tôi muốn nghe thêm ý kiến về các nguyên tắc backup khác

  • Nếu dùng NAS thì tốt nhất đừng dùng ổ cứng cùng hãng cùng model ở cả hai bên

  • Tôi hoàn toàn đồng ý với câu “nhất định phải có backup ở nhiều nơi (3-2-1)”, nhưng với đa số cá nhân thì “1” (offsite) gần như không khả thi, thành ra trừ khi dùng dịch vụ backup, nếu không cũng chẳng còn lý do gì để tự backup; quanh tôi không có ai ở ngoài thành phố sẵn sàng chạy máy tính 24/7 rồi quản lý giúp cả

  • Về ý “không bao giờ nên tin vào rsync copy hay ngay cả backup crash-consistent”, cuối cùng tôi đi tới kết luận rằng vì mọi hệ thống/dịch vụ đều có thể tái dựng bằng công cụ hạ tầng, nên chỉ cần backup tích cực DB và storage file/object là đủ; backup cả VM một cách phức tạp thật ra không có nhiều ý nghĩa

• Bài viết gọn gàng nhưng vẫn có điểm còn thiếu, đó là một hệ thống backup thực sự tốt phải có tốc độ khôi phục và quy trình khôi phục rõ ràng; tôi đã nhiều lần thấy trường hợp người ta yên tâm vì backup “vẫn ổn”, nhưng đến lúc phục hồi thì chỉ khôi phục được một phần hoặc mất nhiều ngày, gây thiệt hại rất lớn; công cụ restic cho phép backup snapshot khử trùng lặp ở mức file nên rất hữu ích khi không có filesystem hỗ trợ snapshot như ZFS; và khi dùng kiểu backup “push” thì ransomware có thể xóa luôn cả backup, nên đúng ra nên dùng kiểu “pull”; nếu vẫn là push, theo tôi nên dùng media chỉ đọc (Bluray chẳng hạn), hoặc ít nhất là có auto-snapshot/ZFS để có thể phục hồi theo thời điểm

  • Dù ransomware có thể xóa cả backup push, nếu giới hạn quyền trên server thật tốt thì cũng không thành vấn đề; Borg và Restic có thể bảo đảm append-only qua ssh, còn ở local thì tôi luân phiên ổ backup offline như lớp phòng thủ cuối cùng; cách làm thực tế xem tại đây

  • Tôi tò mò liệu với chế độ append-only của restic mà chỉ pruning định kỳ từ bên trong server thì có ổn không cần dùng pull hay không; tôi hiểu đây là cách chống ransomware mà restic chính thức khuyến nghị

  • “Tốc độ khôi phục” thực sự phụ thuộc rất nhiều vào yêu cầu; nếu backup ảnh gia đình mà mất 6 tháng để khôi phục thì với tôi cũng không sao

  • Thay vì media chỉ đọc, server push với quyền bị hạn chế cũng là một lựa chọn; ví dụ ssh chỉ cho phép scp, giới hạn trong môi trường chroot, và backup xoay vòng thư mục theo ngày thì ngay cả ransomware cũng không thể xóa dữ liệu cũ; quy trình backup của tôi cũng dùng một ssh server chỉ cho phép chroot+scp, và ngoài ra còn kết hợp cả media chỉ đọc

• Tôi không hẳn cần một hệ thống backup riêng, chỉ cần một cách tiêu chuẩn, hiệu quả để gom ảnh 25 năm của gia đình 4 người lại với nhau (điện thoại, máy ảnh, file tải xuống, file scan, v.v.) là đủ; đến giờ tôi vẫn chưa tìm được cách nào thật sự ưng ý

  • Tôi đang chạy Immich trên NAS, và mỗi ngày backup media cùng DB dump của Immich lên AWS S3 Deep Archive; Immich cũng cung cấp khá đầy đủ các tính năng kiểu Google Photos, còn ảnh/scan trên desktop thì chỉ cần thêm vào NAS là Immich tự nhập vào; nếu là người dùng HN thì việc set up này không khó

  • Tôi đùa hỏi “25 năm ảnh” có phải là một đơn vị dữ liệu kiểu Bắc Mỹ không, rồi chỉ ra rằng thực ra bạn chắc chắn cần một hệ thống backup; tôi chạy syncthing theo mesh trên gnu/linux/windows/android, snapshot archive định kỳ sang hai Debian VM rồi backup lớp hai bằng borgbackup; RPO là 24 giờ nhưng có thể giảm nữa nếu muốn; chỉ có điều thiết bị Apple chặn syncthing chạy nền nên không hợp với cấu hình này; trường hợp của tôi là 500GB ảnh, cộng thêm vài chục đến vài trăm GB tài liệu khác, nhưng nhờ backup dựa trên diff nên vẫn hiệu quả

  • File tải xuống, file scan nếu không thật sự quan trọng thì sớm muộn cũng là dữ liệu bỏ đi; điện thoại/máy ảnh thì sync bằng Nextcloud, chỉ cho backup chạy trong home network; sau đó NAS backup hằng ngày rồi kiểm tra tình trạng, và bước cuối là dùng cloud backup đáng tin cậy hoặc một ổ đĩa ở nhà khác; như vậy là hoàn thành cả backup lớp hai

  • Các giải pháp self-host như PhotoPrism hoặc Immich rất hữu ích cho việc loại bỏ ảnh trùng lặp và tìm kiếm/gắn thẻ; cloud backup có thể dùng Backblaze B2 + Cryptomator để có storage mã hóa và script upload tự làm, chi phí cỡ 1 đô/tháng mỗi TB

  • Tôi dùng syncthing; dù Android chính thức không được hỗ trợ, bản fork thì chạy tốt; ngoài ra tôi khuyên dùng ente.io hoặc self-host Immich để backup ảnh, còn tài liệu thì nên quản lý riêng bằng paperless ngx hay tương tự

• Dirvish là một wrapper nhẹ cho rsync rất đáng thử, có các tính năng tuyệt vời như xoay vòng, tăng dần, lưu giữ, script tiền/hậu xử lý, v.v.; nó đã cứu dữ liệu của tôi suốt hơn 20 năm; cũng rất hợp với các điểm mà bài viết nêu ra; trang chính thức của dirvish, trang chính thức của rsync

  • Tôi muốn biết so với rsync thì dirvish dễ hơn hay mạnh hơn ở điểm nào

• Tôi đã xử lý được cả lỗi phần cứng lẫn vấn đề bị trộm bằng một cách khá lười: lưu tạm trên desktop nội bộ, ổ đĩa ngoài trong nhà, và ổ đĩa ngoài offsite (đều là Samsung T7 Shield); dùng robocopy /MIR để nhân bản mỗi ngày sang vùng tạm hoặc sau khi làm việc xong, mỗi tuần backup sang ổ ngoài, và mỗi tháng đổi ổ ngoài offsite một lần

  • Ổ đĩa ngoài nhất định phải là ít nhất từ các lô khác nhau, hoặc tốt hơn là model khác nhau; nếu cùng model/cùng lô thì thường dễ chết cùng lúc hơn nhiều (đặc biệt khi đang chịu tải phục hồi rất nặng)

• Đúng lúc nên tôi chia sẻ cấu hình archlinux và chiến lược backup của mình; tôi cũng công khai script tự động hóa cấu hình/backup và lớp tự động hóa borg

  • Tôi dùng python+borg để tự động hóa snapshot của 51 block device trên SAN, backup 71 filesystem, rồi sync lên S3; việc khôi phục đã được thử thực tế ở offsite và boot VM thành công không vấn đề gì; tự động hóa hiện vẫn phức tạp và chưa hoàn thiện nên tốc độ khôi phục còn chậm, nhưng dựng được với chi phí rất rẻ; borg thực sự rất mạnh, ai cũng có thể thử làm kiểu này và xét tổng thể thì rất kinh tế

• Dữ liệu quý giá của tôi có chưa đến 100MiB, nên tôi chỉ backup các đường dẫn đã chọn bằng tar+nén+mã hóa hai lần mỗi tuần, giữ xoay vòng vài tháng, để cả trong và ngoài nhà; gần như không cần kiểm tra hay bảo trì gì nhiều; chỉ với một script sh vài dòng là tự động hóa ổn thỏa, một cấu hình đơn giản mà hợp lý

  • Nếu ngày mai tôi đột ngột qua đời, có lẽ nên tự hỏi dữ liệu nào thực sự đáng để gia đình và hậu thế phục hồi; có khi không cần hàng trăm nghìn file, chỉ vài ảnh, video và văn bản cốt lõi là đủ

  • Bình luận này khiến tôi thật sự suy nghĩ lại về việc dữ liệu nào mới là quý giá với mình; ảnh của tôi thì dù nén vẫn ít nhất vài GB, còn danh bạ hay thứ không quan trọng thì rất nhỏ; nhìn chung những thứ khác mất cũng được; có lẽ cần cất recovery key cẩn thận hơn, dù những tài khoản quan trọng nhất của tôi lại không có recovery key; riêng ảnh đã gần 2TB rồi (nỗi khổ của dân chụp ảnh vì sở thích)

• Điểm khó nhất của tính nhất quán trong backup là gần như không thể backup dữ liệu ứng dụng một cách nhất quán mà không làm dịch vụ downtime; với snapshot đĩa thì ở đúng khoảnh khắc đó rất dễ có dịch vụ đang ở trạng thái mid-write khi snapshot được chụp, nên lúc khôi phục có khả năng lớn là rơi vào trạng thái hỏng; DB dump giảm vấn đề này đáng kể, nhưng nhiều khi lại phải backup từ bên ngoài service nên vẫn có thể đang giữa chừng truy vấn; nếu ai có kinh nghiệm thực tế về phần này tôi rất muốn nghe

  • Nhìn chung DB khá vững ở khía cạnh này, nên kể cả chụp snapshot đĩa bất kỳ lúc nào thì tôi vẫn cho là đủ dùng cho mục đích backup; điều tôi lo là các tình huống đặc biệt như cache không có pin, nhưng các hệ thống kiểu đó giờ ít gặp trong cloud hiện đại nên không thành vấn đề lớn

  • Ngoài DB ra, chiến lược còn phụ thuộc vào việc có thêm trạng thái ứng dụng nào cần capture hay không (ví dụ có cần backup cả cache hay không); pg_dump/mysqldump thực sự cho phép tạo snapshot DB đang chạy một cách an toàn, nhưng hơi chậm và làm kích thước dump tăng lên; để tránh vấn đề này, với PostgreSQL lớn tôi từng dùng read-only replica riêng cho backup, tạm dừng replication rồi chạy backup, sau đó bật lại replication