RAID আর নির্ভরযোগ্য স্টোরেজ

১ · ডিস্ক নষ্ট হয় — MTTF আর সম্ভাবনার হিসাব

পর্ব ৪০-এ দেখেছেন, একটি hard disk ঘূর্ণায়মান প্লেটার, চলমান হেড আর মোটরের যন্ত্র; আর একটি SSD flash চিপ আর একটি ছোট কম্পিউটার (controller), যার নিজের firmware আছে। দুই ধরনের যন্ত্রই একদিন নষ্ট হয়। প্রশ্ন “নষ্ট হবে কি না” নয়, “কখন” — আর তখন ডেটার কী হবে।

এই পর্বের মূল প্রশ্ন: অনেকগুলো অনির্ভরযোগ্য ডিস্ক দিয়ে কীভাবে একটি নির্ভরযোগ্য স্টোরেজ বানানো যায়?

MTTF, MTBF আর MTTR

• MTTF (mean time to failure): একটি যন্ত্র চালু হওয়ার পর নষ্ট হওয়া পর্যন্ত গড় সময়। যে জিনিস মেরামত হয় না, বদলানো হয় (যেমন একটি ডিস্ক), তার জন্য এটিই সঠিক মাপ।
• MTTR (mean time to repair): নষ্ট হওয়ার পর আবার পুরো সুরক্ষিত অবস্থায় ফিরতে গড় সময় — RAID-এ নতুন ডিস্ক বসানো আর তাতে ডেটা ভরার (rebuild) সময়।
• MTBF (mean time between failures): মেরামতযোগ্য সিস্টেমে পরপর দুই ব্যর্থতার মাঝে গড় সময়, মোটামুটি MTBF = MTTF + MTTR. ডিস্ক-নির্মাতারা প্রায়ই “MTBF” লেখেন, আসলে বোঝান MTTF.
• AFR (annualized failure rate): বছরে কত শতাংশ ডিস্ক নষ্ট হয়। ছোট হারে AFR ≈ বছরের ঘণ্টা ÷ MTTF.

অনেক ডিস্ক = আগে প্রথম ব্যর্থতা

ধরুন প্রতিটি ডিস্ক অন্যদের থেকে স্বাধীনভাবে নষ্ট হয়, আর প্রতি ঘণ্টায় নষ্ট হওয়ার হার স্থির λ = ১/MTTF (একে exponential মডেল বলে; এতে ডিস্কের “বয়স” হিসাবে আসে না)। N টি ডিস্কের যেকোনো একটি নষ্ট হওয়ার হার তাহলে N × λ, আর প্রথম ব্যর্থতা পর্যন্ত গড় সময়:

MTTF = ১,০০,০০০ ঘণ্টা ধরলে (এই পর্বের calculator-এর ফল): একটি ডিস্ক — ১১.৪ বছর; ১০টি ডিস্ক — ১০,০০০ ঘণ্টা, প্রায় ৪১৬.৭ দিন; ১০০টি ডিস্ক — ১,০০০ ঘণ্টা, প্রায় ৪১.৭ দিন. এক বছরে ১০০টির অন্তত একটি নষ্ট হওয়ার সম্ভাবনা প্রায় ৯৯.৯৮%. অর্থাৎ বড় সিস্টেমে ডিস্ক নষ্ট হওয়া দুর্ঘটনা নয়, রুটিন ঘটনা।

বাস্তবের ডিস্ক — মডেলের চেয়ে জটিল

২০০৭ সালের FAST সম্মেলনে দুটি বড় মাঠ-গবেষণা প্রকাশিত হয়। Bianca Schroeder ও Garth Gibson কয়েকটি বড় সিস্টেমের প্রায় এক লাখ ডিস্কের বদলের রেকর্ড দেখে জানান, বছরে বদলের হার সাধারণত ২–৪% আর কিছু সিস্টেমে ১৩% পর্যন্ত — datasheet-এর হারের চেয়ে অনেক বেশি; আর বদল গুচ্ছ বেঁধে আসে। একই সম্মেলনে Google-এর Eduardo Pinheiro ও সহকর্মীরা নিজেদের বিশাল ডিস্ক-বহরে বয়সভেদে AFR প্রায় ২% থেকে ৮%-এর বেশি পর্যন্ত পান। তাই এই পর্বের MTTF শুধু শিক্ষণের সংখ্যা — বাস্তব সিদ্ধান্তে মাঠ-তথ্য ব্যবহার করুন।

আর একটি অনুমান — independence — বাস্তবে প্রায়ই ভাঙে: একই কারখানার একই ব্যাচের ডিস্ক একই বয়সে একই কাজের চাপে থাকে; একটি বিদ্যুৎ-বিভ্রাট বা অতিরিক্ত গরম একসাথে কয়েকটিকে আঘাত করে; আর rebuild নিজেই বাকি ডিস্কে বাড়তি চাপ দেয়। এমন correlated failure-এর কথা অংশ ৩, ৭ আর ভাবনার প্রশ্ন ২-এ আবার আসবে।

২ · Striping — ডেটা ভাগ করে বহু ডিস্কে, গতির জন্য

প্রথমে গতির কথা। একটি ডিস্ক একসাথে একটিই কাজ করতে পারে — HDD-র হেড একবারে এক জায়গায় থাকে। চারটি ডিস্ক থাকলে চারটি অনুরোধ একসাথে চলতে পারে, অথবা একটি বড় ফাইলের চার টুকরো একসাথে পড়া যায়। ডেটাকে ছোট টুকরোয় ভাগ করে পালা করে ডিস্কগুলোতে বসানোই striping.

Stripe unit, stripe width আর ঠিকানার হিসাব

• Stripe unit বা chunk: এক ডিস্কে পরপর যতটুকু ডেটা বসে, তারপর পরের ডিস্কে যায় — যেমন 64 KiB বা 512 KiB (Linux mdadm-এর বর্তমান ডিফল্ট chunk 512 KiB).
• Stripe: সব ডিস্ক জুড়ে একই “সারির” chunk-গুলো; stripe width = ডেটা-ডিস্কের সংখ্যা × chunk.
• ঠিকানার হিসাব (RAID 0, N টি ডিস্ক): logical chunk নম্বর c হলে ডিস্ক = c mod N, সেই ডিস্কে অবস্থান = ⌊c ÷ N⌋. যেমন N = ৪ হলে chunk ১০ যায় ডিস্ক ২-এ, সেখানে সারি ২-এ।

