Home / Knowledge hub / Backup integrity
Knowledge hub
Backup integrity
Knowing your backups are complete, untouched and actually restorable.
What it means
Backup integrity means your backups hold what you think they hold, have not been altered or deleted, and can be restored. A backup job that reports success has proved only that it ran. It has not proved that the data inside is complete, readable or safe.
Integrity covers three things: completeness, so nothing important is missing; protection, so nobody can tamper with or erase the copies; and restorability, shown by actually restoring. A backup you have never restored is a hope, not a control. Most failures stay hidden until the day the copy is needed, which is why the check has to happen early and on a schedule.
Why it matters
Attackers know backups are the way out of a ransomware demand, so they go after them. If your backup system shares credentials with production, the same break-in that encrypts your servers can wipe your copies. Then the only choice left may be to pay or to close.
Quieter failures are just as common: a job that has silently failed for months, a backup that omits uploaded files, or corruption copied from the source. You discover each one on the worst day. A tested backup is the difference between a bad week and a lost company.
How it shows up
Keep several copies, at least one offsite and one that cannot be changed, such as storage with object lock or an offline copy. Give the backup system separate accounts and multi-factor authentication. Use checksums, monitor job results, and alert when a backup is missing or unusually small.
Most of all, restore. Pick a backup at random each quarter, restore it to a clean environment and check that the application works. Record how long it took, to compare with your recovery time objective. Include backups in your ransomware planning.
Questions people ask
Backup integrity, answered
What is the 3-2-1 backup rule?
Keep three copies of your data, on two different types of storage, with one copy offsite. It is a long-standing rule of thumb.
Many teams add an immutable or offline copy to the list, because of ransomware.
What is an immutable backup?
It is a copy that cannot be changed or deleted for a set period, even by an administrator account. Cloud object lock features and write-once media do this.
It protects against both attackers and accidents.
How often should we test restores?
Regularly, and at least every quarter for critical systems, plus after changes to the backup setup. Restore the data and check the application can use it.
A test that only checks the file exists is not enough.
Can backups contain malware?
Yes. If an intruder was already inside before the backup was taken, the copy may contain what they planted.
Keep several restore points and scan before bringing a backup back into service.
Should backups be encrypted?
Yes. Backups often hold the full contents of the database, so a stolen one is as bad as a breach. Protect the keys separately from the data.
Make sure you can still recover the keys during a disaster.
Sources
Where this comes from
Related
Terms that sit next to this one
Disaster recovery
The plan and tools for restoring systems and data after a major failure.
Ransomware
Malware that locks your data and demands payment to unlock it.
Recovery point objective
The most data, measured in time, you can afford to lose.
Encryption at rest
Stored data scrambled so a stolen disk is useless without the key.
Separation of duties
Splitting a sensitive task so no single person can complete it alone.
Have you ever restored one?
A backup limits the damage after a break-in. Cyberlop looks for the exploitable flaws that let one happen, and proves each with a request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.