I agree that's what he meant, but it's just interesting to me that for the known hard task he took something that also comes with danger. Exactly the feeling that I get when I think about restoring backups.
Well, one of the things about testing backups is that (if you are doing it remotely right) it reduces the danger when you need to actually restore.
A widely accepted method fur judging at least subjective risk when there are insufficient facts for truly objective measure is to ask how much you would bet on various outcomes - such as whether P=NP is solved before New York's 2nd. Ave. subway is completed.
Digging through a mountain actually doesn't have to be dangerous. Assuming modern methods, how dangerous it is depends on how many resources are spent on the process.
So, in a sense I think that part captures the problem. People object to testing backups using the logic of "with our shitty processes, it will be dangerous". I suppose you have companies with a logic akin to "due to being cheap arrogant, we have shitty processes" -> "due to shitty processes, our processes are fragile" -> "due to being fragile, we avoid anything that would stress our system" -> "due our system not being able to take stress, we just pay ransomware instead of stressing system with a backup".
It seems like we've reached to "throw-away enterprise" level. Build it cheap until it breaks, then walk away when the fix cost is too high. There's a cost-benefit to this. Reminds me of bandcamp and other declining sites that just vanished one day with information some would consider valuable.
