10 साल तक बिना drive failure वाला 71 TiB ZFS NAS
(louwrentius.com)- 24 4TB HGST ड्राइव्स से बना 71 TiB ZFS NAS 10 साल से ज़्यादा समय तक चलाया गया, और motherboard व power supply बदले गए, लेकिन अभी तक किसी drive में failure नहीं हुआ
- 10 साल में ड्राइव्स का कुल runtime लगभग 6000 घंटे ही रहा, और केवल ज़रूरत पड़ने पर remote से power on करने की वजह से बिजली की लागत काफी कम रही
- HN पर यह राय आई कि 24 ड्राइव्स का 10 साल तक बिना failure के चलना, सोच से ज़्यादा संभव है, इसलिए इसे बार-बार power off रखने का सीधा असर मानना मुश्किल है
- ZFS ने operating system बदलने के बाद भी pool को बिना समस्या फिर से import किया, और साल में कुछ बार चलाए गए zpool scrub में एक भी checksum error नहीं मिली
- noise, network, UPS, backup और replacement plan — सब कुछ power, cost और risk tolerance के बीच समझौते के साथ चलाया गया, और भविष्य में यही capacity सिर्फ 6–8 ड्राइव्स के RAIDZ2 से भी संभव है
10 साल से ज़्यादा चला 71 TiB ZFS NAS
- 24 4TB ड्राइव्स से बना 4U 71 TiB ZFS NAS 10 साल से ज़्यादा समय से लगातार उपयोग में है
- मौजूदा system अब दूसरे motherboard और दूसरे power supply पर चल रहा है
- अभी तक एक भी drive failure नहीं हुआ
- 4TB HGST ड्राइव्स का cumulative runtime लगभग 6000 घंटे है, जो 10 साल में करीब 250 दिन के uptime के बराबर है
ज़रूरत पड़ने पर ही चालू करने वाला power setup
- NAS सामान्यतः बंद रहता है और सिर्फ ज़रूरत होने पर remote से चालू किया जाता है
- power-on flow इस प्रकार है
- script से IoT power strip को चालू किया जाता है
- BMC(Baseboard Management Controller) boot पूरा होने पर IPMI से NAS को चालू किया जाता है
- विकल्प के तौर पर Wake-on-LAN भी इस्तेमाल किया जा सकता था
- उपयोग खत्म होने पर एक छोटी script से server बंद किया जाता है, फिर कुछ सेकंड बाद दीवार की बिजली भी बंद कर दी जाती है
- अगर सिर्फ server बंद किया जाए और motherboard व BMC को power मिलती रहे, तो लगभग 7W लगातार खर्च होते, इसलिए इस तरीके से बचा गया
- बाकी services Raspberry Pi 4 या बहुत कम idle power वाले servers पर चलती थीं, इसलिए बड़े NAS को 24x7 चालू रखने की ज़रूरत नहीं थी
- मुख्य प्रेरणा बिजली का बिल कम करना थी, और यह भी लगा कि इससे hard drive की उम्र पर अच्छा असर पड़ेगा
- हालांकि HN पर यह राय आई कि 24 ड्राइव्स का 10 साल तक बिना failure के चलना अपेक्षा से ज़्यादा संभव है, इसलिए इस नतीजे को power-cut operation की वजह मानना आसान नहीं है
- पिछला NAS भी 20 1TB Samsung Spinpoint F1 ड्राइव्स के साथ लगभग 5 साल चला था और उसमें भी कोई drive failure नहीं हुआ था
ड्राइव्स से पहले खराब हुए दूसरे parts
- ड्राइव्स ठीक थीं, लेकिन कुछ साल पहले motherboard बदलना पड़ा
- खराबी का लक्षण यह था कि BIOS में जाना संभव नहीं था और कभी-कभी boot भी fail हो जाता था
- CMOS battery हटाने जैसे basic steps आज़माए गए, लेकिन समस्या हल नहीं हुई
- वही motherboard Ebay पर ठीक दाम में मिल गया, इसलिए बिना बड़ी परेशानी के replacement हो गया
- वही board इसलिए चाहिए था क्योंकि server में 4 PCIe slots उपयोग हो रहे थे
- setup में 3 HBA और 1 10Gbit NIC था
- power supply को boot के समय ऐसी स्थिति झेलनी पड़ती थी जहाँ सभी ड्राइव्स एक साथ spin-up होती थीं और कुछ सेकंड के लिए लगभग 600W खींचती थीं
- power supply 750W rated थी और याद के मुताबिक 12V rail भी पर्याप्त power दे सकती थी, फिर भी boot के समय कभी-कभी trip हो जाती थी
ZFS operation और scrub results
- ZFS कई सालों तक बिना समस्या काम करता रहा
- operating system कई बार बदला गया, लेकिन नया OS install करने के बाद पुराना pool दोबारा import करने में कोई दिक्कत नहीं हुई
- अगर नया storage server बनाना पड़े, तो फिर से ZFS इस्तेमाल करने का इरादा है
- zpool scrub साल में कुछ बार चलाया जाता है
- एक scrub पूरा होने में लगभग 20 घंटे लगते हैं
- scrub के दौरान power usage बढ़ जाता है, इसलिए dynamic electricity pricing में सस्ती बिजली वाले दिन इसे चलाया जाता है
- अब तक किसी scrub में checksum error नहीं मिली
- लगता है कि सभी ड्राइव्स मिलाकर 1 petabyte से ज़्यादा data पढ़ा जा चुका होगा, लेकिन ऐसी कोई स्थिति नहीं आई जहाँ ZFS को recovery में दखल देना पड़ा हो
drive errors और silent data corruption
- drive failures आम तौर पर दो तरह के होते हैं
- पूर्ण failure, जहाँ drive बिल्कुल detect ही नहीं होती
- read/write failure या bad sectors
- तीसरी श्रेणी silent data corruption को बहुत दुर्लभ माना गया है
- जब disk खराब data भेज दे और उसे खुद पता भी न हो
- जब SATA connection checksum error को detect न कर पाए
- low-level checksum checks की संख्या ज़्यादा होने के कारण इस risk को बहुत छोटा माना गया है
- silent data corruption वास्तविक risk है, लेकिन इसे home environment की तुलना में data center जैसे बड़े scale वाले माहौल में ज़्यादा चिंता का विषय माना गया है
- ZFS, Linux या FreeBSD से परिचित users के लिए सीखने लायक है, और इसे सीखना बहुत मुश्किल भी नहीं है
शांत NAS के लिए fan control
- यह NAS, NAS के हिसाब से काफी शांत है
- chassis में 24 drive bays को ठंडा रखने के लिए मज़बूत 3 12V fans लगे हैं
- default speed पर ये बहुत शोर करते हैं, लेकिन कम RPM पर काफ़ी शांत रहते हैं और ज़्यादातर स्थितियों में पर्याप्त airflow देते हैं
- सिर्फ कम speed पर चलाने से read/write के दौरान drive temperatures आखिरकार बढ़ जाती थीं
- इस्तेमाल किए गए Supermicro motherboard में Linux से सभी fan headers को control किया जा सकता था
- सबसे गर्म drive के तापमान के आधार पर fan speed नियंत्रित करने के लिए एक script बनाई गई
- एक math subreddit पर शांत रहते हुए drives को ठंडा रखने वाले algorithm के बारे में पूछा गया और PID controller की सिफारिश मिली
- Python में PID control code लिखा गया और example code लेकर parameters tune किए गए
- यह script कई सालों तक अच्छी तरह चलती रही और drive temperature को 40°C से नीचे बनाए रखती थी
- कम base airflow की वजह से HBA और network card जैसी 4 PCIe cards को ठंडा रखने के लिए अतिरिक्त fan भी चाहिए था
network setup में बदलाव
- शुरुआत में quad-port gigabit network controller और network bonding इस्तेमाल किया गया था
- इस setup से कई systems के बीच लगभग 450MB/s transfer speed मिलती थी
- बहुत ज़्यादा UTP cables की ज़रूरत पड़ने लगी, इसलिए बाद में सस्ते Infiniband cards पर switch किया गया
- Infiniband setup में systems के बीच लगभग 700MB/s तक पहुँचना संभव था
- Ubuntu से Debian पर वापस जाने के दौरान Infiniband cards ने काम करना बंद कर दिया और कारण हल नहीं हो पाया
- इसके बाद इस्तेमाल किए हुए 10Gbit Ethernet cards खरीदे गए, और वे अब तक बिना समस्या के चल रहे हैं
UPS, backup और risk tolerance
- कुछ समय तक power outage पर safe shutdown के लिए बड़ा UPS इस्तेमाल किया गया
- बाद में पता चला कि UPS server के power usage के अलावा 10W से ज़्यादा extra भी खर्च करता है, इसलिए उसे हटा दिया गया
- power-related issue से system खोने का risk स्वीकार कर लिया गया
- सबसे महत्वपूर्ण data का तीन बार backup लिया जाता है
- server पर रखा गया बहुत-सा data इतना महत्वपूर्ण नहीं माना गया कि उसका backup लिया जाए
- drive failure से data loss का जोखिम replacement hardware और ZFS पर छोड़ा गया
- और अगर वह protection पर्याप्त न हो, तो loss स्वीकार करने की शर्त पर यह setup 10 साल तक चलाया गया
अगली पीढ़ी: छोटे setup से भी संभव
- फिलहाल अलग से कोई future storage plan नहीं है
- यह server मूल रूप से इसलिए बनाया गया था ताकि storage कम पड़ने पर बार-बार data migrate न करना पड़े, और अभी भी काफी space बची हुई है
- spare motherboard, CPU, memory और HBA cards उपलब्ध हैं, इसलिए failure होने पर भी system को revive करने की संभावना काफ़ी है
- hard drive capacities बहुत बढ़ चुकी हैं, इसलिए कभी न कभी 24-bay chassis को छोटे form factor से बदला जा सकता है
- इसी स्तर की redundant storage अब सिर्फ 6–8 hard drives और RAIDZ2, यानी RAID 6 जैसी redundancy, से बनाई जा सकती है
- storage अब भी महँगा माना जाता है
- एक और संभावना यह है कि आने वाले कुछ सालों में system आखिरकार fail हो जाए, और उसे replace न किया जाए, जिससे storage hobby यहीं खत्म हो जाए
1 टिप्पणियां
Hacker News की राय
उत्सुकता है कि क्या कोई ड्राइव बदलने का चक्र है
24 ड्राइव शायद एक ही मॉडल और एक ही batch की होंगी, और उनका wear भी समान होगा; ऐसे में ज़्यादातर ड्राइव लगभग एक ही समय पर खराब हो सकती हैं, और बाकी भी rebuild के दौरान बढ़े हुए load की वजह से साथ में फेल हो सकती हैं
भरोसेमंद storage मुश्किल चीज़ है
ज़ाहिर है, दोनों एक साथ फेल हुईं, और रात भर recovery करनी पड़ी
सच में किस्मत अच्छी थी :D
लेकिन hardware wear इतना consistent होगा, ऐसा नहीं लगता
एक drive मरने और rebuild के दौरान दूसरी के भी साथ में मरने तक वह ठीक चला
बेशक वह ZFS नहीं था, regular scrub भी नहीं था, 2000s की drive failure rates अलग रही होंगी, और इस्तेमाल न होने पर वह power off भी नहीं करता था
मुख्य बात exact कारण से ज़्यादा correlated failures हैं। sample size 1 है, और internet के किसी random व्यक्ति वाली सामान्य चेतावनी भी लागू है
“यह NAS, NAS के हिसाब से बहुत quiet है” वाला हिस्सा इसलिए है क्योंकि बड़े radius वाला fan कम RPM पर भी बहुत हवा move कर सकता है, और energy efficiency भी कहीं बेहतर होती है
Oxide Computer ने अपनी presentation में बताया था कि वे 80mm fans क्यों इस्तेमाल करते हैं: वे quiet हैं और उससे भी ज़्यादा ज़रूरी, कम power लेते हैं
उन्होंने observe किया कि दूसरे servers में power का 25% तक fans चलाने में खर्च होता है, जबकि उनके यहाँ लगभग 1% है
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
लगभग गायब हो चुके Flex ATX power supplies के 40mm fan को छोड़ दें तो ऐसा ही है, और 80mm भी आजकल काफी rare है। आमतौर पर 120mm या 140mm ज़्यादा दिखते हैं
typical DC high-RPM छोटे fan का high-frequency noise मुझे सच में नापसंद है
उम्मीद है कि fan speed control में भी कोई “smart” तरीका अपनाया होगा ;-)
ज़्यादा airflow को कम speed पर move करने के idea से मैं पूरी तरह convinced हूँ
समझता हूँ कि 1U या 2U chassis में यह मुश्किल है
फिर भी अच्छा है। सिर्फ fan noise कम होना भी impressive है, और यह सोचकर हैरानी होती है कि इतनी simple लगने वाली चीज़ पहले किसी ने क्यों नहीं सोची
मैंने इससे बिल्कुल उलटी सलाह भी सुनी है कि drives को लगातार spinning रखना चाहिए, ताकि power cycles से होने वाला wear कम हो
क्या मानना चाहिए पता नहीं, लेकिन ZFS NAS को चालू रखकर regular scrub चलाना और data verify कर पाना मुझे अच्छा लगता है
संदर्भ के लिए, मैंने 4-drive system 10 साल चलाया और उस दौरान 2 drive failures हुए, लेकिन वे enterprise-grade नहीं बल्कि WD Green थीं
दिन में एक-दो बार drives on/off करना और हर 15 मिनट या उससे कम में spindown होना अलग बातें हैं
WD Green drives NAS के लिए recommend नहीं की जातीं। पहले वे read/write heads को हर कुछ seconds में park कर देती थीं; data access rare हो तो ठीक है, लेकिन server में इससे लगातार wear होता है और early failure हो सकता है
read/write head जब platter के ऊपर तैर रहा होता है तो लगभग कोई wear नहीं होता। power off करने पर head shelf पर या platter के landing zone में physically बैठ जाता है, और landing और takeoff ही head पर सबसे ज़्यादा wear डालते हैं
सबसे खराब स्थिति में static friction की वजह से takeoff के दौरान head उखड़ भी सकता है
bearings भी ज़्यादा चलते हैं, और बहुत लंबे समय तक रुके रहने पर jam हो सकते हैं। drive motor के साथ भी यही है
power on करते समय inrush current भी, चाहे कितना ही छोटा हो, electrical stress है
hard disk बंद करने की वजहें बस power saving, noise reduction और transport हैं
इससे एक दिन में कई बार spin-up और spin-down हो सकते हैं, इसलिए यह तर्क बिल्कुल समझ में नहीं आता
हालांकि मेरे पास इसे support करने वाला evidence नहीं है
अगर ऐसा है, तो disks को हर कुछ मिनट में on/off होने से रोकने के लिए उन्हें continuously spinning रखना lifespan सुधारने में मदद कर सकता है
लेकिन अगर homelab है, तो संभव है कि आप disk maintenance में जितना बचा रहे हैं, उससे कहीं ज़्यादा बिजली के bill में खर्च कर रहे हों
मेरे पास family media के लिए कुछ large-capacity drives हैं, और मैं उन्हें “drive fail नहीं हुई” से अधिक भरोसे के साथ protect करना चाहता हूँ
checksummed filesystem पर चर्चा आम तौर पर ZFS और BTRFS के इर्द-गिर्द घूमती है, लेकिन जिज्ञासा है कि क्या किसी ने bcachefs इस्तेमाल किया है
यह Linux kernel में upstream हो चुका है, और मेरी जानकारी में पूरे checksums को support करता है। लेखक भी filesystem की जिम्मेदारी को गंभीरता से लेता दिखता है
क्या यहाँ कोई इसे इस्तेमाल करता है?
https://bcachefs.org/
पूरे RAID को journal issue की वजह से mount न हो पाने में करीब 1 हफ्ता लगा। configuration में 8 HDD, 2 SSD write cache, और 2 NVMe read cache थे
लेखक ने Reddit पर एक दिन के अंदर जवाब दिया, और मैंने उसका fix apply करके देखा। Linux kernel compile करके उससे boot करना पड़ा, लेकिन समस्या हल नहीं हुई
उसके बाद दुर्भाग्य से कोई जवाब नहीं आया, इसलिए कुछ दिन इंतजार करने के बाद सब wipe करके साधारण mdadm RAID पर लौट गया
जरूरी चीजें तो जाहिर है सब backup की हुई थीं, लेकिन कुछ गैर-जरूरी data खो गया, और फिर याद आया कि cutting edge अस्थिर होता है
हालांकि setup process और features शानदार थे। सिर्फ यह कि disk जोड़कर उन्हें read/write cache के रूप में mark कर सकते हैं, इतना ही काफी अच्छा था
कुछ और साल mature होने के बाद इसे निश्चित तौर पर फिर try करने का इरादा है
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
production data के लिए जोखिम नहीं लेना चाहूंगा, लेकिन homelab के लिए ठीक हो सकता है
बस खुद से पूछना होगा कि कुछ गलत होने पर आप कितना समय खर्च करने को तैयार हैं
ZFS भी 15 साल से ज्यादा समय से इस्तेमाल कर रहा हूं और खराब hardware की वजह से बहुत कुछ देखा है, लेकिन अच्छे enterprise hardware पर यह बिल्कुल flawless चला है
करीब 2TiB SSD को करीब 8TiB की बड़ी hard disk के आगे रखकर SSD को cache की तरह इस्तेमाल करने वाला combination test कर रहा हूं
Ubuntu में अब legacy हो चुके zsys + root ZFS combination से छोटी-मोटी दिक्कतें आईं, लेकिन यह common setup है और कई सालों से व्यापक रूप से इस्तेमाल हो रहा है, इसलिए support ढूंढना आसान है
जब तक bcachefs को भी वैसी ही adoption और community support नहीं मिलती, शायद इसे इस्तेमाल नहीं करूंगा
मुझे लगता है कि drives जिस environment में चलती हैं, वह lifespan में बहुत बड़ा फर्क डालता है
residential environment, datacenter या office की तुलना में कहीं ज्यादा variable होता है। temperature और humidity में उतार-चढ़ाव भी बड़ी चुनौती हैं, लेकिन हैरानी की बात यह थी कि थोड़ी-सी dust का भी काफी साफ असर दिखता है
बहुत पहले basement में एक पुराने Dell server पर 8x500G array चलाता था। सभी drives नई Seagate थीं, 7200RPM, और शायद “enterprise” version थीं
5 साल तक औसतन हर 6 महीने में एक drive खराब हुई। दो parity drives रखीं, spare drive संभालकर रखी, और हर failure पर RMA भेजा
shift करने के बाद lab के लिए dedicated room मिला, और उसी configuration में अगले 5 साल तक एक भी failure नहीं हुआ। उम्मीद थी कि नया environment बेहतर होगा, लेकिन ज्यादा साफ और stable environment से इतना फर्क पड़ेगा, यह चौंकाने वाला था
NAS/file server को लगातार dusty residential environment में रखा और इस्तेमाल किया है, और आज भी fluffy grey Synology logo दिखता है, लेकिन ऐसा कभी नहीं देखा
लगता है उस generation में firmware issue था
annual failure rate यहां देख सकते हैं: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
आजकल की sealed helium-filled drives में, अगर यह कभी समस्या थी भी, तो अब शायद बड़ी समस्या नहीं होगी
“पावर की समस्या से सिस्टम खोने का जोखिम उठाता/उठाती हूं” वाले हिस्से के संदर्भ में, UPS जिस एक और बेहद दुर्लभ failure को रोकता है वह electrical imbalance है
आसपास construction के दौरान बिजली में समस्या आ जाए, या घर के पास बिजली के खंभे पर बिजली गिर जाए, तो ऊपर/नीचे दिशा के spikes आ सकते हैं और दोनों ही destructive हो सकते हैं
मेरी पहली नौकरी में करीब 10 साल पहले कई servers इसी तरह मर गए थे। हालांकि ऐसी समस्या के बारे में मैंने सिर्फ उसी समय सुना था
मेरी समझ में UPS ऐसे spikes को भी रोकता है, और server को नुकसान पहुंचने से पहले UPS ही पहले मर जाएगा
मेरे माता-पिता के घर के TV antenna पर सीधे बिजली गिरी, और coaxial cable से communication box के amplifier/distributor तक connection था
उसके बाद पता नहीं कैसे वह पास के network patch panel तक पहुंच गई, और network से जुड़े सभी wired Ethernet controllers जला दिए। इसमें switch ports और AP में built-in वाले भी शामिल थे
network switch में शायद current ground की तरफ जाने की कोशिश कर रहा था, इसलिए power supply तक destroy हो गई
coax से Cat5 तक यह कैसे पहुंचा, यह अब भी थोड़ा mystery है। हो सकता है electrician ने कहीं दोनों को करीब-करीब parallel में बिछा रखा हो
पूरा network फिर से लगाना पड़ा, लेकिन सौभाग्य से site पर कोई wired computer नहीं था। storage devices भी शायद बच नहीं पाते
Office Depot से खरीदा जाने वाला 99 डॉलर का 850VA APC ऐसा नहीं करता। वह बस AC से battery पर बहुत तेज़ी से switch करता है, असल में power conditioning नहीं करता
अगर अच्छा product खरीद सकते हैं, तो long term में hardware reliability सच में बढ़ती है। clean power अच्छी चीज़ है
जो devices मर गए, जो damaged हुए, और जो ऊपर से ठीक दिख रहे थे, उनके distribution को देखते हुए VDSL ले जाने वाली copper wire बहुत direct path थी। modem Ethernet के जरिए बाकी सभी devices से जुड़ा था
सही solution शायद यह होगा कि पहले optical में convert किया जाए, थोड़ा सा fiber optic segment रखा जाए, फिर वापस convert किया जाए। बिजली glass के बजाय कोई दूसरा path लेने की ज्यादा संभावना रखती है
लेकिन product चुनना उम्मीद से कहीं ज्यादा झंझट भरा निकला, और मैं network-side का व्यक्ति नहीं हूं, इसलिए करीब एक घंटे तक products में फर्क समझने की कोशिश के बाद छोड़ दिया
इसलिए VDSL modem और बाकी equipment के बीच Wi‑Fi bridge लगा दिया है। उम्मीद है अगली storm में वह failure mode isolated रहेगा
उसी modem से जुड़ी एक ZFS array भी थी, वह बच गई, लेकिन लगता है किस्मत अच्छी थी
उस समय server नहीं था, लेकिन LED bulbs हर कुछ हफ्तों में खराब हो जाते थे, जिससे irritation होती थी। building 60s की पुरानी थी, और हमारे घर की electrical setup में भी कुछ संदिग्ध temporary repairs थे
“secret” power off करना नहीं, बस किस्मत है
मैं 4TB HGST drives को 10 साल से ज्यादा समय से 24/7 चला रहा हूं। ठीक 24 नहीं, 8 drives हैं, लेकिन failures 0 हैं
मेरी भी बस किस्मत अच्छी है, और मेरे ऐसे दोस्त भी हैं जिन्होंने इसी drive के लिए कई बार RMA भेजा है
सबसे ज्यादा curiosity यह है कि ऐसा कौन सा data है जिसे ज्यादातर समय बंद रखा जा सकता है, फिर भी 71TB की जरूरत है। क्या यह backup storage server है?
उदाहरण के लिए bearings ठंडे होने पर seize हो सकते हैं
statistics ठीक से जानने वाला कोई व्यक्ति annual failure rate को लगभग 1% मानकर यह calculate कर सकता है कि सभी 24 के बचे रहने की probability कितनी है
ऊपर से पिछले NAS की 20 drives भी fail नहीं हुई थीं। तो N=44 हुआ; इतनी किस्मत कितनी ज्यादा होनी चाहिए?
इसे residential use में इस्तेमाल कर रहा/रही हूं, और data चाहिए हो तो आमतौर पर 10Gbit से कहीं ज्यादा low-power system में copy कर लेता/लेती हूं, फिर इस NAS को वापस बंद कर देता/देती हूं
कुछ drives ऐसी रही हैं जिनके लिए power cycle risky था
इसलिए model से सहमत हूं, लेकिन यह assume नहीं करना चाहिए कि यह हमेशा हर किसी के लिए अच्छा तरीका है। कुछ SSDs को periodically power supply चाहिए होती है
NAS के usage cycle में शायद वह requirement पूरी हो जाएगी
शायद ठीक है, और electricity bill निश्चित रूप से कम आता है। axle में extra grease वाली drives एक समय का peculiar case थीं
सोचता/सोचती हूं कि Backblaze के पास drive on/off और lifespan statistics का model है या नहीं। वे शायद हमेशा-on वाली problem space में होंगे
लेकिन मेरे case में मैं इन drives को frequently power cycle नहीं करता/करती। ज्यादा से ज्यादा महीने में कुछ बार
मैं यह कह या prove नहीं कर सकता/सकती कि यह बड़ा risk नहीं है, लेकिन ऐसा नहीं है यह मानकर 15 साल से ज्यादा समय से यह risk accept किया है
यह भी याद रखना चाहिए कि hard disks में idle होने पर spindown का option होता है। यानी hard disks एक दिन में कई spinups handle कर सकती हैं
वे कुछ Synology devices का backup लेने के लिए internal 3.5-inch hard disk और USB dock इस्तेमाल करते थे, और जब file restore या additional backup के लिए drive को फिर से dock में लगाते, तो लगभग 10 में 1 बार ऐसा लगता था कि power वापस on नहीं होती
production environment में कई सालों से ZFS पर multi-TB PostgreSQL database इस्तेमाल कर रहा/रही हूं, और अब तक bit flip सहित कोई समस्या नहीं आई
जिनकी दिलचस्पी हो, उनके लिए अपना experience यहां document किया है:
https://lackofimagination.org/2022/04/our-experience-with-po...
boot के दौरान intermittent power cut के बारे में, यह देखना चाहिए कि drives startup पर 5V rail से power खींचती हैं
ऐसी drives आमतौर पर अधिकतम 1.2A consume करती हैं। 5V rail पर maximum load 25A (Seasonic Platinum 860W) है, इसे जोड़ें तो staggered spinup इस्तेमाल न करने पर boot के दौरान power failure होने की संभावना ज्यादा है