Always follow 3-2-1 backup rule

Holy fuck whoever was in charge of setting up that disaster recovery needs a million dollar bonus. I get that they're managing $80B and this should all be standard but people usually don't listen to IT and take DR seriously. And even if you do set it up, are you going back to check that your backups are functioning properly and have alarms for when it messes up

Absolutely.
But something tells me they will at most get a recognition award printed from MSWord and a pizza party day at their local office.
Friendly reminder to every CEO that this could have been a situation where a disgruntled employee accidentally fucks up the off site backup too.
Time to update my off site cold backup(private)
- can I get a copy if I ask very nicely?

That wasn't luck - it was best practice backup strategy.

Meme is funny, but that exception used as flow control hurts.

Tbf python guidelines encourage it over if/else in cases like this. "Easier to ask for forgiveness than for permission" or something along the lines
- pythonic != good
- Day 598 of asking for a way to tell which functions throw exceptions in Python so I can know when to wrap in try catch. Seems to me that every other language has this, but when I've asked for at least a linter that can tell me I'm calling a function that throws, the general answer has been "why would you want that?"
  How am I supposed to ask for forgiveness if it's impossible to know that I'm doing something risky in the first place?
- python guidelines
  Do you have a specific PEP you're referencing or is this one of those "I assume this must be the case because of how common using try/except statements for flow control are" kind of things?
- Like most things in life, context matters. In the OP it seems like the check function is used specifically so it could raise a PaymentException if the payment hasn't been received... That's not a "forgiveness/permission" context, this is a yes or no question, hence should have been an if.
Still hurts, but sometimes it's the only option.
If you're trying to confirm things like account existence/deletion, there's often no "account exists" function to return true or false. You just have to figure out the specific exception thrown and catch that specific one.
The worst are libraries that don't give specific exceptions, so you have to catch all exceptions then do extra work to tell what the specific situation is. Does the account not exist, or is the system unreachable?
- Yeah, I had a similar case with some authentication middleware I used that was part of a library.
  It would always throw an exception when a user wasn't authenticated instead of just giving me some flag I could check.
  Wouldn't have done it that way, but it was okay for an API controller.
- so you have to catch all exceptions then do extra work to tell what the specific situation is
  That’s horrifying. That’s a solid reason to avoid Python like the plague.
nothing wrong with that - it is an exception, as in, the customer is likely lost after that anyway.

IMO backups on the same provider aren't really backups. Good that they had some at a different one.

I mean I was originally angry about this toss-up, but since it hit an investment company... good guy Google?

I'm confused now.

UniSuper is a superannuation fund (think 401k), it’s one of the good ones in that it doesn’t take commissions and profits go to members
Stay confounded at Google’s incompetence.
This company wasn't exactly targeted. It could have happened to literally anyone.

paid_bill*

Where is paid_not_payed bot when we need them?
- some heroes don't wear caypes
- Deleted by GCP.