AV Services · avservices.in · Mumbai, India
A Backup You Have Not Tested Is Not a Backup
This is the sentence that every system administrator knows and that most businesses learn too late.
The backup job runs every night. The green tick appears in the dashboard. The file is written to the destination. Everything looks correct. And then the day comes when the restore is needed — a disk failure, a ransomware infection, an accidental deletion, a database corruption — and the restore fails. The file is incomplete. The destination ran out of space six weeks ago and the job has been writing zero-byte files ever since. The backup format changed after an application update and nobody tested whether the new format restores cleanly. The credentials used by the backup job expired and the job has been silently failing for two months.
In 25 years of Linux infrastructure management, AV Services has encountered every one of these failure modes. Not in theoretical scenarios. In real production environments, at the moment a business needed their data back and discovered that what they believed to be a working backup was not.
The purpose of this page is to explain precisely what backup and recovery management means when it is done correctly — and what the difference is between a backup configuration that exists and a backup configuration that works.
What Most Businesses Actually Have
Most businesses running Linux servers have some version of the following: a backup script or tool configured at some point during the server setup, writing to some destination, running on some schedule, with no monitoring of whether it succeeds, no testing of whether the output restores, and no documentation of what the recovery procedure is if everything goes wrong.
This is not negligence. It is the natural result of backup configuration being a setup task rather than an ongoing discipline. The person who configured the server set up backups because backups are important. They moved on to the next task. Nobody was assigned the ongoing responsibility of verifying that the backup continues to work as the environment changes around it.
The environment always changes. Storage fills. Credentials expire. Application updates change data formats. New databases are added that the backup script does not know about. Directories are restructured. The backup that was comprehensive at setup becomes partial over time, quietly and invisibly, without anyone noticing.
What Proper Backup Management Covers
Backup configuration review. Every engagement begins with an assessment of the current backup configuration — what is being backed up, what is not, where it is going, how much retention exists, and whether the configuration covers the full scope of what the business actually needs to recover. Gaps are identified and addressed before they matter.
Remote destination verification. Backups that write only to the same physical disk as the primary data are not backups. A disk failure — the most common cause of data loss in production environments — destroys both simultaneously. AV Services ensures backup destinations are genuinely separate from primary storage — a remote server, an object storage bucket, an offsite location — so that a single hardware failure cannot eliminate both the data and the means of recovering it.
Automated backup monitoring. Every backup job is monitored for successful completion. Not assumed to be running correctly. Monitored — with alerts that fire when a backup fails, when a backup produces an unexpectedly small output, when a destination is filling toward capacity, or when the backup has not run within its expected window. The green tick is verified, not assumed.
Monthly restore testing. This is the discipline that separates backup management from backup configuration. Every month, AV Services performs a test restore from the most recent backup — a real restore to a test environment, verifying that the data is intact, complete, and usable. The restore test result is documented in the monthly health summary. The client knows, with certainty, that their backup works — because it was tested last month and it worked.
Retention policy management. Backups without a retention policy accumulate indefinitely. Storage fills. When storage fills, backup jobs fail. When backup jobs fail silently, the most recent successful backup becomes progressively older. A retention policy defines how many days or weeks of backups are kept, automatically removes older backups to maintain available space, and ensures the backup destination is managed as a long-term system rather than an indefinitely growing archive.
Documentation of recovery procedure. A backup is only as useful as the procedure for using it. AV Services documents, for every client environment, the complete recovery procedure — what to restore first, in what order, what dependencies exist between services, how long a full recovery is expected to take, and who needs to be involved. This document is reviewed and updated whenever the environment changes. It exists so that recovery is a procedure, not an improvisation.
The Scenarios This Protects Against
Hardware failure. Disks fail. SSDs fail. RAID arrays fail in ways that are not fully redundant. Cloud storage volumes become unavailable. When the hardware that holds your data fails completely, a verified remote backup with a documented recovery procedure is the difference between a two-hour recovery and a permanent loss.
Ransomware and malicious encryption. Ransomware that encrypts a server also encrypts any backup destination that is directly mounted or accessible from the infected system. A properly configured backup architecture uses destinations that are write-accessible for backup jobs but not browsable or mountable from the primary server — so that a compromise of the server cannot reach the backup. AV Services configures backup destinations with this attack vector in mind.
Accidental deletion. Developers delete things they should not. Scripts run with unintended scope. Database truncations happen. These are not hypothetical — they happen in every organisation that has been running long enough. A backup with sufficient retention — daily backups kept for 30 days, for example — means an accidental deletion discovered a week later is recoverable. A backup with three days of retention is not.
Database corruption. Application bugs, interrupted writes, and storage anomalies can corrupt database files in ways that are not immediately visible. A corrupted database that has been running for two weeks has potentially overwritten two weeks of backup history with corrupted data. Backup strategies for databases require specific approaches — logical dumps rather than file-level copies, in many cases — that ensure the backup contains consistent, restorable data rather than a copy of a corrupted state.
Compliance and audit requirements. Certain regulated industries and international data handling frameworks require demonstrable data retention and recovery capabilities. A documented backup and recovery process, with monthly test restore records, provides the evidence trail that compliance audits require.
Recovery Time and Recovery Point
Two numbers define the practical usefulness of a backup configuration. Recovery Time Objective — how long the recovery takes — and Recovery Point Objective — how much data is lost between the last backup and the moment of failure.
A daily backup with a one-hour recovery time means that in the worst case, you lose up to 24 hours of data and are back online within an hour of starting the recovery. Whether those numbers are acceptable depends entirely on your business. An e-commerce platform processing continuous transactions has different requirements than a documentation server updated weekly.
AV Services establishes these numbers explicitly for every client environment — not as aspirational targets but as verified capabilities, confirmed by the monthly restore testing that forms part of every retainer. You know your recovery time because it has been measured. You know your recovery point because the backup frequency is documented and the job completion times are logged.
This is what it means to know your backup works. Not to believe it works. To know.
If You Do Not Know Whether Your Backup Works
If you are reading this and are not certain whether your current backup configuration is complete, whether the restore has been tested, or whether the recovery procedure is documented — that uncertainty is the answer to the question.
A backup that has not been tested should be assumed to be unreliable until it is tested and confirmed otherwise. The cost of that assumption, if it turns out to be correct at the moment it is needed most, is data that cannot be recovered and a business that cannot easily be rebuilt.
The infrastructure audit that AV Services offers as a first step covers backup configuration as a primary assessment area. Within five business days, you will have a precise picture of what your backup configuration covers, what it does not, whether the destination is appropriate, and what the current state of your recovery capability actually is.
That knowledge costs nothing to obtain. The cost of not having it is bounded only by how much your data is worth.
Contact
Email: arun@avservices.in
Website: avservices.in
Book a free Infrastructure Audit: arun@avservices.in
AV Services · avservices.in · Mumbai, India Linux Infrastructure Care & Maintenance Since 1999 Backup Configuration · Remote Storage · Monthly Restore Testing · Recovery Documentation