While that sort of analysis probably isn’t impossible, it is computationally unrealistic to do in realtime on a language which wasn’t designed for it.

It’s the sort of thing which is simple in 99% of cases, but the last 1% might well be impossible. Sadly it’s the last 1% you need to worry about, because anyone trying to defeat your system is going to find them

Also, it’s probably possible to fix the partition so that it’s as big as it used to be. It’s likely that some of your data is corrupted already, but the repartitioning won’t have erased the old data except here or there where it’s written things like new file tables in space it now considers unused

What they’re suggesting is to back up the whole disk, rather than any single partition. Anything you do to the partition to try and recover it has the potential to make a rescuable situation hopeless. If you have a copy of the exact state of every single bit on the drive, then you can try and fix it safe in the knowledge that you can always get back to exactly where you are now if you make it worse

I find it makes my life easier, personally, because I can set up and tear down environments I’m playing with easily.

As for your user & permissions concern, are you aware that docker these days can be configured to map “root” in the container to a different user? Personally I prefer to use podman though, which doesn’t have that problem to begin with

Podman supports docker compose just fine. You have to run it as a service, so that it can expose a socket like docker does, but it supports doing exactly that

Because a container is only as isolated from the host as you want it to be.

Suppose you run a container and mount the entire filesystem into it. If that container is running as root, it can then read and write anything it likes (including password databases and /etc/sudo)