The backup world is, to use a quaint colloquialism, “arse about face“. So much of the talk in the backup world revolves around backup, when it actually should revolve around recovery.
It’s not that we don’t care about recovery – it’s just we often consider data protection in terms of “backup”, when in actual fact that’s just the means, not the end.
For this reason, I periodically see sites where backup failures are allowed to go on for sometimes weeks – sometimes, even, months – because “it’s just a backup”, or “it’s probably not important”, or some other such reason. Now, long-term readers would know that I prescribe zero error policies, but sometimes getting traction for zero error policies is difficult. So, we need to rename “backup failure”.
You see, in reality, it’s not really a “backup failure”, and while we call it a “backup failure”, anyone who is busy will think that it just means we wait for the next backup, or assume that it’s a minor problem. Let’s instead call it by what it really is:
an unrecoverable backup
I’ve been testing this out recently, and when I’ve talked to people in the past about “backup failures”, they’ll admit there’s risk involved but tend to shrug them off, hoping for the best. However, when I’ve started talking about “unrecoverable backups”, the squirming starts. It creates a slight sense of panic in the eyes, or a heightened need to check status emails, etc.
So, that’s my tip for today – there’s no such thing as a “backup failure”, it’s an “unrecoverable backup”. And if you think about it as an “unrecoverable backup”, and you talk about it within the company as an “unrecoverable backup”, it’ll get the attention, priority and budget it requires.