Chunk ছোট হলে একটি বড় অনুরোধ অনেক ডিস্কে ছড়ায় — এক ফাইল পড়ার throughput বাড়ে, কিন্তু প্রতিটি অনুরোধ সব ডিস্ককে ব্যস্ত রাখে। Chunk বড় হলে ছোট অনুরোধগুলো সাধারণত একটি ডিস্কেই শেষ হয়, ফলে আলাদা আলাদা অনুরোধ একসাথে আলাদা ডিস্কে চলে — database-এর মতো অনেক ছোট random অনুরোধের কাজে ভালো।

পুরোনো RAID 2 আর 3 ভাগ করত bit বা byte স্তরে, তাই প্রতিটি অনুরোধে সব ডিস্ক একসাথে ব্যস্ত হতো (অংশ ৪)। আধুনিক সব নকশা (RAID 0, 4, 5, 6, 10) block-level, যাতে ছোট অনুরোধ একটি ডিস্কেই শেষ হয় আর অনেকগুলো একসাথে চলে।

RAID 0 — শুধু striping

RAID 0-তে কোনো redundancy নেই: N টি ডিস্কের পুরো ধারণক্ষমতা ব্যবহারযোগ্য, পড়া আর লেখা দুটিই প্রায় N গুণ, কিন্তু যেকোনো একটি ডিস্ক গেলে পুরো অ্যারে যায় — কারণ প্রতিটি বড় ফাইলের টুকরো সব ডিস্কে। ডেটা-হারানোর গড় সময় অংশ ১-এর সূত্রেই MTTF ÷ N. তাই RAID 0 শুধু এমন ডেটার জন্য, যা আবার বানানো যায় — ভিডিও এডিটিং-এর অস্থায়ী ফাইল, build cache, বা এমন cluster-এর node যেখানে ডেটার কপি অন্য মেশিনে আছে।

৩ · Mirroring আর MTTDL — দুই কপির শক্তি

সবচেয়ে সরল redundancy: প্রতিটি ব্লক দুটি ডিস্কে লেখা। এটিই RAID 1 বা mirroring. একটি ডিস্ক নষ্ট হলে অন্যটি থেকে সব ডেটা পাওয়া যায়; নতুন ডিস্ক বসিয়ে কপি করলে (rebuild) আবার দুই কপি।

• ধারণক্ষমতা: অর্ধেক (দুই কপির mirror-এ)। N-way mirror-এ N ভাগের এক ভাগ।
• পড়া: যেকোনো কপি থেকে পড়া যায় — দুটি পড়া একসাথে দুই ডিস্কে চলতে পারে, তাই random পড়া প্রায় দ্বিগুণ।
• লেখা: প্রতিটি লেখা দুই ডিস্কেই — একটি ডিস্কের মতোই গতি (দুটি সমান্তরালে চলে), কিন্তু I/O দ্বিগুণ।

ডেটা হারানোর গড় সময় — MTTDL

Mirror-এ ডেটা হারায় তখনই, যখন একটি ডিস্ক নষ্ট হওয়ার পর মেরামত শেষ হওয়ার আগেই অন্যটিও নষ্ট হয়। এই গড় সময়কে বলে MTTDL (mean time to data loss). সূত্রটি তিন ধাপের যুক্তিতে আসে (independence আর exponential মডেল ধরে):

পূর্ণ সংখ্যায় (calculator-এর ফল): MTTF = ১,০০,০০০ ঘণ্টা, MTTR = ১০ ঘণ্টা হলে MTTF² = ১০^১০, ২ × MTTR = ২০, তাই MTTDL = ১০^১০ ÷ ২০ = ৫ × ১০^৮ ঘণ্টা ≈ ৫৭,০৭৭.৬ বছর. একটি ডিস্কের MTTF-এর ঠিক ৫,০০০ গুণ (MTTF ÷ (২ × MTTR) = ৫,০০০)। আর লক্ষ করুন MTTR কোথায়: হরে। মেরামত দ্বিগুণ ধীর হলে MTTDL অর্ধেক — তাই দ্রুত rebuild আর hot spare এত গুরুত্বপূর্ণ (অংশ ৭)।

একই যুক্তি N টি ডিস্কের RAID 5-এ (একটি ব্যর্থতা সয়): প্রথম ব্যর্থতার হার N/MTTF, তারপর বাকি N − ১টির যেকোনো একটি MTTR-এর মধ্যে গেলে ক্ষতি, তাই MTTDL_{RAID 5} ≈ MTTF² ÷ (N(N − ১) × MTTR) — Patterson ও সহকর্মীদের গবেষণাপত্রেও এই রূপেরই সূত্র। ৬টি ডিস্কে: ১০^১০ ÷ (৬ × ৫ × ১০) ≈ ৩.৩৩ × ১০^৭ ঘণ্টা ≈ ৩,৮০৫.২ বছর — mirror জোড়ার চেয়ে কম, কারণ বেশি ডিস্ক মানে বেশি “দ্বিতীয় প্রার্থী”।

৪ · Parity আর XOR — এক ব্লকে সবার পাহারা

Mirroring-এ অর্ধেক জায়গা যায়। কম খরচে একই সুরক্ষা কি সম্ভব? হ্যাঁ, যদি আমরা জানি কোন ডিস্কটি নষ্ট হয়েছে — আর ডিস্কের বেলায় তা জানা যায়, কারণ নষ্ট ডিস্ক সাড়া দেয় না বা নিজেই ত্রুটি জানায় (প্রতিটি sector-এর নিজস্ব ECC আছে)। তখন একটি মাত্র বাড়তি ব্লকই যথেষ্ট: সব ডেটা-ব্লকের XOR.

XOR-এর তিনটি গুণ

• a ⊕ a = 0 আর a ⊕ 0 = a — একই জিনিস দুবার XOR করলে মুছে যায়।
• ক্রম বা জোড়া বাঁধায় কিছু যায় আসে না (commutative, associative).
• তাই P = D0 ⊕ D1 ⊕ D2 হলে যেকোনো একটি হারালে বাকিদের XOR-ই সেটি: D1 = D0 ⊕ D2 ⊕ P (কারণ D0 ⊕ D2 ⊕ P = D0 ⊕ D2 ⊕ D0 ⊕ D1 ⊕ D2 = D1).

হাতে বিট মিলিয়ে দেখুন

