So extra background, I was put off by proxmox’s weird steps to get ISO’s onto the system via USB so I was like “I am not touching the backup stuff” and just rolled my own (I treat the VMs/containers on my proxmox server like individual servers and back them up accordingly and do not back up the underlying proxmox instance itself).

I see proxmox has a similar pruning setting to Restic, and it exports the files like incus. So I’d say yes, proxmox is one-stop-shop for backup while with incus you have to put its container export options and restic together and put that in a cron job.

Still hard to say what I’d definitively tell a newbie to go with. I found (and still find) the proxmox ui daunting and difficult while the incus UI makes much more sense to me and is easier (has an ISO pulling system built in for instance. But as you’ve pointed out - proxmox gives you an easy way to have robust backups that takes much more effort on the incus side.

As backups are paramount, proxmox for a total newbie. If someone is familiar with scripting, then incus - because it needs scripted backups to be as robust as proxmox’ backups. @barnaclebill@lemmy.dbzer0.com this conclusion should help you choose proxmox (most likely)!

https://linuxcontainers.org/incus/docs/main/howto/instances_backup/#instances-backup-export

A bit down from the snapshots section is the export section, what I do is I export to a place then back it up with Restic. I do not compress on export and instead do it myself with the —rsyncable flag added to zstd. (Flag applies to gzip too) With the rsyncable flag incremental backups work on the zip file so it’s space efficient despite being compressed. I don’t worry about collating individual zip files, instead I rely on Restic’s built-in versioning to get a specific version of the VM/container if I needed it.

Also a few of my containers I linked the real file system (big ole data drive) into the container and just snapshot the big ole data drive/send said snapshot using the BTRFS/ZFS methods cause that seemed easier, those containers are easy enough to stand up on a whim and then just need said data hooked up.

I also restic the sent snapshot since snapshots are write-static and restic can read from it at its leisure. Restic is the final backup orchestrator for all of my data. One restic call == one “restic snapshot” so I call it monolithically with one call covering several data sources.

Hope that helps!

https://linuxcontainers.org/incus/docs/main/howto/instances_backup/#instances-snapshots

This describes the jist, it’s all about snapshots! Incus loves BTRFS/ZFS.

There’s no true need for stop everything as far as I can tell.

Stop everything is applicable for databases for any backup system (snapshot avoids backing up a database mid write (guaranteed failure) but the snapshot could be during a live database multi-step operation and while intact is left in a cursed state). For databases I make sure to stop and backup (SQLite losers) or backup live (Gods’ chosen Postgres) specially so no very niche database failures occur even though it was done with instant/write-safe snapshots!!

Recovery plan is restore snapshot and if 0.1% chance of database bad bc was mid big multiple step operation then I have the .gz to restore from.

There is a larger community. I have proxmox and incus on two devices and for the basics (LXC container/VM) Incus is way more straight forward. Ditchin proxmox next reinstall on the other device (that proxmox install is the OS version). If you’re doing regular stuff it’s easy enough even with the reduced community! They’ve covered the basics well.

But again, proxmox community is larger. I started with it for that reason too.

Since you’re not using proxmox as an OS install, why not check out Incus? It accomplishes the same goals as proxmox but is easier to use (for me at least). Make sure you install incus’ web ui, makes it ez pz. Incus does the VMs and containers just like proxmox but isn’t focused on clustering 1st but rather machine 1st. It does do clustering, but the default UI is set for your machine to start so it makes more sense to me. The forums are very useful and questions get answered quickly, and there’s an Ubuntu-only fork called LXD which expands the available pool of answers. (For now, almost all commands are the same between Incus and LXD). I run the incus stable release from the Zabbly package repo, I think the long term release doesn’t have the web ui yet (I could be wrong). Never have had a problem. When Debian 13 hits I’ll switch to whatever is included there and should be set.

https://linuxcontainers.org/incus/docs/main/installing/#installing-from-package

I use incus for VMs and LXC containers. I also have Docker on the Debian system. Many types of containers for every purpose!

I installed incus on a Debian system that I encrypted with LUKS. It unlocks after reboots with a USB drive, basically I use it like a yubikey but you could leave it in so the system always reboots no problem. There’s also a network unlock too but I didn’t try to figure that out. Without USB drive or network, you’ll have to enter the encryption key on every reboot.

Not a doctor, but based on research I’ve seent brain fog (in likely many cases) seems to be due to inflammation. https://www.autoimmuneinstitute.org/covid_timeline/brain-fog-likely-caused-by-brain-inflammation-its-not-just-all-in-their-head/

Have your friend try inflammation-reducing drugs like metformin. Metformin specifically, maybe there’s others, I’m sadly not a doctor. Metformin is a magic drug that’s not just for diabetius.

It won’t be immediate, but maybe it could help your friend recover. Idk if cranking yourself will break through when it’s a blocking mechanism causing the problem.

I got my parents to get a NAS box, stuck it in their basement. They need to back up their stuff anyway. I put in 2 18 TB drives (mirrored BTRFS raid1) from server part deals (peeps have said that site has jacked their prices, look for alts). They only need like 4 TB at most. I made a backup samba share for myself. It’s the cheapest symbology box possible, their software to make a samba share with a quota.

I then set up a wireguard connection on an RPi, taped that to the NAS, and wireguard to the local network with a batch script. Mount the samba share and then use restic to back up my data. It works great. Restic is encrypted, I don’t have to pay for storage monthly, their electricity is cheap af, they have backups, I keep tabs on it, everyone wins.

Next step is to go the opposite way for them, but no rush on that goal, I don’t think their basement would get totaled in a fire and I don’t think their house (other than the basement) would get totaled in a flood.

If you don’t have a friend or relative to do a box-at-their-house (peeps might be enticed with reciprocal backups), restic still fits the bill. Destination is encrypted, has simple commands to check data for validity.

Rclone crypt is not good enough. Too many issues (path length limits, password “obscured” but otherwise there, file structure preserved even if names are encrypted). On a VPS I use rclone to be a pass-through for restic to backup a small amount of data to a goog drive. Works great. Just don’t fuck with the rclone crypt for major stuff.

Lastly I do use rclone crypt to upload a copy of the restic binary to the destination, as the crypt means the binary can’t be fucked with and the binary there means that is all you need to recover the data (in addition to the restic password you stored safely!).

Odd, I’ll try to deploy this when I can and see!

I’ve never had a problem with a volume being on the host system, except with user permissions messed up. But if you haven’t given it a user parameter it’s running as root and shouldn’t have a problem. So I’ll see sometime and get back to you!

That’s pretty damn clever

I try to slap anything I’d face the Internet with with the read_only to further restrict exploit possibilities, would be abs great if you could make it work! I just follow all reqs on the security cheat sheet, with read_only being one of them: https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

With how simple it is I guessed that running as a userand restricting cap_drop: all wouldn’t be a problem.

For read_only many containers just need tmpfs: /tmp in addition to the volume for the db. I think many containers just try to contain temporary file writing to one directory to make applying read_only easier.

So again, I’d abs use it with read_only when you get the time to tune it!!

Looks awesome and very efficient, does it also run with read_only: true (with a db volume provided, of course!)? Many containers just need a /tmp, but not always

I trust the check restic -r '/path/to/repo' --cache-dir '/path/to/cache' check --read-data-subset=2000M --password-file '/path/to/passfile' --verbose. The --read-data-subset also does the structural integrity while also checking an amount of data. If I had more bandwidth, I’d check more.

When I set up a new repo, I restore some stuff to make sure it’s there with restic -r '/path/to/repo' --cache-dir '/path/to/cache' --password-file '/path/to/passfile' restore latest --target /tmp/restored --include '/some/folder/with/stuff'.

You could automate that and make sure some essential-but-not-often-changing files match regularly by restoring them and comparing them. I would do that if I wasn’t lazy I guess, just to make sure I’m not missing some key-but-slowly-changing files. Slowly/not often changing because a diff would fail if the file changes hourly and you backup daily, etc.

Or you could do as others have suggested and mount it locally and just traverse it to make sure some key stuff works and is there sudo mkdir -p '/mnt/restic'; sudo restic -r '/path/to/repo' --cache-dir '/path/to/cache' --password-file '/path/to/passfile' mount '/mnt/restic'.

I have my router (opnsense) redirect all DNS requests to pihole/adguardhome. AdGuard home is easier for this since you can have it redirect wildcard *.local.domain while pihole wants every single one individually (uptime.local.domain, dockage.local.domain). With that combo of router not letting DNS out to upstream servers and my local DNS servers set up to redirect *.local.domain to the correct location(s), my DNS requests inside my local network never get out where an upstream DNS can tell you to kick rocks.

I combined the above with a (hella cheap for 10yr) paid domain, wildcard certified the domain without exposure to the wan (no ip recorded, but accepted by devices), and have all *.local.domain requests redirect to a single server caddy instance that does the final redirecting to specific services.

I’m not fully sure what you’ve got cooking but I hope typing out what works for me can help you figure it out on your end! Basically the router doesn’t let anything DNS get by to be fucked with by the ISP.

I’m surprised no one’s mentioned Incus, it’s a hypervisor like Proxmox but it’s designed to install onto Debian no prob. Does VMs and containers just like Proxmox, and snapshots too. The web UI is essential, you add a repo for it.

Proxmox isn’t reliable if you’re not paying them, the free people are the test people - and a bit back there was a bad update they pushed that broke shit. If I’d have updated before they pulled it, I’d have been hosed.

Basically you want a device that you don’t have to worry about updates, because updates are good for security. And Proxmox ain’t that.

On top of their custom kernel and stuff, it’s just less eyes than, say, the kernel Debian ships. Proxmox isn’t worth the lock-in and brittleness for just making VMs.

So to summarize, Debian and Incus installed. BTRFS if you’re happy with 1 drive or 2 RAID 1 drives. BTRFS gets scrubbing and bitrot detection (protection with RAID 1). ZFS for more drives. Toss on Cockpit too.

If you want less hands-on, do to OpenMediaVault. No room for Proxmox in my view, esp. for no clustering.

Also the iGPU on the 6600K likely is good enough for whatever transcoding you’d do (esp. if it’s rare and 1080p, it’ll do 4k no prob and multiple streams at once). The Nvidia card is just wasting power.

I do this but with root Docker, every service gets a user:####:#### and that #### is tied to a useradd I made. Chown the data directory the container is given and it just works. In Docker this does not work for Linuxserver images but podman has way more user: specifications so I have a feeling Linuxserver images will work there with the user restrictions.

For something like Gotenberg which is part of paperless ngx I gave Gotenberg its own user too, it has chromium and might ingest a malicious pdf somehow or something. Might as well keep Gotenberg from being able to hose the rest of paperless!

I do plan to move to podman with 5.0+ in Debian 13 and that will remove the Docker daemon attack surface and the occasional firewall issues that come with Docker. So I’m not advocating for Docker over podman here.

I wish too for an in-depth blog post, but the github answer is at least succinct enough

This answers all of your questions: https://github.com/containers/podman/discussions/13728 (link was edited, accidentally linked a redhat blog post that didn’t answer your Q directly but does make clear that specifying a user in rootless podman is important for security for the user running the rootless podman container if that user does more than just run the rootless podman container).

So the best defense plus ease of use is podman root assigning non-root UIDs to the containers. You can do the same with Docker, but Docker with non-root UIDs assigned still caries the risk of the root-level Docker daemon being hacked and exploited. Podman does not have a daemon to be hacked and exploited, meaning root Podman with non-root UIDs assigned has no downsides!

I see, do you know of a way in Docker (or Podman) to bind to a specific network interface on the host? (So that a container could use a macvlan adapter on the host)

Or are you more advocating for putting the Docker/Podman containers inside of a VM/LXC that has the macvlan adapter (or fancy incus bridge adapter) attached?

Confused at this sentiment, Docker includes a MACVLAN driver so clearly it’s intended to be used. Do you eschew any networking in Docker beyond the default bridge for some reason?

With the default Docker bridge networking the container won’t have a unique IP/MAC address on the local network, as far as I am aware. Communication with external clients will have to contact the host server’s IP at the port the container is tied to in order to interact. If there’s a way to specify a specific parent interface, let me know!