Linux Server Management Case Studies — AV Services
AV Services has provided Linux server management in Mumbai and across India since 1999. The following case studies describe real scenarios from managed server engagements — anonymised to protect client confidentiality, but accurate in every technical and business detail.
Case Study 1 — 14 Years, 1 Server, Zero Unplanned Downtime: Geeta Engineering Works
Geeta Engineering Works Pvt. Ltd. · Thane · Engineering manufacturer · Active client since 2012
Geeta Engineering Works has been an AV Services client since 2012. One Linux server. Monthly patching. Continuous monitoring. Security reviews. Backup verification. In 14 years, the average incident rate has stayed below 1 per year — and none have resulted in extended downtime.
One incident stands out. During routine monitoring, a RAID array on the server showed a drive had failed silently. The second drive was healthy but running alone. A second failure at that point would have meant total data loss with no recovery path. The degraded drive was identified, replaced, and the array rebuilt — before any data was lost and before the business noticed anything wrong.
That is what proactive management looks like. The incident that never became an incident.
“Associated with AV Services for more than 18 years only due their extremely professional approach.”
— Punit Kasat · 5-star Google review
Verified by: 5-star Clutch review April 2026 · 14-year client relationship on file
Case Study 2 — OS Overwrite Recovery: AR Gold Mumbai · 2024
AR Gold · Mumbai · Jewellery manufacturer · 501–1,000 employees · Active retainer client since incident
AR Gold’s Linux server running ERPNext stopped booting. The in-house IT contact saw the OS boot failure and made a decision that made things worse — he initiated a fresh OS reinstall on top of the broken system, assuming it would fix the problem. It overwrote the existing OS and its data instead. The call came in at 9pm. Arun was onsite by 11pm.
The first action onsite was not recovery — it was protection. Before touching the system, Arun used TestDisk to clone the entire disk image sector by sector to an external hard disk. That clone took the entire night. It meant the disk state at arrival was preserved exactly, regardless of what the repair required.
With the image secured, the repair was methodical. The deleted OS boot sequence was recovered — kernel and initramfs extracted and repaired using a working equivalent. The server booted. ERPNext, Frappe, and the MariaDB database were intact. The repair itself took a few minutes once the disk was safe.
Operations were restored before the first shift the following morning. No production day was lost. The correct market rate for this work is Rs.75,000–Rs.1,50,000. AR Gold became an active monthly retainer client after the incident.
Clone the disk before you touch anything. That one decision is what made the repair reversible.
Active retainer client since incident · Ubuntu 22.04.4 LTS · ERPNext / Frappe + MariaDB
Verified by: active client relationship · fees paid on record
Case Study 3 — SEBI Audit in 6 Weeks: Mumbai Stockbroker, 2022
Mid-size proprietary trading firm — Mumbai — 30–60 employees — Active retainer client since 2022
A Mumbai proprietary trading firm received notice of an internal SEBI compliance audit with 6 weeks to prepare. Their 4 Linux servers — running order management, risk systems, and internal reporting — had never been formally assessed against SEBI’s cybersecurity framework. The firm’s in-house team was trading-focused. Nobody had mapped the servers to CSCRF controls.
The first week was spent on a read-only gap assessment: kernel patch levels, SSH configuration, password policies, audit logging, network segmentation, and backup integrity across all 4 servers. The gap count came to 23 items classed as critical or high under CSCRF. Several were basic — SSH root login enabled, no login attempt alerting, cron-based backups writing to the same server they were backing up.
Remediation ran over weeks 2 through 5. CIS Benchmark Level 1 hardening applied to all servers. Centralised logging configured. Backup jobs redirected to offsite storage with daily verification. Access control reviewed and unnecessary accounts removed. The 23 gaps were closed. A gap closure report was produced — one page per item, before and after, with the change recorded.
The audit raised zero observations against the Linux infrastructure. The firm has been on a managed retainer since, with a quarterly CSCRF review built into the schedule.
23 gaps found. 23 gaps closed. 6 weeks. The audit saw nothing because there was nothing left to see.
Active retainer client since 2022 — Rocky Linux 8 — 4-server estate
Verified by: active client relationship — retainer fees on record — 2022 to present
Case Study 4 — Ransomware Stopped at the Perimeter: Healthcare Diagnostics, Navi Mumbai, 2021
Diagnostic imaging centre — Navi Mumbai — 25–50 employees — Active retainer client since 2019
At 3am on a Tuesday in March 2021, the monitoring alert fired. Fail2ban had already blocked the source IP automatically — a brute-force SSH attempt from a known malicious range, 847 login attempts in 90 seconds. The server held DICOM imaging data for roughly 4,000 active patients. The alert came through. The IP was confirmed malicious, the block was reviewed and made permanent, and an incident report was filed before the first shift started.
The client never knew there had been an attempt until the monthly health report landed in their inbox. That report included a one-page incident summary: what happened, what was blocked, what was done, and what the current status was. No data was accessed. No system was compromised. No downtime occurred.
The follow-up hardening was the more instructive part. The SSH port was moved from 22. Key-based authentication was enforced and password auth disabled entirely. Fail2ban thresholds were tightened. Geographic IP blocking was added for regions with no legitimate access pattern. The same attack vector, tried again, would not have reached 847 attempts — it would have been blocked on the first.
This is what managed monitoring looks like at 3am. The system acted. The record was kept. The client was informed. The gap was closed.
847 attempts in 90 seconds. Blocked automatically. Reviewed, reported, hardened — before the client arrived for work.
Active retainer client since 2019 — Ubuntu 20.04 LTS — DICOM + patient data environment
Verified by: active client relationship — retainer fees on record — 2019 to present
Case Study 5 — E-Commerce Server Down at 11pm: What 847 Days Unmanaged Looks Like
Client: Mumbai-based e-commerce business, 15–40 employees
Server: Single Linux production server, Ubuntu LTS
Situation: Emergency call, website down, no prior management arrangement
The Situation
The call came at 11pm on a Saturday. A Mumbai e-commerce founder — his website was down, orders were failing, and he had no idea how long it had been down. His team had only noticed when a customer complained on Instagram.
The server had been set up two years earlier by a developer who had since moved on. No monitoring had been configured. No patching schedule existed. No one had been assigned responsibility for watching the server after the developer left. The business had grown significantly in those two years. The server had not been touched.
What the Audit Found
Once access was granted and the immediate incident was stabilised, a full read-only audit was conducted. The findings were typical of an unmanaged server after two years in production:
- Kernel unpatched for 847 days. Multiple CVEs with published exploits were open on the server. The kernel version predated several significant security fixes.
- Disk at 94% capacity. Log files had been growing unattended for two years. One large log rotation failure had caused an accelerating disk fill over the preceding three months.
- Backup job silently failing for four months. The cron job was scheduled and appeared active. The destination storage had filled up four months earlier. Every subsequent backup attempt had exited with an error that went nowhere. The business believed it had four months of backups. It had none.
- Three unused open ports. One with a published CVE against the service version running on it.
- No monitoring. No alerts. No one to call.
What Was Done
The immediate incident — website down — was resolved within two hours of the call. The root cause was the disk reaching capacity and the web server failing to write logs, causing it to stop accepting requests.
Over the following week, with the client on retainer, the server was brought to a managed baseline: kernel patched, packages updated, disk cleaned and monitored, backup destination replaced and tested, open ports reviewed and unnecessary ones closed, monitoring configured with alerts to a dedicated channel.
The Cost
The client calculated the cost of that Saturday night — lost orders during the downtime window, emergency recovery work, and the time spent by the founder and two team members managing the crisis — at more than six months of what a managed retainer would have cost. The server had been running unmanaged for two years. The cost of that single incident exceeded the cost of two years of management.
The client has been on retainer since. In the two years since that Saturday night, there has been one incident — a hardware failure on the hosting provider’s side, resolved within the provider’s SLA, with no data loss because the backup was current and verified.
Case Study 6 — Backup Job Running for 97 Days, Zero Valid Backups
Client: Mumbai professional services firm, 10–25 employees
Server: Single Linux server running CRM and document management
Situation: Free audit requested after reading about backup risks
The Situation
The client contacted AV Services after reading about the risk of backup jobs that run but do not actually produce valid backups. They were confident their backup was working — the cron job had been running nightly for over three months — but they wanted a second opinion before their annual IT review.
What the Audit Found
The backup cron job was scheduled correctly and ran every night at 2am. The log showed it completing. The backup folder existed and contained files with the correct naming convention and approximately the right file sizes.
None of the backup files were valid.
A software update 97 days earlier had changed the backup utility’s output format. The backup job continued running and producing files — but the files were incomplete output from a failed process, not valid backups. The file sizes were plausible because the partial output was large enough to look right without being checked. No checksum verification had been configured. No restore test had been run since the utility was updated.
The client had 97 days of backup files and zero valid backups. If the server had failed that morning, there would have been no restore path.
What Was Done
The backup configuration was corrected immediately. Checksum verification was added to every backup job. A restore test was performed on a clean environment — confirming the new backup was valid. A monitoring alert was configured to trigger if the backup age exceeded 25 hours, ensuring any future failure would be caught within one cycle.
The client joined the retainer. Monthly backup verification — not just scheduling, but confirming the output is valid and restore-tested — is now a standard item in the monthly health report.
Ready to hand this over?
AV Services manages this for Mumbai businesses on monthly retainer since 1999. Start with a free 30-minute call — no access needed, no commitment.
⚡ Check Your Risk Book Free Audit → 🚨 Emergency ResponseFeatured Case Study
OS overwrite on a production ERPNext server. Full recovery before the first morning shift. Read the full breakdown.
Read AR Gold Case Study →Ready for a Retainer?
See monthly retainer plans and pricing for ongoing Linux server management.
View Pricing →