প্রতিটি বিট-কলামে নিয়মটি সহজ: P-এর বিট এমন যে ওই কলামে মোট ১-এর সংখ্যা জোড় হয় (even parity). একটি ঘর মুছে গেলে বাকি ঘরগুলো দেখে বলা যায়, জোড় রাখতে সেখানে ০ ছিল না ১. পরীক্ষার খাতায় ঠিক এভাবেই কলাম ধরে হিসাব করুন।

নিচের C প্রোগ্রাম একই কাজ বাস্তবের মতো করে — byte array-র ওপর: তিনটি ৮-byte chunk, তাদের parity, তারপর একটি chunk “হারিয়ে” XOR দিয়ে ফেরত।

#include <stdio.h>
#include <string.h>

#define K 3          /* data chunks in one stripe */
#define C 8          /* bytes per chunk */

static void dump(const char *name, const unsigned char *b) {
    printf("%-9s", name);
    for (int i = 0; i < C; i++) printf(" %02x", b[i]);
    printf("\n");
}

int main(void) {
    unsigned char d[K][C], parity[C] = {0}, saved[C];
    memcpy(d[0], "Dhaka-01", C);
    memcpy(d[1], "Khulna02", C);
    memcpy(d[2], "Sylhet03", C);
    for (int k = 0; k < K; k++)               /* parity = d0 ^ d1 ^ d2, byte by byte */
        for (int i = 0; i < C; i++) parity[i] ^= d[k][i];
    for (int k = 0; k < K; k++) { char n[16]; snprintf(n, sizeof n, "chunk%d", k); dump(n, d[k]); }
    dump("parity", parity);

    memcpy(saved, d[1], C);                   /* keep a copy only to check later */
    memset(d[1], 0, C);                       /* the disk holding chunk1 dies */
    for (int i = 0; i < C; i++)               /* rebuild = parity ^ all survivors */
        d[1][i] = parity[i] ^ d[0][i] ^ d[2][i];
    dump("rebuilt1", d[1]);
    printf("rebuilt chunk1 = \"%.8s\", identical: %s\n", (const char *)d[1],
           memcmp(d[1], saved, C) == 0 ? "yes" : "no");
    return 0;
}

chunk0    44 68 61 6b 61 2d 30 31
chunk1    4b 68 75 6c 6e 61 30 32
chunk2    53 79 6c 68 65 74 30 33
parity    5c 79 78 6f 6a 38 30 30
rebuilt1  4b 68 75 6c 6e 61 30 32
rebuilt chunk1 = "Khulna02", identical: yes

ঐতিহাসিক লেভেল — RAID 2 আর RAID 3

• RAID 2: bit-level striping, আর সুরক্ষা Hamming code দিয়ে, যা কোন বিট ভুল তা খোঁজে বলে কয়েকটি বাড়তি ডিস্ক লাগে। কিন্তু ডিস্ক নিজেই জানায় কোন sector পড়া যায়নি, তাই একটি parity-ই যথেষ্ট — RAID 2 আজ অচল।
• RAID 3: byte-level striping আর একটি আলাদা parity ডিস্ক; সব ডিস্কের ঘূর্ণন একসাথে মেলানো (synchronized spindle). বড় sequential কাজে দ্রুত, কিন্তু একবারে একটিই অনুরোধ; আজ বিরল।

RAID 4 — block-level, একটি আলাদা parity ডিস্ক

RAID 4 = block-level striping + সব parity একটি নির্দিষ্ট ডিস্কে। ছোট পড়া একটি ডেটা-ডিস্কেই শেষ হয়, তাই অনেকগুলো পড়া একসাথে চলে। কিন্তু প্রতিটি লেখায় parity বদলাতে হয় — আর সব parity এক ডিস্কে, তাই N − ১টি ডেটা-ডিস্কের সব ছোট লেখা লাইন ধরে ওই একটি ডিস্কের সামনে দাঁড়ায়। Parity ডিস্কই bottleneck — একটি চুলার রেস্তোরাঁর মতো, যেখানে সব রাঁধুনিকে শেষ ধাপে একই চুলায় আসতে হয়।

ব্যতিক্রম: লেখা সবসময় পুরো stripe জুড়ে হলে parity নতুন করে হিসাব করে একসাথে লেখা যায়, পুরোনো কিছু পড়তে হয় না, bottleneck-ও থাকে না। NetApp-এর WAFL file system এভাবে লেখা জমিয়ে বহু বছর RAID 4 (আর দুই-parity রূপ RAID-DP) ব্যবহার করেছে — file system আর RAID একসাথে নকশার পুরোনো উদাহরণ, যার আধুনিক রূপ অংশ ৮-এর ZFS.

৫ · RAID 5 — ঘুরতে থাকা parity আর ছোট লেখার দাম

RAID 4-এর bottleneck-এর সমাধান সহজ: parity একটি ডিস্কে না রেখে stripe-ভেদে ঘুরিয়ে সব ডিস্কে ছড়িয়ে দেওয়া। Stripe 0-এর parity শেষ ডিস্কে, stripe 1-এর parity তার আগেরটিতে, এভাবে। এখন দুটি ছোট লেখা যদি আলাদা stripe-এ পড়ে, তাদের parity আলাদা ডিস্কে — একসাথে চলতে পারে। এটিই RAID 5: distributed parity.

• ধারণক্ষমতা: (N − ১) × S — একটি ডিস্কের সমান জায়গা parity-তে, কিন্তু ছড়ানো। ৪টি ডিস্কে দক্ষতা ৭৫%, ৮টিতে ৮৭.৫%.
• সয়: যেকোনো একটি ডিস্কের ব্যর্থতা।
• পড়া: random পড়ায় N টি ডিস্কই কাজে লাগে (RAID 4-এ parity ডিস্ক পড়ায় অলস থাকে)।
• লেখা: বড়, পুরো-stripe লেখা দ্রুত; কিন্তু ছোট লেখায় দাম — নিচে।

নিচের simulator ৪টি ডিস্কে ৪টি stripe বানায়। প্রতিটি “ব্লক” এখানে এক byte — বার্তা DHAKA-METRO!-এর একেকটি অক্ষর — যাতে পুরো layout এক নজরে দেখা যায়। তারপর একটি ডিস্ক “নষ্ট” করে বাকিদের XOR দিয়ে তার সব ব্লক আবার বানায়।

