Every business evaluating a solo operator asks the same question eventually. What happens if Arun is unavailable? It is a fair question. Here is the honest answer.
It started with a disk that looked fine
The server at a Mumbai jewellery manufacturer had been running cleanly for 14 months. No alerts. No complaints. Tally ERP doing its job every morning without fuss.
During a routine monthly check, smartctl -a returned something worth watching: a reallocated sector count that had jumped from 0 to 4 in 30 days. Not a failure. Not even close to a failure. Just 4 sectors the drive had quietly moved aside because they were becoming unreliable.
The client would never have seen this. The monitoring dashboard showed the drive as healthy. The OS was not throwing errors. Tally was opening fine. Everything looked normal.
We ordered a replacement drive, scheduled a Saturday morning swap, and restored from backup onto the new hardware. Total downtime: 2 hours, planned, during a weekend. The old drive failed completely 11 days later during our bench testing.
That is the difference between preventive maintenance and reactive support. One is a planned 2-hour Saturday. The other is a Tuesday at 10am when nobody can open Tally and the accountant is on the phone.
What the monthly maintenance actually covers
The smartctl check above is one item on a structured monthly checklist. Every managed server gets the same review, every month, without exception.
Monthly checklist — every managed server
- Disk health via
smartctl— reallocated sectors, pending sectors, uncorrectable errors - Filesystem usage — root, /var, /home, /tmp — flag anything above 75%
- Backup job verification — last run timestamp, size delta, restore test quarterly
- Security updates — outstanding kernel patches, package updates, CVE scan
- Failed login attempts — auth.log review, brute-force patterns, blocked IPs
- Service health — all critical daemons, systemd unit failures, zombie processes
- Cron job audit — each job ran as expected, no silent failures
- Memory and swap — average utilisation trend over 30 days
- Open ports review — confirm no unexpected listeners since last check
- SSL certificate expiry — flag anything expiring within 60 days
Each check produces a line in the monthly client report. Not a summary. An actual reading — the disk sector count on this date, the last successful backup timestamp, the patch level. If something has changed since last month, it is noted and actioned.
The monitoring never stops
Observium, Nagios, and Cockpit run continuously on every managed server. Alerts fire automatically when thresholds are breached — disk, memory, service availability, backup job failures. The monitoring infrastructure does not depend on Arun being at a keyboard. If something goes wrong at 3am on a Sunday, the alert fires regardless.
Every server is documented
Every managed server has a plain text configuration file and a wiki entry. It covers the server’s full history, installed services, cron jobs, backup configuration, open ports, known issues, and previous incidents with resolutions.
A competent Linux engineer picking up that documentation can understand the environment in minutes, not days. The documentation exists precisely so continuity does not depend on memory or on one person being available.
A backup engineer is available
For hardware emergencies — a failed disk, a server that needs to be physically accessed, onsite break-fix in Mumbai — two engineers are available: Krishna and Sanjay, both Mumbai-based.
Their scope is specific and deliberate. Krishna and Sanjay handle physical hardware. They do not have remote access to client servers. Client data and server configurations are never accessed by anyone other than Arun. This is the correct security boundary for infrastructure management, not a compromise.
The per-client documentation that makes this work is maintained by Arun and updated every month. Every managed server has a plain text configuration file and a wiki entry covering the full server history, installed services, backup configuration, and previous incidents. If a hardware intervention is required, Krishna or Sanjay can be briefed on the physical environment in minutes. No client data is shared in the process.
Retainer clients are notified in advance whenever planned unavailability is expected. For unplanned situations: monitoring continues, the alert fires, and the response path is Arun remotely if reachable, or Krishna and Sanjay onsite if a physical intervention is needed. Clients are not left with an alert firing and nobody to call.
The honest limitation
AV Services is not a 50-person NOC with rotating shifts. If Arun is unavailable and the backup engineer is handling the situation, response time may be longer than the standard commitment. That is the truth.
What will not happen: an alert fires, nobody responds, and a client is left without any path to resolution. The monitoring stays on. The documentation exists. The backup engineer is reachable. The system does not go dark.
Monitoring
Observium, Nagios, Cockpit — always on, alerts fire automatically
Documentation
Per-client plain text config + wiki — any engineer can pick it up
Backup engineer
Krishna and Sanjay (Mumbai) — hardware emergencies only, no remote access to client systems
Field dispatch
Comtech and Source Support — onsite dispatch partners for physical interventions
Questions about how this works for your specific situation?
A 30-minute call covers it. No commitment required.
Book Free Audit WhatsApp Arun