It sure will handle a remote VPS, it’s just not as automatic to set up as it is with PVE.

I put this off for a long time, but I finally did it this weekend.

Basically, you install the proxmox-backup-client utility and then run it via cron or a systemd timerto do the backup however often you want.

You’re responsible for getting the VPS to communicate with your backup server (like pretty much any self-hosted service), so some sort of VPN between them would be good. I used NetBird for that part and I have a policy that allows access from the client to PBS only on TCP port 8007.

I’ve been quite happy with Proxmox Backup Server. I’ve had it running for years and it’s been pretty solid for all my VMs/containers. There’s also a bare metal client, which I’m adding to a couple cloud VPS machines this weekend. We’ll see how that goes.

Also, since it’s just Debian under the hood, I also use the PBS host as a replication target for my ZFS datasets via sanoid/syncoid.

A hybrid is probably a good way forward. I had a career as a photographer for a while and I learned from that: going through 1000 photos takes very little time, but going through 10,000 takes an eternity. If you can star or mark your obviously important photos as you go along, it’ll take very little to print them at the end of the year.

This was a recent point of discussion on the 2.5 Admins podcast (https://2.5admins.com/2-5-admins-228/). Some good discussion on there.

My own thought is the best way to handle your family-member-finding-your-old-photos problem is the analog way: make some prints. It’s absolutely idiot proof, the methodology of keeping paper goods is well understood, and the technology is platform independent.

I do this with HAProxy and keepalived. My dns servers resolve my domains to a single virtual ip that keepalived manages. If one HAProxy node goes down, the other picks right up.

And this is one of the few things I’ve got setup with ansible, so deploying and making changes is pretty easy.

I can’t think of anything that specifically uses ssh, but Syncthing would do this, though for passwords I’m more inclined towards bitwarden.

With this concept in mind, I recently put together a VDI setup for a person who’s in one location for half of the year and another the other half. The idea is he’ll have a thin client at each location and connect to the same session wherever he is.

I’m doing this via a VM on Proxmox and SPICE. Maybe there’s some idea in there you could use.

In that case, I’m sure you’ll enjoy it. I’ve been reading a little bit before I go to bed and learning a lot that I glossed over when I set up my own mail server years ago. He and Alan Jude wrote some ZFS books as well that I keep coming back to and picking up new tricks each time.

I get pretty much anything Michael Lucas writes. The information is always great and his writing style is fun to read.

Important to note: it’s not a step-by-step guide to copy and paste and have a mail server running. It’s all about understand all the stuff that goes into it.

I’ve only ever tinkered with openmediavault, so I’m by no means an expert, but there is a ZFS plugin available. Here’s a forum post that may help: https://forum.openmediavault.org/index.php?thread/7633-howto-instal-zfs-plugin-use-zfs-on-omv/

That fruit argument is so that samba plays nicely with Apple’s SMB client implementation.

That will be totally doable, but there’s no one way to setup every service. Some you’ll install from the repository (like nginx or HAProxy or samba). Others you’d have to clone from git (like netbox or dokuwiki). Others have entirely different methods. So, unfortunately it’ll be a lot of reading the documentation.

In general, I prefer unprivileged LXC to a full VM unless there’s some specific requirement that countermands that preference (like running an appliance or a non-Linux OS).

What I tend to do is create a new container for each service (unless there’s a related stack). If the service runs on Docker, I’ll install that right inside the container and manage it with docker compose. By installing Docker directly from get.docker.com instead of the built in packages, it pretty much works all the time.

Since each service is in its own container, restoring backups is pretty service-specific. If you wanted some kind of central control plane for docker, you could check out swarm mode.

In my state (Vermont), the Secretary of State has an rss feed that basically presents the results as an xml file. I’m using that to make some local results spreadsheets. Could be other states have similar things.

I’m not familiar with the Ben Eater series, but there are certainly a couple options to check out.

Mark Ferneaux did a fantastic series on the workings of pfSense. It’s a little dated, but the core concepts are still sound and apply to networking generally.

There are also several sites that do in-depth networking topics with a focus on certifications. My favorite of the bunch is Viatto.

I also quite like The Network Berg, though his videos are specifically focused on Mikrotik.

The thing that immediately came to mind was mailpiler.org. It’s been on my list to stand up for a while, but I’ve never got around to it.

Awesome. I’m glad it helps. I’d be a little weary of using the same directory in multiple containers. File systems may or may not behave well with multiple machines writing to them. Not saying anything bad will happen, but do keep an eye out for issues.

I’m making some assumptions, namely that you’re using an unprivileged LXC container and the mount point is a bind mount.

Unprivileged LXC shift user ID numbers so that an escape won’t result in root access to the host. The root user (uid 0) in the container is actually uid 100000 from the perspective of the Proxmox host.

What I usually do is set ownership of my bind mounts to that high-numbered ID (so something like chown -R 100000:100000 /path/to/bind/mount) from Proxmox. Then the root user in the container will be able to set whatever permissions you need directly.

Since you’re interested in this kind of DIY, approach, I’d seriously consider thinking the whole process through and writing a simple script for this that runs from your desktop. That will make it trivial to do an automatic backup whenever you’re active on the network.

Instead of cron, look into systemd timers and you can fire off your script after, say, one minute of being on your desktop, using a monotonic timer like OnUnitActiveSec=60.

Thinking through the script in pseudo code, it could look something like:

rsync -avzh $server_source $desktop_destination || curl -d "Backup failed" ntfy.sh/mytopic

This would pull the back from your server to your desktop and, if the backup failed, use a service such as ntfy.sh to notify you of the problem.

I think that would pretty much take care of all of your requirements and if you ever decided to switch systems (like using zfs send/recv instead of rsync), it would be a matter of just altering that one script.

I had never heard of this, but it sounds fascinating — thanks for sharing! Definitely going to try to set this up this weekend.