// RAID 5 simulator: N disks, rotating parity, 1-byte blocks, then a disk failure.
const N = 4, msg = "DHAKA-METRO!";            // 12 data bytes = 4 stripes x 3
const hex = b => b.toString(16).padStart(2, "0");
const disks = Array.from({ length: N }, () => []);
const stripes = msg.length / (N - 1);
let k = 0;
for (let s = 0; s < stripes; s++) {
  const pd = N - 1 - (s % N);                   // parity disk rotates right-to-left
  let p = 0;
  for (let d = 0; d < N; d++) {
    if (d === pd) continue;
    const b = msg.charCodeAt(k);
    disks[d][s] = { tag: "D" + k++, val: b };  p ^= b;
  }
  disks[pd][s] = { tag: "P" + s, val: p };
}
const show = cell => (cell.tag + ":" + hex(cell.val)).padEnd(7);
console.log("stripe  " + disks.map((_, d) => ("disk" + d).padEnd(7)).join(" "));
for (let s = 0; s < stripes; s++)
  console.log(("  " + s).padEnd(8) + disks.map(dk => show(dk[s])).join(" "));

const failed = 2, lost = disks[failed];        // remember the truth, then "fail"
disks[failed] = null;
console.log("\ndisk" + failed + " FAILED - rebuilding from the other " + (N - 1) + " disks");
let ok = 0;
for (let s = 0; s < stripes; s++) {
  let x = 0;
  for (let d = 0; d < N; d++) if (d !== failed) x ^= disks[d][s].val;
  const match = x === lost[s].val;  ok += match;
  console.log("  stripe " + s + ": XOR of survivors = " + hex(x) + "  original " +
              lost[s].tag + ":" + hex(lost[s].val) + (match ? "  match" : "  MISMATCH"));
}
console.log(ok + "/" + stripes + " blocks rebuilt correctly");

stripe  disk0   disk1   disk2   disk3
  0     D0:44   D1:48   D2:41   P0:4d
  1     D3:4b   D4:41   P1:27   D5:2d
  2     D6:4d   P2:5c   D7:45   D8:54
  3     P3:3c   D9:52   D10:4f  D11:21

disk2 FAILED - rebuilding from the other 3 disks
  stripe 0: XOR of survivors = 41  original D2:41  match
  stripe 1: XOR of survivors = 27  original P1:27  match
  stripe 2: XOR of survivors = 45  original D7:45  match
  stripe 3: XOR of survivors = 4f  original D10:4f  match
4/4 blocks rebuilt correctly

Small write — কেন একটি লেখায় চারটি I/O

ধরুন একটি stripe-এর শুধু একটি ব্লক (D1) বদলাতে হবে। Parity-ও বদলাতে হবে, নইলে পরে rebuild ভুল ফল দেবে। নতুন parity জানার দুই উপায়:

1. Read-modify-write: পুরোনো D1 আর পুরোনো P পড়া; নতুন P′ = P ⊕ D1_{পুরোনো} ⊕ D1_নতুন (পুরোনো D1-এর অবদান XOR করে মুছে নতুনটির অবদান যোগ); তারপর নতুন D1 আর P′ লেখা। ২টি পড়া + ২টি লেখা = ৪টি I/O, ডিস্ক যতগুলোই থাকুক।
2. Reconstruct-write: stripe-এর বাকি ডেটা-ব্লকগুলো পড়া, নতুন D1-সহ সবার XOR করে P′, তারপর ২টি লেখা। N টি ডিস্কে N − ২টি পড়া + ২টি লেখা = N টি I/O. ৪টি ডিস্কে দুটিই ৪টি I/O; ৮টিতে প্রথমটি ৪, দ্বিতীয়টি ৮. তাই ছোট লেখায় read-modify-write, প্রায়-পুরো stripe লেখায় reconstruct-write; Linux md যেটিতে কম পড়া লাগে সেটি বাছে।

নিচের stepper পুরোনো উদাহরণের বিটগুলো নিয়েই চলে: D0 = 10110010, D1 = 01101100, D2 = 11010101, P = 00001011; D1-এর নতুন মান 00111111.

1 request: write D1 := 001111112 I/O 1  read  old D1 (disk1)3 I/O 2  read  old P  (disk3)4 CPU    P' = P ⊕ D1 ⊕ D1'5 I/O 3  write new D1 (disk1)6 I/O 4  write new P' (disk3)

এই ৪-এর দাম সরাসরি গতিতে পড়ে। প্রতিটি ডিস্ক সেকেন্ডে R টি random I/O পারলে, N টি ডিস্কের RAID 5-এ ছোট random লেখা মোটামুটি N × R ÷ ৪ টি — যেখানে RAID 10-এ N × R ÷ ২ আর RAID 0-তে N × R. Database-এর মতো ছোট-লেখা-ভারী কাজে তাই প্রায়ই RAID 10 বেছে নেওয়া হয়। Write cache ছোট লেখা জমিয়ে পুরো stripe বানাতে পারলে এই দাম কমে (অংশ ৮)।

৬ · RAID 6, RAID 10 বনাম 01, আর সব লেভেলের তুলনা

RAID 6 — P আর Q, দুটি ব্যর্থতা সয়

RAID 6 প্রতিটি stripe-এ দুটি আলাদা হিসাব-ব্লক রাখে, দুটিই ঘুরিয়ে ছড়ানো। P সেই পুরোনো XOR. Q একটি ভিন্ন হিসাব: প্রতিটি ডেটা-ব্লককে আলাদা একটি সহগ দিয়ে “গুণ” করে যোগ — তবে সাধারণ গণিতে নয়, ২৫৬টি মানের একটি finite field (GF(2⁸))-এ, যেখানে যোগ মানেই XOR. এটি Reed–Solomon code-এর একটি বিশেষ রূপ। দুটি ডিস্ক হারালে দুটি অজানা, আর P ও Q দুটি স্বাধীন সমীকরণ — তাই দুটি অজানাই সমাধান করা যায়। Linux-এর md driver ঠিক এই P+Q নকশা ব্যবহার করে; তার গণিত H. Peter Anvin-এর “The mathematics of RAID-6” লেখায় সহজভাবে ব্যাখ্যা করা আছে।

