NAS ZFS 71 TiB không hỏng ổ đĩa trong 10 năm
(louwrentius.com)- NAS ZFS 71 TiB được tạo từ 24 ổ HGST 4TB đã vận hành hơn 10 năm; bo mạch chủ và bộ nguồn đã được thay, nhưng đến nay chưa có ổ đĩa nào hỏng
- Trong 10 năm, tổng thời gian hoạt động tích lũy của ổ đĩa chỉ khoảng 6000 giờ; cách chỉ bật từ xa khi cần đã giúp giảm đáng kể chi phí điện
- Trên HN có ý kiến cho rằng xác suất để 24 ổ đĩa đều không hỏng trong 10 năm cao hơn tưởng tượng, nên khó khẳng định chắc chắn kết quả này là nhờ thường xuyên tắt nguồn
- ZFS đã import lại pool không vấn đề gì sau khi đổi hệ điều hành, và trong các lần chạy zpool scrub vài lần mỗi năm cũng chưa từng phát hiện lỗi checksum
- Tiếng ồn, mạng, UPS, sao lưu và kế hoạch thay thế đều được vận hành như những đánh đổi giữa điện năng, chi phí và mức chấp nhận rủi ro; cùng dung lượng đó trong tương lai cũng có thể đạt được bằng RAIDZ2 với 6–8 ổ đĩa
NAS ZFS 71 TiB trụ được hơn 10 năm
- NAS ZFS 71 TiB dạng 4U gồm 24 ổ 4TB vẫn đang được sử dụng liên tục hơn 10 năm
- Hệ thống hiện dùng bo mạch chủ thứ hai và bộ nguồn thứ hai
- Chưa từng có ổ đĩa nào hỏng
- Tổng thời gian hoạt động tích lũy của các ổ HGST 4TB là khoảng 6000 giờ, tương đương khoảng 250 ngày hoạt động trong 10 năm
Vận hành nguồn: chỉ bật khi cần
- NAS về cơ bản luôn tắt và chỉ được bật từ xa khi cần
- Quy trình bật nguồn như sau
- Dùng script bật ổ cắm điện IoT nhiều cổng
- Khi BMC (Baseboard Management Controller) khởi động xong, dùng IPMI để bật thân máy NAS
- Wake-on-LAN cũng có thể được dùng như một phương án thay thế
- Khi dùng xong, một script nhỏ sẽ tắt server, chờ vài giây rồi ngắt nguồn ở ổ cắm tường
- Nếu chỉ tắt server nhưng vẫn để bo mạch chủ và BMC có điện thì sẽ tiếp tục tiêu thụ khoảng 7W, nên cách này được tránh
- Vì các dịch vụ khác chạy trên Raspberry Pi 4 hoặc các server có điện chờ thấp hơn nhiều, nên không cần chạy chiếc NAS lớn liên tục
- Động lực chính là tiết kiệm tiền điện, đồng thời được cho là có vẻ tốt cho tuổi thọ ổ cứng
- Tuy nhiên, trên HN có ý kiến cho rằng xác suất để 24 ổ không hỏng trong 10 năm cao hơn dự kiến, nên khó kết luận chắc chắn kết quả này là nhờ cách vận hành ngắt nguồn
- NAS trước đó cũng vận hành khoảng 5 năm với 20 ổ Samsung Spinpoint F1 1TB mà không có ổ nào hỏng
Những linh kiện gặp vấn đề trước ổ đĩa
- Ổ đĩa vẫn ổn, nhưng bo mạch chủ đã phải thay vài năm trước
- Triệu chứng lỗi là không thể vào BIOS và thỉnh thoảng boot thất bại
- Đã thử các biện pháp cơ bản như tháo pin CMOS nhưng không giải quyết được
- Cùng mẫu bo mạch chủ đang được bán trên Ebay với giá hợp lý, nên việc thay thế không gặp vấn đề lớn
- Lý do cần cùng mẫu bo mạch là server sử dụng 4 khe PCIe
- Cấu hình gồm 3 HBA và 1 NIC 10Gbit
- Bộ nguồn phải chịu điều kiện tất cả ổ đĩa đồng thời spin-up khi boot, kéo khoảng 600W trong vài giây
- Bộ nguồn có công suất định mức 750W và theo nhớ lại thì rail 12V cũng có thể cấp đủ điện, nhưng đôi lúc vẫn bị ngắt khi boot
Vận hành ZFS và kết quả scrub
- ZFS đã hoạt động nhiều năm mà không gặp vấn đề
- Dù đã đổi hệ điều hành nhiều lần, sau khi cài OS mới vẫn không gặp vấn đề khi import lại pool cũ
- Nếu dựng một server lưu trữ mới, tác giả dự định sẽ dùng lại ZFS
- zpool scrub được chạy vài lần mỗi năm
- Mỗi lần scrub mất khoảng 20 giờ để hoàn tất
- Vì mức tiêu thụ điện trong khi scrub khá cao, tác giả chạy vào những ngày điện rẻ theo biểu giá điện động
- Cho đến nay, scrub chưa từng phát hiện lỗi checksum nào
- Tác giả cho rằng tổng cộng tất cả ổ đĩa đã đọc hơn 1 petabyte dữ liệu, nhưng chưa có tình huống nào ZFS phải can thiệp để phục hồi
Lỗi ổ đĩa và hỏng dữ liệu âm thầm
- Lỗi ổ đĩa chủ yếu được chia thành hai dạng
- Hỏng hoàn toàn, khi ổ đĩa không còn được phát hiện
- Lỗi đọc/ghi hoặc bad sector
- Dạng thứ ba là hỏng dữ liệu âm thầm được cho là rất hiếm
- Trường hợp ổ đĩa không tự biết rằng nó đã trả về dữ liệu bị hỏng
- Trường hợp kết nối SATA không phát hiện lỗi checksum
- Vì có nhiều lớp kiểm tra checksum ở mức thấp, rủi ro này được xem là rất nhỏ
- Hỏng dữ liệu âm thầm là một rủi ro có thật, nhưng được cho là vấn đề đáng lo hơn ở môi trường quy mô lớn như datacenter, thay vì môi trường gia đình
- ZFS đáng để học với người dùng quen Linux hoặc FreeBSD, và cũng không quá khó học
Điều khiển quạt để có NAS yên tĩnh
- NAS này khá yên tĩnh so với một NAS
- Khung máy có 3 quạt 12V chắc chắn để làm mát 24 khay ổ đĩa
- Khi chạy ở tốc độ mặc định thì rất ồn, nhưng ở RPM thấp lại khá yên tĩnh và cung cấp đủ luồng khí trong hầu hết tình huống
- Chỉ chạy tốc độ thấp thì nhiệt độ cuối cùng vẫn tăng lên trong lúc ổ đĩa đọc/ghi
- Bo mạch chủ Supermicro được dùng có thể điều khiển tất cả header quạt từ Linux
- Tác giả đã viết một script điều chỉnh tốc độ quạt theo nhiệt độ của ổ đĩa nóng nhất
- Tác giả hỏi trên một subreddit về toán học về thuật toán phù hợp để vừa yên tĩnh vừa làm mát ổ đĩa, và được đề xuất dùng bộ điều khiển PID
- Tác giả viết mã điều khiển PID bằng Python, lấy mã ví dụ rồi tinh chỉnh tham số
- Script này đã chạy tốt trong nhiều năm và giữ nhiệt độ ổ đĩa ở mức dưới 40°C
- Do luồng khí nền thấp, cũng cần thêm quạt để làm mát 4 card PCIe như HBA và card mạng
Thay đổi trong cấu hình mạng
- Ban đầu, hệ thống dùng bộ điều khiển mạng gigabit bốn cổng và network bonding
- Cấu hình này đạt tốc độ truyền khoảng 450MB/s giữa nhiều hệ thống
- Vì cần quá nhiều cáp UTP, sau đó tác giả chuyển sang card Infiniband giá rẻ
- Với cấu hình Infiniband, tốc độ giữa các hệ thống có thể đạt khoảng 700MB/s
- Khi quyết định quay lại từ Ubuntu sang Debian, card Infiniband không còn hoạt động nữa và tác giả không xử lý được nguyên nhân
- Sau đó tác giả mua card 10Gbit Ethernet đã qua sử dụng, và đến nay nó vẫn hoạt động không vấn đề gì
UPS, sao lưu và chấp nhận rủi ro
- Trong một thời gian, tác giả dùng một UPS lớn để tắt máy đúng cách khi mất điện
- Sau khi xác nhận UPS tiêu thụ thêm hơn 10W ngoài mức điện của server, tác giả đã loại bỏ nó
- Tác giả quyết định chấp nhận rủi ro mất hệ thống do sự cố điện
- Dữ liệu quan trọng nhất được sao lưu ba lần
- Nhiều dữ liệu lưu trên server được xem là không đủ quan trọng để sao lưu
- Với mất dữ liệu do hỏng ổ đĩa, tác giả dựa vào phần cứng thay thế và ZFS
- Nếu mức bảo vệ đó không đủ, tác giả đã vận hành 10 năm với điều kiện chấp nhận mất mát
Thế hệ tiếp theo cũng có thể dùng cấu hình nhỏ hơn
- Hiện không có kế hoạch lưu trữ riêng cho tương lai
- Lý do ban đầu dựng server này là vì thiếu dung lượng và không muốn tiếp tục chuyển dữ liệu qua lại; hiện vẫn còn đủ nhiều không gian
- Có sẵn bo mạch chủ, CPU, bộ nhớ và card HBA dự phòng, nên khả năng khôi phục hệ thống khi hỏng là cao
- Vì dung lượng ổ cứng đã tăng mạnh, một ngày nào đó có thể thay khung 24 bay bằng form factor nhỏ hơn
- Có thể tạo mức dung lượng dự phòng tương tự bằng 6–8 ổ cứng và RAIDZ2, tức mức dự phòng tương đương RAID 6
- Tác giả vẫn cho rằng lưu trữ còn đắt
- Một khả năng khác là hệ thống cuối cùng sẽ hỏng trong vài năm tới, không được thay thế, và thú vui lưu trữ sẽ kết thúc
1 bình luận
Ý kiến trên Hacker News
Thắc mắc liệu có chu kỳ thay ổ đĩa hay không
24 ổ nhiều khả năng là cùng mẫu và cùng lô, mức hao mòn cũng tương tự nhau, nên phần lớn có thể hỏng vào thời điểm gần nhau, và số còn lại cũng có thể hỏng theo do tải tăng trong quá trình tái tạo
Lưu trữ đáng tin cậy là chuyện khó
Tất nhiên cả hai hỏng cùng lúc, và tôi phải thức cả đêm để khôi phục
Đúng là quá may :D
Nhưng tôi không nghĩ hao mòn phần cứng lại nhất quán đến mức đó
Nó chạy ổn cho đến khi một ổ chết và trong lúc tái tạo thì ổ thứ hai chết theo
Dĩ nhiên đó không phải ZFS, không có scrub định kỳ, tỷ lệ hỏng ổ của thập niên 2000 có thể cũng khác, và anh ấy cũng không tắt nguồn khi không dùng
Điểm chính là lỗi hỏng có tương quan, hơn là nguyên nhân chính xác. Dĩ nhiên vẫn kèm lời cảnh báo quen thuộc: cỡ mẫu 1, một người ngẫu nhiên trên Internet
Phần “NAS này rất yên tĩnh so với một NAS” là vì quạt bán kính lớn có thể đẩy nhiều không khí ngay cả ở RPM thấp, và cũng tiết kiệm năng lượng hơn nhiều
Oxide Computer từng nói trong một bài thuyết trình vì sao họ dùng quạt 80mm: vì nó yên tĩnh, và quan trọng hơn là tiêu thụ ít điện
Nội dung là họ quan sát thấy ở các máy chủ khác, có thể tới 25% điện năng được dùng để chạy quạt, còn của họ chỉ khoảng 1%
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Nếu không tính quạt 40mm của nguồn Flex ATX gần như đã biến mất thì đúng là vậy, và 80mm bây giờ cũng khá hiếm. Thường thấy 120mm hoặc 140mm nhiều hơn
Tôi thực sự ghét tiếng ồn tần số cao của kiểu quạt DC nhỏ, RPM cao điển hình
Hy vọng họ cũng dùng cách nào đó “thông minh” khi điều khiển tốc độ quạt ;-)
Tôi hoàn toàn bị thuyết phục bởi ý tưởng di chuyển luồng khí lớn hơn ở tốc độ thấp hơn
Tôi hiểu là điều này khó với chassis 1U hoặc 2U
Nhưng vẫn hay. Chỉ riêng việc giảm tiếng ồn quạt đã đáng kinh ngạc, và khiến tôi tự hỏi vì sao trước đây không ai nghĩ tới một thứ trông đơn giản như vậy
Tôi từng nghe lời khuyên hoàn toàn ngược lại rằng nên để ổ đĩa quay liên tục để giảm hao mòn do các chu kỳ bật/tắt nguồn
Không biết nên tin gì, nhưng tôi thích việc để ZFS NAS bật để có thể chạy scrub định kỳ và kiểm tra dữ liệu
Để tham khảo, tôi đã chạy một hệ thống 4 ổ trong 10 năm và trong thời gian đó có 2 lần hỏng ổ, nhưng đó là WD Green chứ không phải loại enterprise
Bật/tắt ổ một hai lần mỗi ngày khác với spin-down sau mỗi 15 phút hoặc ít hơn
Ổ WD Green không được khuyến nghị dùng cho NAS. Trước đây chúng thường park đầu đọc/ghi sau mỗi vài giây; nếu ít truy cập dữ liệu thì không sao, nhưng trong máy chủ điều đó dẫn đến hao mòn liên tục và có thể gây hỏng sớm
Đầu đọc/ghi gần như không bị mòn khi đang lơ lửng trên platter. Khi tắt nguồn, đầu đọc hạ vật lý xuống một giá đỡ hoặc vùng đáp trên platter, và việc hạ cánh/cất cánh gây hao mòn lớn nhất cho đầu đọc
Trong trường hợp xấu nhất, do ma sát tĩnh, đầu đọc có thể bị giật rách ra trong lúc cất cánh
Vòng bi cũng bền hơn, còn nếu dừng quá lâu có thể bị kẹt. Động cơ ổ đĩa cũng vậy
Dòng điện khởi động khi bật nguồn, dù nhỏ đến đâu, cũng là ứng suất điện
Lý do tắt ổ cứng chỉ là để tiết kiệm điện, giảm tiếng ồn, hoặc vận chuyển
Khi đó có thể xảy ra spin-up và spin-down nhiều lần trong ngày, nên tôi thấy lập luận này hoàn toàn khó chấp nhận
Tuy nhiên tôi không có bằng chứng để củng cố điều đó
Nếu có, việc để ổ quay liên tục nhằm tránh cảnh đĩa bật/tắt mỗi vài phút có thể giúp cải thiện tuổi thọ
Nhưng nếu là homelab, rất có thể bạn đang tốn tiền điện nhiều hơn rất nhiều so với số tiền tiết kiệm được từ chi phí duy trì ổ đĩa
Tôi có vài ổ dung lượng lớn dùng cho media gia đình, và muốn bảo vệ chúng với mức tự tin cao hơn là chỉ “ổ chưa hỏng”
Thảo luận về hệ thống tệp có checksum thường xoay quanh ZFS và BTRFS, nhưng tôi tò mò không biết có ai đã dùng thử bcachefs chưa
Nó đã được upstream vào kernel Linux, và theo tôi biết là hỗ trợ checksum toàn bộ. Tác giả cũng có vẻ rất nghiêm túc với trách nhiệm của hệ thống tệp
Có ai ở đây đang dùng không?
https://bcachefs.org/
Mất khoảng 1 tuần thì toàn bộ RAID không mount được do vấn đề về journal. Cấu hình là 8 HDD, 2 SSD làm cache ghi, 2 NVMe làm cache đọc
Tác giả đã trả lời trên Reddit trong vòng một ngày, và tôi đã thử áp dụng bản sửa của anh ấy. Dù phải compile kernel Linux rồi boot bằng kernel đó, vấn đề vẫn không được giải quyết
Sau đó tiếc là không còn phản hồi, nên tôi đợi thêm vài ngày rồi xóa sạch và quay lại RAID mdadm bình thường
Dĩ nhiên những thứ quan trọng đều đã được backup, nhưng tôi đã mất một phần dữ liệu không quan trọng, và điều đó nhắc tôi nhớ lại rằng công nghệ tuyến đầu thì không ổn định
Tuy vậy, quá trình thiết lập và các tính năng rất tuyệt. Chỉ riêng việc có thể thêm đĩa và đánh dấu chúng làm cache đọc/ghi đã rất hay
Chắc chắn tôi sẽ thử lại sau khi nó trưởng thành thêm vài năm nữa
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
Tôi không muốn mạo hiểm với dữ liệu vận hành, nhưng nếu là homelab thì có thể ổn
Tuy nhiên bạn phải tự hỏi mình sẵn sàng bỏ bao nhiêu thời gian khi có gì đó trục trặc
Tôi cũng đã dùng ZFS hơn 15 năm và gặp đủ chuyện vì phần cứng tệ, nhưng trên phần cứng enterprise tốt thì nó chạy hoàn hảo
Tôi đang thử tổ hợp dùng SSD làm cache, đặt SSD khoảng 2TiB phía trước ổ cứng dung lượng lớn khoảng 8TiB
Tôi từng gặp vài vấn đề nhỏ với tổ hợp zsys + root ZFS nay đã thành legacy trên Ubuntu, nhưng đó là cấu hình phổ biến và đã được dùng rộng rãi nhiều năm nên dễ tìm hỗ trợ
Có lẽ tôi sẽ không dùng bcachefs cho đến khi nó có mức độ được chấp nhận và hỗ trợ cộng đồng tương tự
Tôi nghĩ môi trường mà ổ đĩa vận hành tạo ra khác biệt rất lớn về tuổi thọ
Môi trường nhà ở biến động nhiều hơn hẳn so với trung tâm dữ liệu hay văn phòng. Biến động nhiệt độ và độ ẩm cũng là thách thức lớn, nhưng điều làm tôi ngạc nhiên là chỉ một lượng bụi nhỏ cũng có tác động khá rõ rệt
Hồi lâu trước tôi chạy một mảng 8x500G trên một server Dell cũ ở tầng hầm. Tất cả ổ đĩa đều là Seagate mới, 7200RPM, có thể là phiên bản “enterprise”
Trong 5 năm, trung bình cứ 6 tháng lại hỏng một ổ. Tôi dùng 2 ổ parity, giữ ổ dự phòng, và mỗi lần hỏng thì gửi RMA
Sau khi chuyển nhà, tôi có một phòng riêng cho lab, và với cùng cấu hình đó, 5 năm tiếp theo không hỏng ổ nào. Tôi đã dự đoán môi trường mới sẽ tốt hơn, nhưng thật bất ngờ khi môi trường sạch hơn và ổn định hơn lại cải thiện nhiều đến vậy
Tôi vẫn luôn đặt NAS/file server trong môi trường nhà ở nhiều bụi, đến giờ còn thấy logo Synology màu xám phủ lông tơ, nhưng chưa từng gặp chuyện như vậy
Tôi nghĩ thế hệ đó có vấn đề firmware
Xem tỷ lệ hỏng hằng năm ở đây: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
Với các ổ đĩa bơm helium được niêm kín hiện nay, ngay cả nếu trước đây đó từng là vấn đề thì giờ có lẽ cũng không còn là vấn đề lớn
Liên quan đến phần “chấp nhận rủi ro mất hệ thống do sự cố nguồn điện”, còn có một dạng hỏng hóc rất hiếm khác mà UPS giúp ngăn chặn là mất cân bằng điện
Nếu có vấn đề về điện trong lúc thi công gần đó, hoặc sét đánh vào cột điện gần nhà, có thể xuất hiện các spike theo cả hai chiều lên/xuống, và cả hai đều có thể phá hoại
Khoảng 10 năm trước ở công việc đầu tiên, nhiều máy chủ đã chết theo kiểu đó. Tuy nhiên đó cũng là lần duy nhất tôi nghe về vấn đề như vậy
Theo tôi hiểu, UPS cũng chặn được những spike như thế, và UPS sẽ chết trước khi máy chủ bị hỏng
Sét đánh thẳng vào ăng-ten TV ở nhà bố mẹ tôi, và cáp đồng trục nối tới bộ khuếch đại/bộ chia trong tủ viễn thông
Sau đó không hiểu bằng cách nào nó nhảy sang patch panel mạng gần đó, đốt cháy mọi bộ điều khiển Ethernet có dây gắn vào mạng. Bao gồm cả các cổng switch và những bộ điều khiển tích hợp trong AP
Trong switch mạng, có vẻ dòng điện cố đi xuống đất nên phá luôn cả bộ nguồn
Đến giờ việc nó nhảy từ cáp đồng trục sang Cat5 như thế nào vẫn hơi bí ẩn. Có thể thợ điện đã đi song song hai đoạn cáp khá gần nhau ở đâu đó
Phải làm lại toàn bộ mạng, nhưng may là lúc đó tại hiện trường không có máy tính nối dây. Thiết bị lưu trữ chắc cũng khó mà sống sót
Con APC 850VA giá 99 USD mua ở Office Depot thì không làm vậy. Nó chỉ chuyển từ điện lưới sang pin rất nhanh, chứ không thật sự làm sạch nguồn điện
Nếu có thể mua loại tốt, về lâu dài nó thực sự tăng độ tin cậy phần cứng. Nguồn điện sạch là điều tốt
Nhìn vào phân bố thiết bị chết, thiết bị hư hại và thiết bị nhìn bề ngoài vẫn ổn, dây đồng mang VDSL rõ ràng là tuyến đi rất trực tiếp. Modem được nối Ethernet tới mọi thiết bị khác
Cách giải quyết đúng có lẽ là chuyển sang quang, cho đi qua một đoạn cáp quang ngắn rồi chuyển lại. Điện nhiều khả năng sẽ chọn đường khác thay vì đi qua thủy tinh
Nhưng việc chọn sản phẩm phiền hơn tôi tưởng rất nhiều; vì không phải dân mạng, tôi thử phân biệt sản phẩm khoảng một giờ rồi bỏ cuộc
Vì vậy tôi đặt một Wi‑Fi bridge giữa modem VDSL và phần thiết bị còn lại. Hy vọng trong cơn bão tiếp theo, kiểu hỏng đó sẽ được cô lập
Có một mảng ZFS nối với cùng modem đó và nó vẫn sống sót, nhưng tôi nghĩ là do may mắn
Khi đó không có máy chủ, nhưng bóng LED cứ hỏng vài tuần một lần rất khó chịu. Đó là tòa nhà cũ từ thập niên 60, và hệ thống điện trong căn hộ của chúng tôi cũng có vài chỗ sửa tạm đáng ngờ
“Bí quyết” không phải là tắt nguồn, mà chỉ là may mắn
Tôi đang chạy các ổ HGST 4TB hơn 10 năm 24/7. Không phải đúng 24 ổ mà là 8 ổ, nhưng hỏng 0 ổ
Tôi cũng chỉ may mắn thôi, và tôi có những người quen đã RMA cùng loại ổ nhiều lần
Điều tôi tò mò nhất là dữ liệu gì mà cần tới 71TB trong khi phần lớn thời gian có thể tắt đi. Máy chủ lưu trữ backup à?
Ví dụ, vòng bi có thể bị kẹt khi nguội
Có lẽ ai đó hiểu thống kê đúng cách có thể tính xác suất để cả 24 ổ đều sống sót nếu giả định tỷ lệ hỏng hằng năm khoảng 1%
Hơn nữa, 20 ổ trong NAS trước đó cũng không hỏng. Vậy N=44, cần may mắn đến mức nào?
Tôi dùng trong gia đình; khi cần dữ liệu, thường tôi sao chép qua 10Gbit sang một hệ thống tiêu thụ điện thấp hơn nhiều rồi tắt NAS này lại
Có những ổ đĩa mà power cycle từng là rủi ro
Vì vậy tôi đồng ý với mô hình này, nhưng không nên giả định rằng đây luôn là cách tốt cho mọi người. Một số SSD cần được cấp điện định kỳ
Với chu kỳ sử dụng của NAS thì có lẽ yêu cầu đó sẽ được đáp ứng
Có lẽ ổn, và tiền điện chắc chắn rẻ hơn. Những ổ có thêm mỡ bôi trơn ở trục từng là một trường hợp đặc biệt của một thời
Tôi tò mò liệu Backblaze có mô hình thống kê về bật/tắt ổ đĩa và tuổi thọ không. Có lẽ họ nằm trong không gian vấn đề luôn bật
Nhưng trong trường hợp của tôi, tôi không power cycle các ổ này thường xuyên. Nhiều lắm là vài lần mỗi tháng
Tôi không thể nói hay chứng minh rằng đó không phải rủi ro lớn, nhưng tôi tin là không và đã chấp nhận rủi ro đó hơn 15 năm
Cũng cần nhớ rằng ổ cứng có tùy chọn spin down khi nhàn rỗi. Tức là ổ cứng có thể chịu nhiều lần spin up trong một ngày
Họ dùng ổ cứng 3.5 inch gắn trong và dock USB để backup vài thiết bị Synology; mỗi khi cắm lại ổ vào dock để khôi phục file hoặc backup bổ sung, cảm giác khoảng 1 trong 10 lần là ổ không bật nguồn lại
Trong môi trường vận hành, tôi đã dùng cơ sở dữ liệu PostgreSQL nhiều TB trên ZFS suốt vài năm, và đến nay chưa gặp bất kỳ vấn đề nào, kể cả bit flip
Tôi đã ghi lại trải nghiệm ở đây cho ai quan tâm:
https://lackofimagination.org/2022/04/our-experience-with-po...
Về việc thỉnh thoảng mất nguồn trong lúc khởi động, cần xem xét rằng ổ đĩa lấy điện từ đường 5V khi khởi động
Các ổ tương tự thường tiêu thụ tối đa 1,2A. Kết hợp với việc tải tối đa của đường 5V là 25A (Seasonic Platinum 860W), khả năng cao sẽ xảy ra lỗi nguồn khi khởi động nếu không dùng staggered spinup