File Service and Shared Storage Cluster Services
The file services your users actually touch every day, made redundant without changing a single path or permission they are used to.
What this usually looks like
All project data lives on one file server. It has been reliable for years, which is exactly what makes the risk invisible until it is not.
- Every share is behind one hostname, and that hostname is one machine.
- Any maintenance requires a scheduled outage that the business negotiates down every time.
- Permissions have drifted for a decade, and nobody can say who can read what.
- Storage growth is visible only as an uncomfortable conversation when the volume fills.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Share, permission and access-path inventory as they exist today
- Permission drift review against intended policy
- Storage growth and quota analysis per project
- Availability review: what happens to open files if the server stops now
Build
One-off delivery: design, code, hardening, handover
- Scale-out SMB or NFS cluster presenting the same addresses and paths
- Backend storage chosen for the estate size — CephFS, DRBD/LINSTOR or replicated block
- Permission model rebuilt and verified, with Windows ACL to POSIX mapping tested
- Data migration with a pre-staged copy and a short final synchronisation
- Quota and audit policy so growth and access are visible per project
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Node failure and maintenance handled without an outage window
- Quota and capacity reporting per share and per project
- Permission and audit review on the agreed cycle
- Backup and restore coverage for file tiers, drilled not just scheduled
- Cluster health, CTDB state and lock monitoring with alerting
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
SMB / Samba
- clustered Samba
- CTDB
- public addresses + failover
- SMB3 encryption
- previous versions / shadow copies
NFS
- NFS-Ganesha
- kernel NFS
- pNFS
- NFSv4 ACLs
- DRBD-backed export with VIP
Backends
- CephFS
- DRBD 9 + LINSTOR
- ZFS with replication
- replicated block on NVMe
Identity integration
- FreeIPA / AD
- winbind / SSSD
- POSIX ACLs
- idmap design
Migration & tooling
- rsync over cluster
- robocopy (Windows estates)
- hash verification
- staged cutover plan
Governance
- per-project quota
- auditd on access paths
- encryption at rest
- WORM / retention tier where required
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- A cluster node can be taken out of service at any time without users noticing, proven by doing it.
- Paths and drive mappings are unchanged after migration — users notice nothing but the speed.
- Permission model is verified file by file against the intended policy on a sampled basis.
- Storage growth is reported per project, with quota alerts ahead of the ceiling.
- A representative file set has been restored from backup and timed.
What we would build, and where the weak point is
The backend is the single point of failure, and the honest answer is that it is the one that matters. Clustering the Samba nodes buys you maintenance without outages; the storage backend is what buys you surviving a failure, and it needs its own failure-domain design.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Out of scope
Document management systems and content workflows
We deliver reliable shared storage. A DMS is an application with its own lifecycle and data model.
- Requires partner
Windows Server cluster roles (SOFS, DFS-R ownership)
We integrate with and migrate from them, working alongside your Windows team rather than replacing it.
- Out of scope
Desktop backup and personal endpoint data
That is endpoint management territory. We will integrate with whatever MDM backs your laptops up.
- Requires partner
Tape archival and media lifecycle for file tier
We include a tape tier in the design if you operate one. We do not run the library.
What it looked like last time
An architecture practice whose 60TB of project data lived on a single file server with permissions that had drifted for a decade: rebuilt as a three-node clustered Samba deployment presenting the same paths, permissions rebuilt and verified, and a migration with no user-visible interruption — with a node-failure test run deliberately during business hours.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the storage systems engineer about your file & block services
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a storage systems engineer: botonwa@gmail.com · +86 130 5181 3099