Nhờ ZFS, lượng dữ liệu mất chỉ khoảng 10 phút

 (mastodon.social)
3 điểm bởi GN⁺ 2023-08-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • SSD 2 năm tuổi đột ngột chết, nhưng nhờ sao chép gia tăng của ZFS, hệ thống được khôi phục trên ổ mới và lượng mất mát thực tế chỉ khoảng 10 phút
  • Kiến trúc là chụp snapshot toàn bộ filesystem mỗi 10 phút rồi gửi tới NAS; phần tự động hóa dùng zrepl
  • Snapshot lưu trạng thái tại một thời điểm của hệ thống đang chạy và chỉ truyền phần thay đổi, nên có thể sao chép nền ngay cả trên mạng gia đình
  • Quá trình khôi phục còn xa mới là tự động: phải chạy ZFS receive 625GiB qua đêm và khôi phục cả wrapper key mã hóa
  • ZFS có gánh nặng lớn khi triển khai ban đầu và bảo trì, nhưng đã cho thấy hiệu quả khôi phục thảm họa khi khôi phục được cả trạng thái làm việc sau sự cố ổ đĩa thực tế

Sau lỗi SSD, phần mất mát còn lại là 10 phút

  • Khi mở laptop để gửi email, màn hình đã đứng ở màu đen; sau khi khởi động lại, SSD 2 năm tuổi được xác nhận là đã chết
  • Sau khi khôi phục hệ thống lên ổ mới, máy có thể dùng lại, và tổng lượng dữ liệu mất chỉ khoảng 10 phút
  • Laptop được khôi phục đã boot vào đúng điểm đang bị gián đoạn, các tab trình duyệt cũng khôi phục công việc còn dang dở từ đêm trước
  • Ý tưởng tiếp tục trạng thái cũ trên thiết bị mới, giống quảng cáo Chromebook 12 năm trước, đã thực sự hoạt động trong sự cố lần này

Kiến trúc gần với sao chép hơn là backup

  • Thay vì chỉ backup ổ đĩa, tác giả dùng cách sao chép toàn bộ filesystem
  • Mùa đông vừa rồi, tác giả xây dựng hệ thống lưu trữ mạng gia đình để backup định kỳ các máy tính dùng cho công việc sáng tạo, và trong nhiều lựa chọn đã chọn sao chép gia tăng ZFS
  • ZFS có thể tạo snapshot tại một thời điểm một cách hiệu quả ngay cả trên hệ thống đang chạy
  • Khi gửi sang máy khác về sau, nó không truyền lặp lại toàn bộ dữ liệu mà chỉ truyền dữ liệu đã thay đổi

Gửi tới NAS mỗi 10 phút bằng zrepl

  • Việc tự động hóa tạo snapshot và truyền tới NAS dùng zrepl
  • Cấu hình là chụp snapshot toàn bộ filesystem mỗi 10 phút rồi truyền đi
  • Nhờ snapshot gia tăng, bản sao có thể được giữ cập nhật ngay cả khi chạy nền trên mạng gia đình
  • Lần chạy cuối mất 14 giây để truyền và gửi khoảng 64MiB

Gánh nặng thao tác thủ công lộ rõ trong quá trình khôi phục

  • Khôi phục hệ thống là một quá trình cần học hỏi và phụ thuộc đáng kể vào thao tác thủ công
  • Tác vụ ZFS receive 625GiB phải chạy qua đêm
  • Snapshot được mã hóa bởi máy tính nguồn nên NAS không thể đọc nội dung
  • Để thực sự dùng được bản backup, cũng phải khôi phục wrapper key mã hóa
  • Cho đến khi xác nhận lần đầu rằng có thể giải mã dữ liệu, quá trình khôi phục rất bất an

