We place so much faith in backups to recover from all kinds of critters that clobber our data or simply wipe it out- some malicious (ransomware), others accidental (clumsy people).
But is our trust misguided?
What’s to say that our backups have not been tampered with as well? There’s really only one way: make them immutable.
Immutable vs. WORM Backups
And if immutability is the solution, why not do that for the data in the first place? Because then you couldn’t make any changes to it. Every file would turn into a WORM (Write Once Read Many) object.
WORM spreadsheets and WORM documents lead a pretty dull existence. A one-time record never to be updated again. Who wants that?
On the other hand, a WORM backup is a wonderful thing. Especially if it’s a backup of THE spreadsheet your finance team has been compiling for the last three weeks and someone or something just corrupted it.
That WORM backup suddenly becomes a life safer. Let’s look at Julie, a fictitious administrator, who is showered with praises for restoring that spreadsheet a few hours before the end-of-quarter results were expected by the executive team.
In a parallel universe, this scenario could have had an alternate, arguably much darker ending. A junior administrator, let’s call him Ricky, might have been put in charge of recovering the WORM backup. Rather than recall and restore it, Ricky unintentionally deleted it. Yikes!
Surprise, WORM does not prevent deletion, only overwriting.
Which brings us to object locking. That’s WORM with special powers. Immutable powers. No updates, no deletion, unmodifiable, undeletable – even if you wanted to.
Object Locking Backup Strategy
If this fictional organization had been fortunate (and clever) enough to have used object locking on their backup strategy, Ricky wouldn’t be seeking a new job right now. The system would have prevented him from mistakenly removing the last known good copy of the spreadsheet, and he too would be a hero.
It would be tedious to apply object locking manually to backups, so in practice it is done programmatically. Object locking is performed by the object storage system, say DataCore Swarm, under the direction of the backup software, for example, Veeam Backup & Replication.
In a typical workflow, with a Veeam Scale-Out Backup Repository (SOBR), Veeam software makes a backup of the file on fast, local primary storage, such as provided by DataCore SANsymphony software. This is referred to as the Performance tier. Then it places a second copy on the lower cost, scalable Capacity tier provided by Swarm. Making this secondary copy immutable through object locking.
Should the first backup get corrupted or deleted, you can restore the immutable version directly from the Swarm object storage, and resume where you left off.
And that my friends, is a happy ending.
P.S. I’ll bet you’re curious how you get rid of files that are so locked down. Object locks can include an expiration date, after which files are eligible for removal. Be generous with those dates. Better to eat up a little space on disk, than find yourself without a fallback.
Learn more
DataCore Swarm object storage has been verified as a “Veeam Ready – Object” and “Veeam Ready – Object with Immutability” solution by Veeam® Software. See announcement here for more information.
