Prove You Can Recover: The Backup Metric That Lies

Most GP shops track one number for their backups, and it’s the wrong one. The number is “backups are running.” It’s green on a dashboard, it satisfies whoever asks about the compliance checkbox, and it lets everyone sleep. It’s also worth almost nothing on its own, because a backup that’s never been restored isn’t a recovery plan — it’s a hope with a timestamp. The gap between “backups are running” and “we can actually get GP back” is exactly where organizations discover the truth at the worst possible moment: the backup was corrupt, or incomplete, or restorable as a database but not as a working GP environment.

The right number is different, and it’s a sentence rather than a status light: we restored one this quarter, and GP came up clean. That sentence is either true right now, or it isn’t — and for most shops, it isn’t, because nobody’s actually tried.

Why This Gets Worse, Not Better, as GP Ages

This has always mattered. It matters more with every year past 2029. Through December 31, 2029, Microsoft is still shipping updates. Through April 30, 2031, critical security patches still land. After that, a perpetual-license shop can keep running GP indefinitely — but there’s no support line to call at two in the morning when a restore goes sideways. Once the vendor’s safety net comes down, your own recovery discipline is the only net left. The recoverability you’ve actually proven today is the recoverability you’ll have when nobody’s behind you.

That reframes what a backup strategy is for. It stops being a compliance line item and becomes one of the last things standing between a bad day and a genuinely bad year.

What “Backed Up” Actually Has to Cover

The most common backup failure in a GP shop isn’t a bad backup job — it’s an incomplete picture of what GP actually is. GP isn’t one database. It’s a system database, a set of company databases, several SQL infrastructure databases, and a pile of files that live outside SQL entirely: modified forms and reports, signature files, ISV components, and — for shops that predate the modern attachment feature — a whole share of file attachments that a database-only backup silently loses. Add encryption to the picture and there’s a fourth piece: if any database uses Transparent Data Encryption or the backups themselves are encrypted, the certificate and keys have to be captured and stored separately, or a complete backup history restores to exactly nothing.

None of this is exotic. It’s just easy to miss piece by piece, and a backup plan built around “the company databases” rather than “everything GP actually depends on” looks complete right up until the day it isn’t.

The other half of the picture is the one almost nobody documents at all: recovering the data only gets you halfway there. A restored database dropped onto a bare server, or onto a GP install missing the right build number or the right add-ons, isn’t a working system — it’s a set of tables nobody can log into. The record of how your specific GP environment is actually assembled — exact build number, every ISV and its install order, the service accounts, the SQL collation, the install media itself — is a separate document from the data backup, and it’s the one that determines whether a rebuild takes an afternoon or becomes an open-ended project. Write it once, keep it current, and store it somewhere the data backups don’t solely live.

The Discipline That Actually Proves It: Restore Something

Everything above is table stakes. This is the piece that separates a recovery plan from a recovery hope, and it’s the one almost everyone skips.

A restore test isn’t checking that a backup file exists. It’s taking a real backup, restoring it to an isolated instance, and bringing GP up against it as though it were the real thing — logging in, posting a test transaction, running a report, opening an attachment if you keep them. That single rehearsal tests three separate things at once: that the backup is readable, that it’s complete, and that GP will actually run on it. Skip the drill and you don’t know the answer to any of the three; you only know the backup job didn’t error out last night, which is a much smaller claim than it sounds like.

Do this quarterly, and time it. The elapsed span from “backup in hand” to “GP open and verified” is your real recovery time — not the number in a policy document, and it’s almost always longer than people expect. That gap between the assumed number and the measured one is worth knowing before an actual outage forces the comparison. And run the drill from written instructions, ideally with someone other than the person who usually handles backups running it, because a restore that only succeeds when the expert is in the room hasn’t proven the backup — it’s proven the expert, and the expert is exactly the person this whole exercise should assume might not be available.

If your shop keeps a test or training environment, this drill and its upkeep are the same task. The restore you were going to throw away is a freshly refreshed copy of production, which is exactly what a stale test environment needs — so point the quarterly restore into that environment where possible, and one afternoon proves the backup and refreshes the environment at the same time, rather than being two separate chores nobody has time for.

The Bottom Line

“Backups are running” and “we can recover” are two different claims, and only a rehearsal tells you which one is actually true. That’s the whole argument here — not a call for more backup jobs, which most shops already have, but for the one habit that turns a hope into a proven fact: restore something, on a schedule, and watch what breaks while it’s still a drill and not a crisis.

Every year past 2029 raises the stakes on that habit without changing what it takes to build. Pick your single most important company database, restore it to an isolated instance this month, and time how long it actually takes to bring GP up clean. Whatever you learn will matter more than a year of green dashboards — and it’s the only way to know, before you need to know it, whether the sentence you want to say on your worst day is actually true.