Comment by marcinzm
2 years ago
And that's the problem. "It's easy for me because I've done it a dozen times so it's easy for everyone" is a very common fallacy.
2 years ago
And that's the problem. "It's easy for me because I've done it a dozen times so it's easy for everyone" is a very common fallacy.
This is an oversimplification, but! Dumping postgres to a file is one command. scp the file to a different server is two commands. (Granted you need to setup ssh keys there too). I have implemented backups this way.
With sqlite you only need the scp part.
You can even push your backup file to an S3 bucket... with one command!
Honestly, this argument mystifies me.
Of course you can make it as complicated as you want to, too. I've also worked on replicating anonymized data from a production OLTP database to a data warehouse. That's a lot more work.
And that works right until you get to publish an incident report like this:
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-data...
> Our backups to S3 apparently don’t work either: the bucket is empty
It took them a data loss incident to find this out? This is just one of the many red flags mentioned in the article, IMO this incident isn't about relying on cloud backups vs self managing it
1 reply →
What happened to having people trained by external trainers for what you need? That’s much cheaper than having everything externally “managed” and still having to integrate all of it. The number of services listed in TFA is just ridiculous.