• ধারণক্ষমতা: (N − ২) × S. দক্ষতা ৬টি ডিস্কে ৬৬.৭%, ৮টিতে ৭৫%.
• Small write: পুরোনো D, P, Q পড়া আর নতুন D, P, Q লেখা — ৬টি I/O; Q-এর হিসাবে CPU-ও বেশি খাটে।
• লাভ: rebuild চলার সময়ও আরেকটি ব্যর্থতা বা পড়ার ত্রুটি সয় — বড় ডিস্কের যুগে এটিই মূল যুক্তি (অংশ ৭)। MTTDL-এর সূত্রে MTTF-এর ঘাত ৩ হয়ে যায়: MTTF³ ÷ (N(N − ১)(N − ২) × MTTR²)।

RAID 10 বনাম RAID 01

দুটিই striping আর mirroring মেলায়, শুধু ক্রম উল্টো। RAID 10 (1+0): আগে জোড়ায় জোড়ায় mirror, তারপর জোড়াগুলোর ওপর stripe. RAID 01 (0+1): আগে দুটি RAID 0 stripe, তারপর পুরো stripe দুটিকে একে অপরের mirror. ধারণক্ষমতা আর স্বাভাবিক গতি একই — অর্ধেক জায়গা, ছোট লেখায় ২টি I/O. পার্থক্য দেখা দেয় একটি ডিস্ক নষ্ট হওয়ার পর।

1 4 disks: A1 A2 B1 B22 first failure: A13 second failure = A2 ?4 second failure = B1 ?5 second failure = B2 ?6 tally

নিচের ছোট প্রোগ্রামটি সব সম্ভাব্য (প্রথম, দ্বিতীয়) ব্যর্থতা-জোড়া গুনে একই উত্তর ৪, ৬ আর ৮টি ডিস্কে যাচাই করে।

// RAID 10 vs RAID 01: after one disk fails, which second failures lose data?
// Enumerate every ordered pair (first, second) of distinct failed disks.
function alive(kind, n, dead) {                 // disks 0..n-1, dead = Set
  const half = n / 2;
  if (kind === "10") {                          // mirror pairs (0,1) (2,3) ... striped
    for (let p = 0; p < n; p += 2) if (dead.has(p) && dead.has(p + 1)) return false;
    return true;
  }
  // "01": stripe A = disks 0..half-1, stripe B = half..n-1, A mirrored to B;
  // one dead disk takes its whole stripe offline.
  const aDead = [...dead].some(d => d < half), bDead = [...dead].some(d => d >= half);
  return !(aDead && bDead);
}
for (const n of [4, 6, 8]) {
  for (const kind of ["10", "01"]) {
    let survive = 0, total = 0;
    for (let a = 0; a < n; a++)
      for (let b = 0; b < n; b++) {
        if (a === b) continue;
        total++;
        if (alive(kind, n, new Set([a, b]))) survive++;
      }
    console.log(`n=${n} RAID ${kind}: second failure survivable in ${survive}/${total} cases` +
                ` = ${(100 * survive / total).toFixed(1)}%`);
  }
}

n=4 RAID 10: second failure survivable in 8/12 cases = 66.7%
n=4 RAID 01: second failure survivable in 4/12 cases = 33.3%
n=6 RAID 10: second failure survivable in 24/30 cases = 80.0%
n=6 RAID 01: second failure survivable in 12/30 cases = 40.0%
n=8 RAID 10: second failure survivable in 48/56 cases = 85.7%
n=8 RAID 01: second failure survivable in 24/56 cases = 42.9%

সব লেভেল এক টেবিলে

R = একটি ডিস্কের প্রতি সেকেন্ডে random I/O; গতির কলামগুলো আনুমানিক, controller, cache আর workload-এ অনেক বদলায়। এবার একটি নির্দিষ্ট অ্যারের সংখ্যা — ৬টি ৪ TB ডিস্ক — আর অংশ ১ ও ৩-এর MTTF/MTTDL-এর হিসাব এক জায়গায়:

// RAID calculator: usable capacity, efficiency, failures survived, small-write cost,
// then the MTTF / MTTDL numericals (independent failures assumed).
const N = 6, S = 4;                                 // N disks, S TB each
const levels = [                                    // [name, data disks, guaranteed failures, I/Os per small write]
  ["RAID 0",  N,     0,     1],
  ["RAID 1",  1,     N - 1, N],                     // N-way mirror: every write goes to all N
  ["RAID 5",  N - 1, 1,     4],
  ["RAID 6",  N - 2, 2,     6],
  ["RAID 10", N / 2, 1,     2],
];
console.log(`${N} disks x ${S} TB = ${N * S} TB raw`);
console.log("level    usable  efficiency  survives  I/Os per small write");
for (const [name, data, fail, io] of levels)
  console.log(name.padEnd(9) + (data * S + " TB").padStart(6) +
              ((100 * data / N).toFixed(1) + "%").padStart(12) +
              String(fail).padStart(10) + String(io).padStart(12));

const MTTF = 100000, MTTR = 10, HPY = 8760;          // hours; hours per year
const yrs = h => (h / HPY).toFixed(1) + " years";
console.log(`\nMTTF of one disk: ${MTTF} h = ${yrs(MTTF)}`);
for (const n of [10, 100]) console.log(`MTTF of ${n} disks (first failure): ${MTTF / n} h = ${(MTTF / n / 24).toFixed(1)} days`);
const pair = MTTF ** 2 / (2 * MTTR);
console.log(`MTTDL mirrored pair  = MTTF^2/(2*MTTR) = ${pair.toExponential(2)} h = ${yrs(pair)}`);
const r5 = MTTF ** 2 / (N * (N - 1) * MTTR);
console.log(`MTTDL RAID 5, ${N} disks = MTTF^2/(N(N-1)MTTR) = ${r5.toExponential(2)} h = ${yrs(r5)}`);

// Unrecoverable read errors while rebuilding RAID 5: all N-1 survivors are read in full.
const bits = (N - 1) * S * 1e12 * 8;
for (const ure of [1e14, 1e15]) {
  const expected = bits / ure;
  console.log(`URE spec 1 per ${ure.toExponential(0)} bits: read ${(N - 1) * S} TB, ` +
              `expected UREs ${expected.toFixed(2)}, P(no URE) = ${(100 * Math.exp(-expected)).toFixed(1)}%`);
}

6 disks x 4 TB = 24 TB raw
level    usable  efficiency  survives  I/Os per small write
RAID 0    24 TB      100.0%         0           1
RAID 1     4 TB       16.7%         5           6
RAID 5    20 TB       83.3%         1           4
RAID 6    16 TB       66.7%         2           6
RAID 10   12 TB       50.0%         1           2

