Backups: a lifeline or a false sense of security?

 

SPOILER: The first time you discover that your backup does not work is often when you really need it. By then, it is too late.

31 March is World Backup Day, a good opportunity to reflect on an uncomfortable truth: backups are often less reliable than we think. Many organisations depend on them but rarely test whether a restore actually works. Fortunately, there are smart ways to ensure you can always recover, without surprises. We spoke with four of our experts about their views on backups:

• Bert Jan Meinders, Platform Consultant
• Johan Buijser, Oracle Database Consultant
• Herman Buitenhuis, Oracle Database Administrator
• Jeroen Gouma, Senior Technical Consultant

Their insights show that a backup is just one piece of a sound recovery strategy. What do they consider the biggest misconception about backups? And how can you ensure a restore runs smoothly?

Many organisations treat backups as their first line of defence against data loss. But that is a misconception. A backup is simply a tool to support rapid recovery. Bert Jan explains: “Contrary to what many people, including IT auditors, think, a backup is not an end in itself. The goal is to recover quickly when problems occur. If that is not possible, a restore is needed. And a backup is a useful, perhaps the right, tool for carrying out that restore.”

This also means that a backup is not always the best option. Johan highlights alternatives such as flashback and rollback technology and geo-redundant replication, which are often faster and more efficient: “I see a backup as a last resort. I prefer techniques that can quickly reverse changes or continuously maintain a copy at another location. That avoids having to restore an entire database.” An effective recovery strategy therefore goes beyond simply creating backups.

Creating a backup is one thing; knowing it will work when needed is another. Herman shares a telling example: “In the late 1990s, a customer had a state-of-the-art backup solution with robotic tape libraries and advanced systems. When a restore was needed for the first time, a faulty tape drive turned out to have rendered every backup useless. No one had ever tested whether the backups actually worked.”

This remains a problem today. Bert Jan sees companies creating backups but rarely checking whether they are usable: “Oracle offers a function to test whether a restore is possible, but because it takes time and resources, this is often skipped. Organisations only discover that their backups are corrupt or unusable during a real incident.”

Regular testing is therefore essential. Jeroen puts it plainly: “Testing is absolutely necessary, because failure is not an option. If your backup cannot be restored, you are out of business.”

Restoring from a backup is rarely as simple as pressing a button. Dependencies and practical challenges often arise. Johan describes a case where a customer accidentally deleted critical data: “The customer only discovered it shortly before the backup retention period expired. We had to perform a full restore on a separate system, then export only the deleted tables to CSV. All under intense time pressure, with limited capacity and without affecting the production environment.”

And what if the restored data is part of a wider process chain? Jeroen warns: “Restoring a backup will hopefully bring your data back online, but how do you get the whole chain back in sync? If the inventory database still thinks there are 100 bags of plaster in the aisle after a restore, how do you check whether that reflects reality?” Backups are therefore only one part of a broader business continuity strategy.

Alongside a sound backup policy, hardware is crucial. Herman shares a costly lesson from practice: “On a project involving around 40 developers, the server crashed because of a failed hard drive. The hardware supplier sent a replacement, but the courier was not authorised to install it. We had to wait for a system administrator, who was only available at the end of the day. My backup was ready, but that made no difference while the hardware was down. We lost a day’s productivity. The lesson? A good hardware support contract is just as important as your backup strategy.” 

Some organisations retain backups for years, forgetting that they may no longer be usable. Bert Jan warns: “I have seen companies keep backups for five to ten years, only to find they can no longer restore them because the software has moved on by four versions.” If long-term storage is needed, a separate archive is often a better solution. 

An effective backup strategy requires more than storing data. Without testing and a recovery plan, a backup has little value. These are our experts’ key lessons for getting your recovery strategy in order:

• Treat backups as a last resort, rather than your first line of defence.
• Regularly test whether a restore actually works.
• Use replication and flashback for faster recovery.
• Have a sound recovery plan that includes hardware and synchronisation across connected systems.
• Remember that a backup is not an archive.

As Herman neatly sums it up: “A database without a backup is not a database. And a backup without a restore test is not a backup.”