Not completely, I'm afraid, BrowserUK. At least, not with respect to Amazon:

Did you read the rest of the post? I did acknowledge that corruption does occur. My point was not that it doesn't, but that trying to program defensively against the possibility is futile.

For example, in each of your 10-digit timestamps, there are 576,650,390,625 combinations of bit failures that would not only cause your regex to fail to match, but that would corrupt the timestamp such that it would cause you to either discard a backup early, or retain a backup that should have been discarded. That's (at least) five hundred and seventy trillion failure modes that your regex would not and could not detect!

Let me explain. For any decimal digit there are 15 single bit failures that could morph one digit into another valid decimal digit. Eg. 0x31 ascii('1') with corruption of bit-2 on, becomes 0x33 ascii('3'). Or with bit-3 corrupted on: 0x35 ascii('5'); and bit-4 ascii('9'). Do that for all digits and all bits and then combine them out and you get 576 trillion possible combinations that the regex will not detect but that could cause extensive problems through your discarding your latest snapshots or retaining old ones when you shouldn't. And that's just the single bit per digit combinations.

And the possibility of single bit corruptions occurring is far more likely than the disappearance of all 10 digits that it would require before your regex would fail.

You cannot hope to detect, much less deal with, these kinds of failures through defensive programming at the statement level in all your scripts. It can only be done through a combination of error detecting hardware and file-systems. Programming to detect just some of the possible errors, especially when that subset are the least likely to occur, is pointless and naive.

Money down the drain for the sake of a false sense of security. Extra complexity and extra runtime (more costs) for no possible benefit.