MTTF of one disk: 100000 h = 11.4 years
MTTF of 10 disks (first failure): 10000 h = 416.7 days
MTTF of 100 disks (first failure): 1000 h = 41.7 days
MTTDL mirrored pair  = MTTF^2/(2*MTTR) = 5.00e+8 h = 57077.6 years
MTTDL RAID 5, 6 disks = MTTF^2/(N(N-1)MTTR) = 3.33e+7 h = 3805.2 years
URE spec 1 per 1e+14 bits: read 20 TB, expected UREs 1.60, P(no URE) = 20.2%
URE spec 1 per 1e+15 bits: read 20 TB, expected UREs 0.16, P(no URE) = 85.2%

৭ · ডিস্ক নষ্ট হলে — rebuild, URE আর hot spare

একটি ডিস্ক নষ্ট হলে অ্যারে degraded mode-এ চলে। সুরক্ষা ফেরাতে নতুন ডিস্ক বসিয়ে প্রতিটি stripe-এর হারানো ব্লক বানিয়ে তাতে লিখতে হয় — rebuild (ZFS-এর ভাষায় resilver). অংশ ৫-এর simulator-এর অ্যারেতে disk2 নষ্ট হলে কী ঘটে, ধাপে ধাপে:

1 array optimal, 4 disks2 disk2 fails: degraded3 spare: rebuild stripe 04 spare: rebuild stripe 15 spare: rebuild stripe 26 spare: rebuild stripe 3

Rebuild কত সময় নেয়

সবচেয়ে ভালো ক্ষেত্রেও rebuild-এ নতুন ডিস্কটি শুরু থেকে শেষ পর্যন্ত লিখতে হয়। একটি HDD-র sequential গতি ধরুন ১৫০–২০০ MB/s: ৪ TB ডিস্কে ১৫০ MB/s-এ প্রায় ৭.৪ ঘণ্টা, ২০০ MB/s-এ প্রায় ৫.৬ ঘণ্টা; ১৬ TB ডিস্কে ২০০ MB/s-এ প্রায় ২২.২ ঘণ্টা — আর অ্যারে যদি একই সময়ে ব্যবহারকারীর কাজও সামলায়, গতি ধরুন ৫০ MB/s-এ নামলে প্রায় ৮৮.৯ ঘণ্টা, প্রায় চার দিন। এগুলোই বাস্তবের MTTR, আর অংশ ৩-এর সূত্রে MTTR হরে বসে। Linux md-তে rebuild-এর গতির সীমা dev.raid.speed_limit_min/_max sysctl দিয়ে ঠিক হয়।

URE — rebuild-এর লুকানো ঝুঁকি

ডিস্কের datasheet-এ একটি সংখ্যা থাকে: unrecoverable read error rate — যেমন সাধারণ desktop HDD-তে “প্রতি ১০^১৪ বিট পড়ায় ১টির কম”, enterprise HDD-তে প্রায়ই ১০^১৫. URE মানে ডিস্ক একটি sector পড়তে পারল না, নিজের ECC দিয়েও ঠিক করতে পারল না। স্বাভাবিক RAID 5-এ এতে সমস্যা নেই — অন্য ডিস্কের parity দিয়ে সেই sector বানিয়ে আবার লেখা হয়। কিন্তু degraded RAID 5-এ redundancy নেই; rebuild-এর মাঝে একটি URE মানে অন্তত সেই stripe-এর ডেটা আর বানানো যায় না।

Calculator-এর হিসাব: ৬টি ৪ TB ডিস্কের RAID 5-এ rebuild-এ বাকি ৫টির ২০ TB = ১.৬ × ১০^১৪ বিট পড়তে হয়। ১০^১৪ হারে গড়ে ১.৬০টি URE প্রত্যাশিত, একটিও না হওয়ার সম্ভাবনা e^−১.৬ ≈ ২০.২%; ১০^১৫ হারে ০.১৬টি, সম্ভাবনা ৮৫.২%. এই ধরনের হিসাব থেকেই ২০০৭ সালে Robin Harris ZDNet-এ লেখেন “Why RAID 5 stops working in 2009” — বড় ডিস্কের যুগে RAID 5-এর rebuild প্রায় নিশ্চিত ব্যর্থ হবে। এটি “RAID 5 is dead” বিতর্কের সূচনা।

Hot spare আর scrubbing

• Hot spare: অ্যারেতে আগে থেকে লাগানো একটি অলস ডিস্ক। ব্যর্থতা ধরা পড়লেই controller সেটিতে rebuild শুরু করে — মানুষ এসে ডিস্ক বদলানোর ঘণ্টা বা দিন MTTR থেকে বাদ যায়।
• Scrubbing: নিয়মিত (যেমন মাসে একবার) পুরো অ্যারে পড়ে parity মিলিয়ে দেখা আর খারাপ sector আগেভাগে ঠিক করা — যাতে লুকানো URE rebuild-এর দিনে প্রথম ধরা না পড়ে। Linux md-তে root হিসেবে /sys/block/md0/md/sync_action-এ check লিখে শুরু হয়; অনেক distro এর জন্য একটি নির্ধারিত cron বা systemd timer রাখে। ZFS-এ zpool scrub, hardware controller-এ সাধারণত “patrol read”.

৮ · Hardware বনাম software RAID, write hole আর ZFS RAID-Z

RAID কোথায় চলে

মাদারবোর্ডের firmware RAID (“fake RAID”)-এ আসল কাজ OS-এর driver-ই করে। Linux-এ একটি software RAID 5 তৈরি আর পর্যবেক্ষণ দেখতে এমন (root লাগে, আর /dev/sdb…/dev/sde-এর সব ডেটা মুছে যাবে — তাই এখানে চালানো যায় না, শুধু নমুনা):

# ৪টি ডিস্ক দিয়ে RAID 5 (ডিফল্ট chunk 512K, layout left-symmetric)
$ sudo mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

# পরে একটি ডিস্ক নষ্ট হয়েছে (sdd বাদ গেছে), নতুন sde যোগ করে rebuild চলছে:
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sde[4] sdd[2](F) sdc[1] sdb[0]
      11720661504 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UU_U]
      [==>..................]  recovery = 12.6% (493123456/3906887168) finish=301.4min speed=188762K/sec
      bitmap: 0/30 pages [0KB], 65536KB chunk

$ sudo mdadm --detail /dev/md0        # অবস্থা, কোন ডিস্ক faulty, rebuild কত দূর
$ sudo mdadm /dev/md0 --remove /dev/sdd   # নষ্ট ডিস্ক অ্যারে থেকে বাদ

