Enterprise storage & data protection — from the operations floor
I’m Mohit Saraswat — a storage and backup specialist since 2019. I keep enterprise arrays, backup estates and disaster-recovery plans alive, and I write the field notes nobody publishes: the restore drills, the capacity fights, and the 3 a.m. decisions.
Based in India · working with teams worldwide · location is no constraint · Vendor-neutral writing
The three areas this work lives in. Each is organised around the same question: could you actually recover, tonight, under pressure?
Backup dashboards glow green right up to the restore that matters. This area of practice is about the gap between “jobs completed” and “business recovered” — designing restore drills, checking evidence, and treating recovery as a tested capability rather than a policy document.
Arrays rarely fail loudly — they drift. Latency percentiles creep, rebuild rates sag, port errors accumulate one by one. This is the day-to-day discipline of noticing that drift early: health evidence packs, capacity curves, and change-window readiness before any of it becomes an incident review.
Plain-English explanations of what changes operationally, what doesn’t, and what it costs — drawn from the floor, not the keynote stage. Field notes, runbooks and drill documentation that a team can actually run from.
“A backup job that completes tells you data left the building. It says nothing about whether it can come back.”
The rule behind the work
The Backup Central model, in my lane: learn it in public, prove it in the field, write it down plainly. Tap a title to read the opening.
Every backup dashboard I’ve ever seen glows green. The restores are where environments go to die.
A backup job that completes tells you exactly one thing: data left the building. It says nothing about whether that data can come back — intact, in order, inside the window your business actually needs. The gap between those two statements is where careers in storage are made, usually at 3 a.m.
This essay is about closing that gap on purpose: scheduled restore drills, application-consistent checks, and why the most valuable meeting in IT is the one where you prove, out loud, that last night’s backup can rebuild the business by lunch.
Full essay — placeholder in this mockup
Snapshots live on the same array, under the same admin credentials, one bad command away from the data they’re meant to protect.
Every few years the industry rediscovers this the hard way. A snapshot is a recovery point measured in seconds; a backup is a recovery point measured in independence — different failure domain, different blast radius, ideally different credentials.
On the 3-2-1 rule, why ransomware changed the definition of “isolated”, and the uncomfortable audit question you should be able to answer before your auditor asks it.
Full essay — placeholder in this mockup
Five nines is 5.26 minutes of downtime a year. Nobody who asks for it has priced the maintenance window it forbids.
Availability numbers get quoted in procurement meetings like weather. But every nine you add removes a class of things you’re allowed to do: no leisurely firmware upgrades, no “we’ll patch it Sunday”, no single-person knowledge of how the failover works.
A walk through the arithmetic of uptime, the hidden line items — spares, rehearsals, on-call depth — and how to have the honest version of this conversation with the business before the contract is signed.
Full essay — placeholder in this mockup
The script’s job isn’t to replace the engineer. It’s to remember what the engineer knew at 2 p.m. so nobody has to reconstruct it at 2 a.m.
Most storage automation fails socially before it fails technically: a script nobody trusts gets bypassed, and a bypassed script is worse than none. The automation that sticks is boring — health checks, evidence collection, the pre-flight list before a change window.
Notes from years of Python and shell glue in production environments: what to automate first, what to never automate, and how to write the runbook the script quietly becomes.
Full essay — placeholder in this mockup
Spreadsheets say the array fills up in November. They don’t say which team’s retention policy quietly doubled in March.
Every capacity crisis I’ve worked was visible in the trend line a year early — and invisible in the meeting where it mattered, because the growth belonged to a project nobody had told storage about. Capacity planning is mostly intelligence work: knowing what’s coming before it lands on your LUNs.
How to build the growth conversation into change management, why dedupe ratios lie politely, and the one chart worth putting in front of finance.
Full essay — placeholder in this mockup
Arrays rarely fail loudly. They drift — a latency percentile here, a fan curve there — and the alerts you set never fire because nothing crossed a line.
Threshold monitoring answers “is it broken?” The more useful question is “is it becoming broken?” Latency distributions, rebuild rates, port error counters trending the wrong way for six weeks: the signals are all there, filed under dashboards nobody opens.
A field guide to drift detection with the tooling you already have, and the weekly fifteen minutes that prevent the quarterly incident review.
Full essay — placeholder in this mockup
I’m Mohit Saraswat, a storage and backup specialist based in India. I’ve worked in enterprise infrastructure since 2019 — running backup and recovery operations, storage estates and disaster-recovery programmes for large organisations, first with services firms and now as a resident engineer embedded with an enterprise customer.
Day to day that means all-flash arrays, file and block estates, data-protection platforms and replication — the unglamorous layer everything else stands on. I’m based in India and work with teams wherever they are; the work has never really cared which room the array sits in, and neither do I.
This site follows the practitioner model: learn in public, prove it in the field, and keep the writing vendor-neutral — positive about the work, honest about the trade-offs, silent on customer-confidential detail.
I send an email when I have something worth sharing — roughly once a month: an essay, a field note, a drill checklist. No schedule, no noise.