Not for PostgreSQL, but for MariaDB we run replicas in FreeBSD jails on a server with lots of ZFS space. The jailed Maria instances just stop every hour (so the DB flushes everything to disk), the host snapshots all of their data volumes, and then starts the jails back up. Within a minute or so they're fully caught up to the primaries again. Gives us months and months of recovery checkpoints.
It's great because it's a completely clean save from a shutdown state, so when we need a scratch copy of a database it only takes as long as cloning whatever snapshot we want (depending on how far back we need to to), then starting a scratch jail that runs from those clone filesystems. When finished, just shutdown scratch and delete the clones, it's like it never happened.
Yes, this really is an example of someone who "made it" and made a large amount of money that has allowed them to turn around and choose a simpler life. "Oh, I just moved myself and my family off to a little Greek island estate I bought and farming it (along with my existing money) is what provides for us..."
Money may not buy happiness buy money buys you all the freedom you could possibly need to do anything that fits your whimsy.
It's not like VMFS (not a cluster filesystem), for Proxmox+iSCSI you get a large LVM PV that gets sliced up into volumes for your VMs. All of your Proxmox nodes are connected to that same LVM PV and you can live migrate your VMs around all you wish, have HA policies so if a node dies its VMs start up right away on a surviving node, etc.
You lose snapshots (but can have your SAN doing snaps, of course) and a few other small things I can't recall right now, but overall it works great. Have had zero troubles.
Yes, when dementia has you terrified of, or raging at, your closest loved ones (who you don't remember at all so you think they're demons or strangers) all day every day to the point where they all can't stand you and feel terrible for wishing death would come to end your massive suffering. Beautiful moments, just beautiful.
Hanging in there with cancer? Sure, fight it and deal with the pain. Dementia? No, please end it. The two aren't even close in comparison, cancer feels easy and merciful.
Yeah, kinda have to agree. I like traefik fine but getting mTLS working with it was a serious pain and the docs for doing so were _terrible_, had to keep searching around and piecing together bits from various third party blogs. Coming from haproxy where the documentation is _so_ _much_ better and things like e.g. mTLS are vastly easier, it was not a fun experience but we did finally get traefik to work as we needed.
Anecdotal but btrfs is the only filesystem I've lost data with (and it wasn't in a RAID configuration). That combined with the btrfs tools being the most aggressively bad management utilities out there* ensure that I'm staying with ext4/xfs/zfs for now.
*Coming from the extremely well thought out and documented zfs utilities to btrfs will have you wondering wtf fairly frequently while you learn your way around.
What about it isn't idempotent for you? Are you falling into the anti-pattern of using shell/command all over the place instead of real modules?
We have playbooks installing and managing our databases, web servers, VoIP PBX, DNS servers, backend services, and on and on. All completely idempotent and safe to run at any time against any host. No special effort whatsoever was required to make that safe to do.
This is the comment you see from people on EKS or GKE. Many companies have compelling reasons to keep a large part, or all, of their services in-house. Nobody who actually has to install and administer K8s is on here commenting about how easy it is to run, maintain, and upgrade on their bare metal hosts. Troubleshoot, I almost forgot troubleshoot! All of those moving pieces, and something is hosed at 3am. This will be fun.
It will be great if that changes someday, and there's certainly been progress, but for places where they'd need to run it themselves, K8s is a tough proposition.
It's great because it's a completely clean save from a shutdown state, so when we need a scratch copy of a database it only takes as long as cloning whatever snapshot we want (depending on how far back we need to to), then starting a scratch jail that runs from those clone filesystems. When finished, just shutdown scratch and delete the clones, it's like it never happened.