লাইনগুলো পড়তে শিখুন: [4/3] মানে ৪টি ডিস্কের অ্যারে, সক্রিয় ৩টি; [UU_U]-এ প্রতিটি অবস্থানের অবস্থা — U সুস্থ, _ নেই বা rebuild চলছে; (F) মানে faulty. algorithm 2 হলো left-symmetric layout. ব্লক-সংখ্যা: প্রতিটি সদস্যের 3906887168 KiB × ৩টি ডেটা-ডিস্ক = 11720661504 — RAID 5-এর (N − ১) × S. finish=301.4min: বাকি অংশ ÷ বর্তমান গতি, প্রায় পাঁচ ঘণ্টা। bitmap হলো write-intent bitmap: কোন অঞ্চলে লেখা চলছিল তার হিসাব, যাতে হঠাৎ বন্ধ হওয়ার পর পুরো অ্যারে নয়, শুধু সেই অঞ্চলগুলো আবার মেলাতে হয়।

Write hole — অর্ধেক লেখা stripe

অংশ ৫-এর stepper-এর ধাপ ৫ মনে করুন: নতুন D1 লেখা হয়ে গেছে, নতুন P তখনো নয়। ঠিক তখন বিদ্যুৎ গেলে ডিস্কে stripe অসংগত — D0 ⊕ D1′ ⊕ D2 ≠ P. সমস্যাটি তখনই ধরা পড়ে না; পরে কোনো একদিন একটি ডিস্ক নষ্ট হলে rebuild এই ভুল P দিয়ে একটি অন্য ব্লক “ফেরত” বানায় — ভুল ডেটা, কোনো সতর্কবার্তা ছাড়াই। এটিই write hole. পর্ব ৪৪-এর crash consistency সমস্যার RAID-সংস্করণ: একাধিক ডিস্কে লেখা একসাথে atomic হয় না।

প্রতিকার কয়েক রকম:

• Battery- বা flash-backed write cache: hardware controller লেখাগুলো আগে নিজের cache-এ রাখে; বিদ্যুৎ গেলে একটি ব্যাটারি বা supercapacitor সেই cache বাঁচিয়ে রাখে (বা flash-এ ঢেলে দেয়), আর বিদ্যুৎ ফিরলে অসমাপ্ত লেখাগুলো শেষ করে। ব্যাটারি দুর্বল হলে ভালো controller নিজে থেকেই write-back cache বন্ধ করে ধীর-কিন্তু-নিরাপদ write-through-এ চলে যায়।
• Journal: Linux md-তে RAID 4/5/6-এর জন্য একটি আলাদা দ্রুত ডিস্কে write journal, অথবা partial parity log (PPL) রাখার ব্যবস্থা আছে (Linux ৪.x সংস্করণগুলোর সময় যোগ হয়েছে) — পর্ব ৪৪-এর journaling-এর একই ধারণা।
• কখনো জায়গায় না লেখা: ZFS-এর পথ — নিচে।

ZFS RAID-Z — RAID file system-এর ভেতরে

Sun Microsystems-এ Jeff Bonwick আর Matthew Ahrens-এর নেতৃত্বে তৈরি ZFS (২০০৫ সালে OpenSolaris-এ প্রকাশ; আজ OpenZFS প্রকল্প Linux, FreeBSD-সহ বিভিন্ন OS-এ) volume manager, RAID আর file system একসাথে মেলায়। তার RAID-Z (একটি parity-র RAID-Z1, দুটির Z2, তিনটির Z3) RAID 5/6-এর দুটি দুর্বলতা দূর করে:

• Write hole নেই: ZFS copy-on-write (পর্ব ৪৪), আর RAID-Z-এর stripe-এর প্রস্থ পরিবর্তনশীল — প্রতিটি লেখা নতুন জায়গায় নিজেই একটি পূর্ণ stripe, নিজের parity-সহ। তাই read-modify-write নেই; নতুন লেখা শেষ না হলে পুরোনো সংস্করণই বৈধ।
• প্রতিটি ব্লকের checksum: সাধারণ RAID শুধু জানে কোন ডিস্ক নষ্ট; একটি ডিস্ক যদি চুপচাপ ভুল ডেটা ফেরত দেয় (silent data corruption — firmware বাগ, ভুল জায়গায় লেখা), RAID 5 জানতেই পারে না কোন ব্লকটি ভুল। ZFS প্রতিটি ব্লকের checksum তার parent pointer-এ রাখে; পড়ার সময় না মিললে parity বা mirror থেকে সঠিক কপি বানায় আর ভুলটি মেরামত করে দেয় (self-healing).
• Resilver শুধু ব্যবহৃত ডেটার: file system জানে কোন ব্লক সত্যিই ব্যবহৃত, তাই অর্ধেক-ভরা pool-এর rebuild পুরো ডিস্ক পড়ার চেয়ে কম সময় নেয়।

দাম: RAID-Z-এ ছোট random পড়ায় প্রায়ই একটি গোটা stripe লাগে, তাই random-পড়া-ভারী কাজে ZFS-এর mirror বেশি দ্রুত; আর pool-এর গঠন পরে বদলানো তুলনামূলক কঠিন। Btrfs-এরও নিজস্ব RAID আছে, তবে তার RAID 5/6 নিয়ে Btrfs-এর নিজের ডকুমেন্টেশন বহু বছর ধরে সতর্ক করে আসছে — ব্যবহারের আগে বর্তমান অবস্থা দেখে নিন।

৯ · RAID backup নয় — ৩-২-১, snapshot, erasure coding আর SSD

এই পর্বের সবচেয়ে গুরুত্বপূর্ণ বাক্য: RAID রক্ষা করে ডিস্কের ব্যর্থতা থেকে, ডেটার ভুল থেকে নয়। RAID-এর কাজ সব কপিকে সবসময় একই রাখা। তাই যা কিছু “বৈধ লেখা” হিসেবে আসে — একটি ভুল rm -rf, একটি অ্যাপের বাগে নষ্ট হওয়া database, ransomware-এর এনক্রিপ্ট করা ফাইল — RAID তা মুহূর্তেই সব ডিস্কে নিখুঁতভাবে ছড়িয়ে দেয়। চুরি, আগুন বা বন্যায় পুরো সার্ভার গেলে RAID কিছুই করতে পারে না।

৩-২-১ নিয়ম

Snapshot বনাম backup

