The worst backup failure is not the loud one. A job that crashes with an error gets noticed within a day. The dangerous ones carry on reporting success, or stop reporting at all, while the copies they produce are incomplete, unreadable or stale. You find out when you need to restore, which is the most expensive moment to learn anything.

This guide walks through the ways CRM backups typically go wrong, how to recognise each, and the small set of checks that catches nearly all of them.

Silent Failure Mode One: The Job Stopped Running

Schedulers fail. A server gets rebuilt without recreating the job, a service account is disabled, a maintenance change pauses the schedule, or the machine that ran the job is retired. Because nothing runs, nothing reports an error, and a dashboard that only shows failures looks reassuringly empty.

The defence is to alert on absence. Instead of only asking “did a job fail?”, ask “did a successful backup complete in the last expected interval?” If not, raise an alarm. This single inversion catches an entire class of problems.

Silent Failure Mode Two: The Job Runs but Captures Too Little

A backup may succeed technically while missing important pieces. Typical examples include a database backed up but not the attachment storage, a new database or schema added after the job was designed, configuration files and encryption keys left out, or custom code and integration settings living on a server nobody included.

Maintain an explicit inventory of everything the CRM needs in order to be rebuilt, and compare it against what the backup actually contains. Review it whenever the system changes. A good question to ask after any change is: if this server vanished, what would we lose?

Silent Failure Mode Three: Space and Time Run Out

As data grows, backups take longer and need more room. Eventually one of two things happens. The destination fills, and the job fails or truncates. Or the job begins to overrun its window, colliding with the next run or with morning business, and gets cancelled by a timeout or by an operator.

Track backup duration and size as trends, not just pass or fail. A job that took a modest time last quarter and now takes several times as long is telling you something, long before it breaks. Alert on destination free space well in advance, and remember that copies kept for retention accumulate.

Silent Failure Mode Four: Credentials and Permissions Expire

Backup jobs depend on accounts, passwords, API tokens and keys. Passwords rotate, tokens expire, certificates lapse, and a permission quietly changes during a security tightening. The job then fails, or in worse designs succeeds partially.

Document every credential a backup depends on, with its expiry or rotation date, and put those dates in a calendar. When you change a password policy, check backup accounts deliberately. Encryption keys deserve special care: an encrypted backup whose key is lost or sits only on the failed server cannot be restored, and no amount of storage will save it.

Silent Failure Mode Five: The Backup Is Corrupt or Unrestorable

Files can be written yet unusable: a transfer interrupted midway, a snapshot taken while the database was mid-write without proper consistency, storage faults, or a backup that depends on an earlier backup in a chain that has since been pruned.

Verification partly addresses this. Many tools can check integrity after writing, and you can compare sizes and checksums after copying. But the only proof that a backup works is restoring it. That is not paranoia; it is the definition.

Silent Failure Mode Six: Backups Share the Fate of the System

If backups live on the same server, the same storage array or the same account as the live system, a single event can destroy both: hardware failure, ransomware, an accidental deletion, or a compromised administrator login. Keep at least one copy elsewhere and, where your tooling allows, protect it from being altered or deleted by the same credentials that run production. Check your vendor’s current documentation for immutability or retention-lock features.

Checks That Catch It

Check	What it catches	How often
Alert if no successful backup within expected interval	Stopped schedules, disabled accounts	Continuous
Job duration and size trend review	Growth, overruns, truncation	Weekly
Destination free-space alert	Full storage	Continuous
Inventory comparison against backup contents	Missing databases, files, keys	After every change, quarterly review
Credential and certificate expiry calendar	Expired access	Monthly review
Integrity verification after write	Corrupt files	Every backup
Test restore to an isolated environment	Everything above, including unusable copies	Regularly, on a schedule you keep
Offsite or protected copy review	Shared-fate losses	Quarterly

A Hypothetical Example

Imagine an administrator who checks the backup dashboard every morning and sees only green. One day, preparing for a planned upgrade, they perform a test restore into an isolated environment as part of the change checklist. The restore fails: the most recent backups are zero-length files. Investigation shows the destination volume had filled some weeks earlier, and the tool reported the job as completed because the command itself returned normally.

Nothing was lost, because the problem was found before any incident. The fixes were simple: clear and resize the storage, alert on free space and on files below an expected size, add a check that compares each new backup’s size to the recent trend, and put a recurring restore test in the calendar. The most valuable change was the cultural one. The dashboard was no longer treated as proof.

Build a Routine You Will Keep

Choose a small restore test you can repeat cheaply: restore the latest backup to an isolated environment, start the application, and confirm a few known records and attachments are present. Do it on a schedule, record the date and result, and treat a missed test as a finding. Combine it with your staging refresh if you have one, so the exercise earns its keep twice.

Frequently Asked Questions

If my backup software says success, can I trust it? Not completely. Success usually means the process finished without a detected error, not that the output is complete and restorable. Pair status with size checks, integrity verification and periodic test restores.

How often should we test restores? Often enough that you would catch a silent failure before it matters, commonly monthly or quarterly depending on how critical the CRM is, plus after significant changes to the system or backup setup.

What should we do if we find our backups are bad? Take a fresh backup immediately by a reliable method, preserve any older copies that might still be usable, then investigate the cause and fix it before relying on the schedule again. Record what happened so it informs future checks.

Are cloud-managed backups immune to these problems? No. Managed services reduce some risks, but you still need to confirm what is covered, how long copies are kept, whether restores work as you expect, and who is responsible for each part. Read the provider’s current documentation and test.

Who should monitor backups? A named owner with a deputy, supported by automated alerts that reach more than one person. A check that depends on one individual’s memory is itself a single point of failure.

Next Step

Do one test restore this month. Restore the latest backup to an isolated environment, open the application and find three records you know should be there. Whatever the outcome, you will know more than the dashboard has ever told you.