Chi phí triển khai và thay thế phần cứng

  • Thiết lập ban đầu của ZFS đòi hỏi thay toàn bộ filesystem nên chi phí khởi đầu cao
  • Việc duy trì cần nhiều kiến thức liên quan và đi kèm quy trình vận hành có thao tác thủ công
  • Dù vậy, việc đã thiết lập sao chép trước khi SSD hỏng lần đầu là may mắn, và trường hợp này cho thấy ưu điểm của ZFS
  • Ổ đã chết là WD_BLACK SN850 vốn đi kèm đơn hàng Framework ban đầu
    • Tác giả từng thấy trên diễn đàn Framework những trường hợp đáng lo về việc ổ này đột ngột chết hoặc không thể boot
  • Cùng ngày, tác giả nhận được SK Hynix P41 SSD và Sabrent NVMe enclosure từ Amazon sau khoảng 3 giờ

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-24
Ý kiến trên Hacker News

  • Vì đang dùng ZFS, có thể nói là đã chuẩn bị tốt hơn so với những người dùng SSD WD hay SanDisk khác
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Ngay trước khi rời hẳn thế giới Linux, tôi bắt đầu đào bới chút ít tảng băng trôi mang tên btrfs, và thấy khá thú vị
    Nó có vẻ rất tiềm năng ở nhiều tính năng như đổi mới sao lưu, cấu hình đĩa, v.v. btrfs không phải ZFS, nhưng có những phần chức năng chồng lấn, và cũng khá gần với “ZFS cho người nghèo”. Ngoài ra ZFS hơi lấn cấn về giấy phép, đóng gói và tình trạng được đưa vào kernel, nên trên một số hệ điều hành nhất định, btrfs vận hành hợp lý hơn nhiều
    Ở Linux User Group, khi tôi nói rằng tôi đã phải rút dây nguồn để khởi động lại máy tính, tôi từng bị mắng một trận vì hành động ngu ngốc đó và được khuyên dùng ZFS. Tuy nhiên nếu xét việc hệ thống đó là Raspberry Pi, có lẽ cách nhìn về việc hành động nào trong hai hành động ấy là khôn ngoan cũng có thể khác đi

    • Người ta nói Pi có thể bị hỏng filesystem, nhưng mỗi lần cài image tôi đều chạy script gắn tmpfs ở nhiều nơi và tắt phần lớn các log vô dụng, nên bản thân tôi chưa từng thấy
      Miễn là không hành hạ thẻ SD, các thiết bị kiểu này chạy liên tục rất ổn định. ZFS trông thật sự tuyệt, nhưng kể cả một ngày nào đó mua NAS, tôi nghĩ mình cũng không muốn bỏ tiền cho thiết bị có thể chạy ZFS, nên chắc sẽ dùng RAID và ext4
      Tôi vẫn tránh btrfs vì cứ vài tháng lại thấy bài “BTRFS làm mất dữ liệu của tôi”, rồi tranh cãi kéo dài xem đó có phải lỗi của btrfs không. Dạo này có vẻ ít thấy những bài như vậy hơn, nên có lẽ đã đến lúc xem lại
    • Hỏi vì tò mò: điều gì đã khiến bạn rời hẳn thế giới Linux? “Cộng đồng” có thể học được gì từ trải nghiệm đó để trở nên tốt hơn với người khác?
    • Điều duy nhất tôi thật sự không thích ở btrfs là nó dễ bị phân mảnh
      Đặc biệt là với image VM sparse, và tôi cho rằng zvol tốt hơn nhiều cho mục đích đó

  • Vài năm trước có khủng hoảng tụ điện, giờ không biết có phải chúng ta đang trải qua khủng hoảng thiết bị lưu trữ không
    Việc mọi thiết bị lưu trữ ngày càng tệ đi đang trở nên vô lý. WD thì đang phá hỏng HDD bằng SMR, còn các nhà sản xuất nói thời gian hoạt động 3 năm của SSD và HDD đã là quá dài, không phải đùa đâu. Chỉ riêng năm nay, một SSD Kingston đã chết; cái đó khoảng 8 năm tuổi thì còn chấp nhận được, nhưng cả HDD di động WD cũng chết sau khoảng 2 năm
    Internet ngày nay đầy rẫy chuyện mất dữ liệu và vấn đề tuổi thọ. 20 năm trước HDD cũng không phải thứ dùng mãi mãi, nhưng tôi nhớ ít nhất chúng chắc chắn trụ lâu hơn vòng đời hữu dụng của chiếc máy tính mua cùng

    • Ổ cứng ngày nay may mắn hơn nhiều so với 20 năm trước
      20 năm trước là thời của các ổ IBM Deathstar khét tiếng, khi lớp phủ từ tính theo nghĩa đen bong khỏi platter. Cũng có những ổ Maxtor kinh khủng chết sau 1–2 năm, và sau khi Seagate mua lại Maxtor, ổ Seagate cũng trở nên không ổn định một thời gian. Tôi vận hành một server gắn khoảng 8 đĩa và phải thay đều đều khoảng mỗi năm một cái
      Ngược lại, hiện tôi đang hỗ trợ quản lý một server ZFS có hơn 20 ổ, và tuổi thọ ổ vào khoảng 4–5 năm. Hơn nữa máy tính thời đó lỗi thời nhanh hơn nhiều. Bây giờ máy tính 6 năm tuổi vẫn đủ dùng, nhưng hồi đó máy 3 năm tuổi thôi đã thấy khác biệt rõ
    • Không cần lo. Chẳng bao lâu nữa cả chip sau vài năm cũng sẽ bắt đầu hoạt động sai
      Chúng ta đang chạm giới hạn mở rộng, và tăng trưởng theo hàm mũ đang chậm lại
    • Cá nhân tôi nhớ ngày xưa HDD của tôi và những người quanh tôi thỉnh thoảng cũng hỏng
      Giờ chuyện đó hầu như không xảy ra với SSD. Thậm chí một SSD Intel cũ từ cuối thập niên 2000, vốn nổi tiếng nhiều vấn đề, sau khi tôi dùng vài năm rồi đưa cho mẹ tôi, vẫn đang hoạt động bình thường trong cùng chiếc MacBook đời cũ đó. Tôi tò mò dữ liệu thực tế bên trong ra sao
    • Tất cả ổ WD tôi mua trong 10 năm qua đều hoạt động đúng như kỳ vọng. Kể cả ổ dành cho NAS mua sau khi SMR được đưa vào, vì tôi đã kiểm tra để chắc đó không chỉ là Red mà là Plus hoặc Pro
      Với SSD tôi cũng khá may, nhưng trên desktop tôi vẫn thường đặt thư mục /home và mảng RAID trên các ổ quay cũ, nên chỉ dùng SSD nhỏ
      Có hai ngoại lệ. Tôi đã tháo hai ổ WD Red đời trước SMR khỏi NAS cũ để thay bằng đĩa lớn hơn; chúng hoàn toàn bình thường, được cho vào túi chống tĩnh điện và cất trong ngăn kéo. Khoảng 2,5 năm sau cần đĩa dự phòng nên lấy ra kiểm tra thì cả hai đều không hoạt động; một cái chết hẳn, cái còn lại chỉ vừa được nhận diện nhưng không đọc được. Cái đầu tiên cắm vào không hiện lên gì cả; tôi đã lau mọi tiếp điểm, gồm cả các chân PCB điều khiển, nhưng vô ích nên cuối cùng phải bỏ. Cái thứ hai chỉ có thể tái sử dụng sau khi format lại toàn bộ, nhưng ngay cả dùng testdisk cũng không có cách nào khôi phục dữ liệu cũ. Tôi chưa từng trải qua hay dự đoán chuyện như vậy, nên thật lòng khá lo
    • Khoảng 20 năm trước cũng có HGST “Deathstar”, những ổ tệ đến mức bị kiện tập thể
      Đĩa luôn chết ngẫu nhiên, và đó cũng là một trong những lý do Sun tạo ra ZFS

  • Tóm rất ngắn gọn, luồng Mastodon đang trỏ tới https://zrepl.github.io
    “zrepl là một giải pháp tích hợp một điểm đến cho nhân bản ZFS”

    • Ngoài việc zrepl được viết bằng Go còn sanoid/syncoid là các script Perl, có ai biết zrepl và sanoid/syncoid khác nhau thế nào không?
    • Có vẻ như phải giao tiếp với một daemon chạy trên server lưu trữ
      Ví dụ nếu có thể dùng trực tiếp S3 làm kho lưu trữ thì sẽ rất tuyệt

  • Zrepl là một lý do lớn giúp tôi yên tâm sống kiểu du mục số
    Một script chạy khoảng mỗi đêm một lần sẽ mở một ZFS pool được bảo vệ bằng LUKS với header riêng, rồi sao chép tất cả snapshot. Vỏ NVME đó luôn nằm trong “túi” không rời khỏi người tôi
    Nhờ cấu hình này và NixOS, tôi có thể provision một laptop mới giống hệt trong khoảng 10 phút. Gần đây tôi còn thêm nhân bản offsite, nên ngay cả nếu bị cướp cực kỳ tệ thì khả năng mất dữ liệu nghiêm trọng gần như bằng 0
    Zrepl là phần mềm thật sự tuyệt vời. Dễ bắt đầu, nhưng tinh vi và mạnh mẽ đến mức khi cần có thể chạm vào mọi điểm tinh chỉnh. Tôi không thể khen đủ

    • Có vẻ bạn an toàn hơn nhiều so với đa số người khác, vốn chỉ cần một vụ trộm, hỏa hoạn, lũ lụt hoặc thảm họa nào đó là xong
    • Bạn đã từng dùng sanoid/syncoid chưa? So với chúng, Zrepl mang lại thêm điều gì?
    • Sẽ rất hay nếu bạn viết một bài về cách cấu hình này hoạt động. Nghe khá thú vị

  • Việc chụp snapshot mỗi 10 phút cho hệ thống tệp có thể đã ảnh hưởng đến cái chết của SSD không?

    • ZFS khá đặc biệt, và vì dùng copy-on-write, chi phí tạo snapshot thấp
      Theo trực giác thì dù chụp snapshot rất thường xuyên, lượng ghi bổ sung có vẻ cũng khá ít. Dù vậy nếu có đo đạc khoa học thì tốt hơn
      Trên một số máy chủ tôi từng quản lý trước đây, tôi dùng ZFS để chụp snapshot mỗi phút, mỗi giờ và mỗi ngày. Snapshot theo phút bị xóa sau 60 phút, còn các snapshot theo giờ và theo ngày được sao lưu bằng cron job trên một máy khác. Snapshot theo giờ được giữ khoảng 72 giờ, còn snapshot theo ngày được giữ vĩnh viễn. Snapshot theo phút nhằm để hoàn tác lỗi thủ công trong lúc migration SQL, và nó hoạt động tốt
      Hiện tôi vẫn dùng ZFS trên máy chủ FreeBSD, nhưng các dự án hiện tại có lưu lượng thấp và ít khi thay đổi dữ liệu quan trọng, nên trên máy chủ cá nhân tôi chỉ chụp snapshot thủ công khoảng mỗi tuần một lần và kích hoạt sao lưu thủ công từ máy chủ khác. Ngoài ra giờ tôi chỉ snapshot phần hệ thống tệp có cơ sở dữ liệu PostgreSQL và dữ liệu ứng dụng. Dữ liệu hệ điều hành thì tôi không còn quá bận tâm. Nếu xảy ra hỏng hóc phần cứng nghiêm trọng, tôi sẽ cài lại OS; các giá trị cấu hình quan trọng được ghi chép lại, và khi script sao lưu chạy thì nó sẽ sao chép các giá trị đó thay vì những thứ lặt vặt khác
    • Khả năng đó thấp
      Snapshot không ghi nhiều, và cả SSD lẫn ZFS đều là cơ chế copy-on-write. Tức là chi phí ghi sau snapshot giống như trước snapshot
      Tuy nhiên vẫn thiếu ngữ cảnh. Cả SSD lẫn ZFS đều không thích trạng thái đầy hoặc gần đầy. Nếu dữ liệu làm việc khoảng 650GB và ổ là 1TB, snapshot có thể dễ dàng đẩy mức sử dụng ổ vượt 90%. Chỉ riêng điều đó cũng có thể đã khiến ZFS khó chịu
    • Theo tôi hiểu, việc chụp snapshot trong ZFS là ghi một đối tượng metadata và một số tham chiếu dữ liệu
      Giả sử dữ liệu 100GB, kích thước block 128K và con trỏ 64-bit, dữ liệu mới được ghi trong lúc snapshot có lẽ vào khoảng 5MB. Nếu làm việc này 6 lần mỗi giờ, 52.560 lần mỗi năm, thì để xem có đủ gây mòn ổ sớm không, con số là khoảng 256GB mỗi năm. Khả năng cao là dưới 1% độ bền ghi của SSD. Vì vậy tôi sẽ ngạc nhiên nếu snapshot mỗi 10 phút là nguyên nhân quan trọng
      Tôi có thể sai, và ước tính này được đưa ra nhờ hỏi một nguồn không đáng tin cậy lắm. Rất hoan nghênh chỉnh sửa. Dù vậy, nếu ước tính của tôi còn cao hơn thực tế mà vẫn ít có khả năng ảnh hưởng đến tuổi thọ, thì bản thân luận điểm này có thể không có nhiều ý nghĩa
    • Khả năng thấp. Snapshot về cơ bản là đánh dấu các block được ghi gần đây nhất và ngăn các block cũ bị thay đổi
      ZFS là copy-on-write, nên khi thay đổi tệp vẫn phát sinh cùng lượng ghi, chỉ là một phần dữ liệu cũ không bị xóa
    • Theo một bình luận trên trang web màu cam ngẫu nhiên nào đó[1], kích thước ghi tối thiểu của chip flash hiện đại có thể vào khoảng 100MB
      Khi đó 5MB ghi mỗi 10 phút thực tế sẽ thành 600MB mỗi giờ, 4,8TB cho một ngày làm việc 8 giờ, 24TB cho tuần 40 giờ, và trên ổ 1TB thì tương đương 3,43 DWPD theo thời gian thực, hay 2500TBW trong 2 năm thời gian thực[2]
      Độ bền ghi chính thức của SN850 là 600TBW, nhưng vì vấn đề bảo hành nên dĩ nhiên nhiều khả năng đó là con số được hạ thấp một cách thận trọng. Trùng hợp là 2500TB cũng là mức độ bền phổ biến ở nhiều SSD trong thị trường này. Nhìn tổng thể thì nghe có vẻ không phải hoàn toàn bất khả thi
      Nếu ổ vẫn còn sống, tôi tò mò controller nói gì trong dữ liệu SMART. Trên Linux, chạy apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda sẽ in ra một bảng[4]. Trên Windows thì cài CrystalDiskInfo[3] là được
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - tính bằng terabyte
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail” có nghĩa là giá trị đó phải thay đổi ngay trước khi hỏng, còn “Old_age” nghĩa là giá trị biểu thị tuổi thọ; không có nghĩa là “cái này tệ và sắp hỏng” hay “ổ này đã cũ”. Pre-fail và Old_age luôn được hiển thị cho mọi mục. Tôi nghĩ lẽ ra từ lâu ai đó nên đổi chúng thành “somewhat_boolean” và “life_remain”

  • Tôi thường sao lưu gia tăng bằng Apple Time Machine lên một máy chủ Synology dùng ổ đĩa quay
    Khi làm việc rủi ro hoặc nâng cấp máy, tôi cũng mirror ổ nội bộ sang SSD gắn ngoài. Cách này hoạt động tốt. Khôi phục bằng Time Machine có thể khá chậm, nhưng phần lớn dữ liệu quan trọng của tôi nằm trong Git và các repository được host nên không phải vấn đề lớn. Thỉnh thoảng tôi dùng Time Machine khi muốn khôi phục một tệp riêng lẻ
    Tôi cũng có một ổ SanDisk khét tiếng[0], nhưng không dùng cho việc quan trọng. Nó chỉ chứa thư viện game. Là người dùng Mac nên game không phải yếu tố lớn, và nếu chúng chết thì tôi cũng sẽ không khóc
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Tôi cũng dùng Time Machine. Tôi tải ứng dụng https://tclementdev.com/timemachineeditor/ và thiết lập để kích hoạt thủ công sao lưu TM mỗi khi máy ở trạng thái rảnh
      Có vẻ nó hoạt động tốt hơn nhiều so với sao lưu tự động hoặc sao lưu theo thời gian của Apple
    • Tôi đã bỏ Time Machine. Trên Synology, dù dùng atalk và các thứ tương tự, nó hầu như chưa từng hoạt động ổn quá một hai tháng

  • Snapshot của tôi được mã hóa trên máy tính gốc. Điểm hay là NAS không thể đọc được
    Vì vậy để dùng bản sao lưu, tôi cũng phải khôi phục wrapper key mã hóa. Nói thật, cho đến khi có xác nhận đầu tiên rằng có thể giải mã dữ liệu, tôi đã khá sợ
    Không nên giả định rằng một phương thức sao lưu tùy chỉnh là hoạt động cho đến khi thực sự kiểm tra định kỳ rằng có thể khôi phục dữ liệu

    • Sao lưu không tùy chỉnh cũng vậy
    • Tôi vẫn luôn chỉ nghĩ rằng nên lưu một bản sao LUKS header trên một ổ đĩa riêng để phòng khi cần

  • Tương lai gần của Linux ở đây là bcachefs
    https://bcachefs.org/

    • bcachefs làm gì tốt hơn BTRFS hay ZFS?
    • Gọi là tương lai gần thì nó đã được phát triển 7 năm rồi và vẫn chưa được chấp nhận vào upstream
      Dù việc đưa vào upstream vẫn đang được tiến hành
    • Có bản tóm tắt ngắn gọn nào về lý do nên kỳ vọng không? Có tính năng thú vị nào không?

  • Câu “cho đến khi có xác nhận đầu tiên rằng có thể giải mã dữ liệu, tôi đã khá sợ” nghe như nghĩa là quy trình này chưa được kiểm thử và ghi chép tài liệu đầy đủ như mức tối ưu
    Với hệ thống gia đình hay máy desktop cá nhân thì chuyện này không quá hiếm. Nhưng trên server production thì chắc sẽ không muốn phải ứng biến tìm ra quy trình khôi phục ngay tại chỗ

    • Đúng vậy. Tôi biết mình có đủ các thành phần cần để khôi phục, và 6 tháng trước cũng đã thử một lần, nhưng lúc đầu tôi đã sao chép nhầm khóa
      Khi tải không thành công, tôi đã có một khoảnh khắc khá tuyệt vọng, nhưng rồi nhanh chóng nhận ra sai lầm. Trong những khoảnh khắc thất bại như vậy, các lỗ hổng của toàn bộ quy trình bỗng hiện ra rõ ràng đến chói mắt