ZFS, Btrfs, LVM বা Windows-এর Volume Shadow Copy একটি মুহূর্তের snapshot নিতে পারে — copy-on-write-এর কারণে প্রায় সঙ্গে সঙ্গে আর প্রায় বিনা খরচে। ভুল করে মোছা ফাইল ফেরত আনতে চমৎকার, কিন্তু snapshot একই pool-এ থাকে: pool নষ্ট হলে, বা কেউ admin অধিকার পেয়ে snapshot মুছে দিলে, সেটিও যায়। Snapshot-কে অন্য মেশিনে পাঠালে (যেমন ZFS-এর zfs send) তবেই তা backup-এর অংশ হয়।

Ransomware-প্রতিরোধী backup (প্রতিরক্ষার দিক)

• অফলাইন বা air-gapped কপি: যে ডিস্ক বা টেপ backup শেষে খুলে রাখা হয়, ভাইরাস নেটওয়ার্ক দিয়ে সেটিতে পৌঁছাতে পারে না।
• Immutable storage: ক্লাউড object storage-এর “object lock” বা WORM (write once, read many) সুবিধায় নির্দিষ্ট সময় পর্যন্ত কপি মোছা বা বদলানো যায় না — admin-এর চুরি হওয়া পাসওয়ার্ড দিয়েও না।
• আলাদা লগইন: backup সিস্টেমের লগইন মূল সার্ভার থেকে আলাদা, multi-factor authentication-সহ।
• Restore-এর মহড়া: যে backup থেকে কখনো ফেরত আনা হয়নি, সেটি আছে কি না জানা নেই। নিয়মিত একটি এলোমেলো ফাইল আর পুরো সিস্টেম ফেরত এনে দেখা।

Database-এর বেলায় এই প্রশ্নগুলো — full আর incremental backup, point-in-time recovery, replication-এর ধরন — বিস্তারিত আছে DBMS কোর্সের backup আর replication পর্বে।

Replication আর erasure coding — ডেটা সেন্টারের মাপে RAID

একটি মেশিনের ভেতরের RAID পুরো মেশিন, র‍্যাক বা ডেটা সেন্টার হারানো সামলায় না। বড় distributed storage (পর্ব ৫৩) তাই একই ধারণা মেশিনের স্তরে নেয়:

• Replication: প্রতিটি ব্লকের ৩টি কপি তিনটি আলাদা মেশিনে (প্রায়ই আলাদা র‍্যাকে) — HDFS-এর ঐতিহ্যগত ডিফল্ট। ২টি হারানো সয়, কিন্তু খরচ ৩ গুণ জায়গা। মনে রাখুন, replication ভুল মুছে ফেলাকেও সাথে সাথে কপি করে — এটিও backup নয়।
• Erasure coding: RAID 6-এর সাধারণ রূপ। ডেটাকে k টুকরো করে m টি Reed–Solomon হিসাব-টুকরো যোগ, k + m টুকরো k + m টি আলাদা মেশিনে; যেকোনো k টি থাকলেই সব ফেরত। যেমন ১০ + ৪: যেকোনো ৪টি হারানো সয়, আর জায়গা লাগে ১৪ ÷ ১০ = ১.৪ গুণ — ৩-কপির replication-এর ৩ গুণের অর্ধেকেরও কম। Facebook-এর f4 warm-storage-এর গবেষণাপত্রে RS(১০, ৪)-এর কথা আছে, আর HDFS ৩ থেকে erasure coding যোগ হয়েছে। দাম: একটি টুকরো ফেরত আনতে k টি মেশিন থেকে পড়তে হয়।

SSD-র বিশেষ দিক

• Correlated failure-এর নতুন রূপ: RAID 1-এ দুটি একই মডেলের SSD হুবহু একই লেখা পায়, তাই flash-এর ক্ষয় (wear) দুটিতেই প্রায় সমান গতিতে বাড়ে — দুটি কাছাকাছি সময়ে আয়ু শেষ করতে পারে। আর firmware বাগ একই মডেলের সব ড্রাইভকে একসাথে আঘাত করে — ২০১৯ সালে একটি বড় সার্ভার-নির্মাতা কিছু enterprise SAS SSD নির্দিষ্ট ঘণ্টা চলার পর অকেজো হওয়ার বাগ নিয়ে সতর্ক করেছিল। প্রতিকার: firmware হালনাগাদ, ভিন্ন ব্যাচ বা মডেল মেশানো, আর SMART-এর wear-সূচক দেখা।
• TRIM: file system মুছে ফেলা ব্লকের খবর SSD-কে দেয়, যাতে SSD-র ভেতরের garbage collection সহজ হয় (পর্ব ৪০)। RAID স্তর এই খবর নিচের ডিস্কে পাঠায় কি না, তা implementation-নির্ভর — যেমন Linux md RAID 0/1/10-এ discard পাঠায়, কিন্তু RAID 4/5/6-এ শুধু তখনই, যখন নিরাপদ বলে আলাদাভাবে চালু করা হয় (raid456 module-এর devices_handle_discard_safely). নিজের সেটআপে lsblk --discard দিয়ে দেখে নিন।

১০ · AI-এর যুগে RAID আর স্টোরেজ

স্টোরেজের প্রশ্নে AI-এর একটি ভুল উত্তর মানে ডেটা হারানো। বারবার দেখা ভুলগুলো:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• ধারণক্ষমতা আর সহনশীলতার সংখ্যা নিজে সূত্র দিয়ে (বা এই পর্বের calculator-এ) মিলিয়েছি
• MTTDL-এর হিসাব হাতে আবার করেছি, আর একক (ঘণ্টা, বছর) ঠিক আছে কি না দেখেছি
• কমান্ড আমার OS, distro আর version-এর জন্য কি না — man page (man mdadm) বা অফিসিয়াল ডকুমেন্টেশনে দেখেছি
• ডেটা-মোছা কমান্ড চালানোর আগে ডিস্কের serial মিলিয়েছি, আর পুরো ডেটার backup নিয়েছি
• প্রথমে একটি পরীক্ষামূলক VM-এ বা loop device দিয়ে নকল ডিস্কে পুরো ধাপগুলো চালিয়ে দেখেছি, একটি ডিস্ক “fail” করিয়ে rebuild পরীক্ষা করেছি
• পরিকল্পনায় RAID-এর বাইরে আলাদা backup আছে, আর অন্তত একবার সেখান থেকে restore করে দেখেছি