Live data from Hacker News

Total data loss after botched GitOps and failed backups

firefish.social

41–50 of 176 posts

Re: Total data loss after botched GitOps and failed backups

#41
post #3

The more layers of automation we add, the more invisible points of failure. Magic is great until it isn’t. I feel their pain. The sinking feeling when you realize that data is gone and not coming back is an awful experience.

  The more layers of automation we add, the more invisible points of failure. 
Bullshit. Doing things by hand is more error prone.

Without automation this situation would've played out like: well we got used to running things with e.g. --force or --yes or just hitting yes manually at every prompt. Unfortunately we just nuked our data store.

Alternatively they would've looked at the dashboards, seen perhaps low CPU or memory utilization for the data store namespace and manually nuked it to save some money..

While this smells like a process issue it's mostly an architectural one. It's good that things were namespaced, however, for persistent data the infra should be more or less air gapped from a tooling POV. Updating the persistent data store should be a whole separate CI job, ideally with more intervention required to effect change.

Re: Total data loss after botched GitOps and failed backups

#42
post #4

Wow... tooling that deletes a bunch of stuff because a manifest file is missing. Just... wow. I feel for the admin here. This seems equivalent to an accidental `sudo rm -rf /`.

Yeah, it should not delete everything in that situation, it should require a tombstone file.

Re: Total data loss after botched GitOps and failed backups

#43
post #18
post #9

Automation is wonderful for creating things, configuring things and moving things. Automation should never "clean up". Do your cleanup manually, or this is what you get.

The point of the tooling is that you describe what you want your deploy to look like, and it updates the deploy to match the description. If you delete something from the description and it stays running, that would be very confusing.

It's not too bad. There are two approaches to this one in AWS: 1. You can mark specific resources like db and volumes to be retained on stack deletion. 2. You can't delete some resources easily without deleting the content. Wanna delete a bucket? Explicitly delete all the objects first.

It works ok in practice.

Re: Total data loss after botched GitOps and failed backups

#44
post #28

Earlier quoted context omitted.

This is a dumb question, but why can't people just make things simpler? Tools are supposed to make work easier and make things more efficient, but this sort of complexity just seems to hurt, doesn't it?

I wonder if it has to do with mismatches between -as-cattle and -as-pets philosophies and usecases. From the post, it looks like they were using k8s. It's hard to tell given the, you know, total data loss, but it looks like the instance had at max triple-digit users. In my experience running small community stuff like this, the -as-cattle tooling, even though I'm familiar with it from work, is way overkill and introd…

This sounds like a good explanation. As an outsider may be complexity seems unnecessary but it's needed for scale (an analogy is what is needed in a kitchen for a spaghetti meal to what is needed in a resturaunt to what is needed in a canned spaghetti factory), but problems can arise when you try to shoehorn methodologies and tools for scaled production to smaller systems I guess.

Re: Total data loss after botched GitOps and failed backups

#46

This all seems way overly complicated for what could probably be a few services running on a VM or four. Why does Kubernetes/Argo/Helm need to get involved? Why couldn't the whole architecture diagram look a lot more like HN? I feel like we've entirely lost our way with complexity.

IMO it's because of this default in k8s storage class: https://kubernetes.io/docs/concepts/storage/storage-classes/.... Almost everything in a k8s cluster can be ephemeral... except your data! But they make the defaults insane and it eats a lot of people's lunches. It's honestly very sad. I fortunately haven't "lost" data in 25 years, but I still remember the pain when I made this kind of mistake.

Re: Total data loss after botched GitOps and failed backups

#47

> While manual backup and restore tests were run once a month to ensure our backups were functioning, they were run manually. After digging into why our restores were not coming up with data, I found that our recurring backups were missing the flag to run volume backups with Restic which snapshots PVC block volume data. Can someone explain this? How did they test restores, if the actual restore failed to come up with…

Velero can be configured to run on a schedule, but the scheduled command was apparently not the exact same command they were using to perform the manual tests - the scheduled job was missing part of the command, basically.

Re: Total data loss after botched GitOps and failed backups

#49
Off-topic, but this website has some pretty crazy dark-patterns!

I went to the user's profile and right-clicked their photo. The contextmenu action is intercepted and replaced with a custom menu mimicking the browser's context menu. This fake context menu has the option "Open in Window". I click it. The website doubles-down on the charade and opens a "popup" inside itself - maximize/minimize icons in the action bar and everything.

It's the sort of thing you're taught phishing websites do to lure you into inputting your credentials into the wrong website.

https://i.imgur.com/lMiH3uH.png

Re: Total data loss after botched GitOps and failed backups

#50
Disclaimer: Author to a competitive k8s backup solution.

I personally don't think Velero is a solution for production workloads or anything serious. Only an established backup company/devs will have expertise to implement and handle all cases and take care of all data loss scenarios. Ideally k8s authors should have stopped at providing a tool (they have snapshots like any db/fs) rather than writing their own backup piece. Unfortunately many of the industry solutions are wrapped over Velero except a few (two?), one I implemented from scratch for Commvault.

Post reply on HN