Maybe this will help you: https://linuxcontainers.org/incus/docs/main/backup/

How are snapshots with ZFS on Incus?

What do you mean? They work, described here, the WebUI can also make snapshots for you.

You should consider replacing Proxmox with LXD/Incus because, depending in your needs, you might be able to replace your Proxmox instances with Incus and avoid a few headaches in the future.

While being free and open-source software, Proxmox requires a payed license for the stable version and updates. Furthermore the Proxmox guys have been found to withhold important security updates from non-stable (not paying) users for weeks.

Incus / LXD is an alternative that offers most of the Proxmox’s functionality while being fully open-source – 100% free and it can be installed on most Linux systems. You can create clusters, download, manage and create OS images, run backups and restores, bootstrap things with cloud-init, move containers and VMs between servers (even live sometimes).

Incus also provides a unified experience to deal with both LXC containers and VMs, no need to learn two different tools / APIs as the same commands and options will be used to manage both. Even profiles defining storage, network resources and other policies can be shared and applied across both containers and VMs. The same thing can’t be said about Proxmox, while it tries to make things smoother there are a few inconsistencies and incompatibilities there.

Incus is free can be installed on any clean Debian system with little to no overhead and on the release of Debian 13 it will be included on the repositories.

Another interesting advantage of Incus is that you can move containers and VMs between hosts with different base kernels and Linux distros. If you’ve bought into the immutable distro movement you can also have your hosts run an immutable with Incus on top.

Incus Under Debian 12

If you’re on stable Debian 12 then you’ve a couple of options:

• Run the LXD version provided on their repositories: this will give you LXD 5.0.2 LTS that is guaranteed to be compatible with Debian 13’s Incus. Note that this was added before Canonical decided to move LXD in-house;
• Use the backported version as described here: https://linuxcontainers.org/incus/docs/main/installing/;
• Get the latest Incus pre-compiled from https://github.com/zabbly/incus and install as described above.

In the first option you’ll get a Debian 12 stable system with a stable LXD 5.0.2 LTS, it works really well however it doesn’t provide a WebUI. The second and third options will give you the latest Incus but they might not be as stable. Personally I was running LXD from Snap since Debian 10, and moved to LXD 5.0.2 LTS repository under Debian 12 because I don’t care about the WebUI. I can see how some people, particularly those coming from Proxmox, would like the WebUI so getting the latest Incus might be a good option.

I believe most people running Proxmox today will, eventually, move to Incus and never look back, I just hope they do before Proxmox GmbH changes their licensing schemes or something fails. If you don’t require all features of Proxmox then Incus works way better with less overhead, is true open-source, requires no subscriptions, and doesn’t delay important security updates.

Note that modern versions of Proxmox already use LXC containers so why not move to Incus that is made by the same people? Why keep dragging all of the Proxmox overhead and potencial issues?

Yeah, you’ll be okay. The easiest way is to pick a generic image for ARM here: https://github.com/home-assistant/operating-system/releases/latest and run with using Incus/LXD or some other virtualization solution that you like. I personally run it on Incus.

You can also do a more barebones manual install in a container if you don’t want to run the entire thing. I would still stick with a Incus container or VM to avoid polluting your base system.

Reolink / AMCrest - no internet required, can be setup offline AND have a WebUI that allows full control over all functionality. Check the details of specific models, may vary a bit.

… NO internet required, no apps, nothing. Just a WebUI on a browser.

Too much pieces that can potentially break. I’ve been looking at http://nginx.org/en/docs/http/ngx_http_auth_request_module.html and there’s this https://github.com/kendokan/phpAuthRequest that is way more self contained and simple to maintain long term. The only issue I’m facing with that solution is that I’m yet capable of passing a token / username in a header to the final application.

• TPLink Tapo line - I own those, requires internet / cloud access for setup, then can be viewed by any ONVIF capable software, VLC etc. You can cut their internet access and they mostly work, however timestamps and some features may break randomly;
• Reolink / AMCrest - no internet required, can be setup offline AND have a WebUI that allows full control over all functionality. Check the details of specific models, may vary a bit.

AMCrest is most likely be most offline friendly brand. Here’s a testimonial from another user:

I’ve been using Amcrest and foscam IP cameras at my home for the past several years. I have then connected to a no internet VLAN with an NVR. The models I’ve been using have an ethernet port and wifi. Setup was connecting to the ethernet port and then accessing the web ui in a browser to configure settings (most importantly turning on RTSP or ONVIF feeds)

Thanks, I’ll have another look.

Hmm this is actually interesting, passkeys would indeed make things simpler.

Those solutions are still way too complex and corporate to my likes. :(

I’ve been looking into some kind of simple SSO to handle this. I’m tired of entering passwords (even if it’s all done by the password manager) a single authentication point with a single user would be great.

Keycloak and friend are way too complex. Ideally I would like to have something in my nginx reverse proxies that would handle authentication at that level and tell the final app what user is logged on in some safe way.

it’s possible to have an email client download all the messages from Gmail and remove them from the server. I would like to set up a service on my servers to do that and then act as mail server for my clients. Gmail would still be the outgoing relay and the always-on remote mailbox, but emails would eventually be stored locally where I have plenty of space.

Do you really need this extra server? Why not just configure the account on Thunderbird and move the older / archival mail to a local folder? Or even drag and drop it out of Thunderbird to a folder and store the resulting files somewhere?

I’m just asking this because most people won’t need regular access to very old email and just storing the files on a NAS or something makes it easier.

They’re devices usually require a ui.com account and linking the device. As some people already said it you’ll still require cloud connection to setup the device even if standalone by using their mobile or desktop app. Doesn’t seem like a good choice for someone who’s into privacy and self hosting.

It is somewhat sensitive, at least wireless device names, network/switch setup, MAC addresses and LED/ GPIO settings are going to be different - almost always (and this list is far from complete).

Usually what I do is I take the config and merge it manually (Beyond Compare), to the default config of a new unit, that way I can adjust the interfaces and other details.

To be fair I only do this because I tend to deploy OpenWRT on customers quite a lot and something I don’t have a config for some specific hardware already done. A router is basically a fridge, it should last a long time and even if you’ve to manually configure everything it won’t be much of an issue 5 or 10 years later.

Be prepared to be hostage of their cloud services… Unifi was all cool until they introduced the Cloud Key and a few other things.

The future of ethernet is not expensive cabling, more like switches capable of doing more on current cables. We’ve been seeing this trend for a while.

I’ve done my fair share of long runs of Cat6e 23 AWG with PoE and they all work fine and gigabit on distances like 100 meters or close. Sometimes even slightly above that.

Staggered will reduce the failure rate by a lot, specially if you’re into gigabit speeds or anything above it. Although I know from experience that you can get gigabit on non-staggered connectors it won’t always happen on the first try. On long distances the noise caused by having the wires side by side may also cause problems.

Btw, if you’ve small patch cables don’t use solid core for those, those should be stranded cables and they’ll be more flexible, less likely to break when bent and less prone to bad contacts.

It depends: https://lemmy.world/comment/11680250

CCA wasn’t probably your issue there, CCA is actually becoming the standard everywhere because copper is way too expensive and to be fair not needed with modern hardware.

You most likely issue with that CCA is the AWG size you picked, cheap cable is usually 24, 26 or even 28 AWG and those will be bad.

If you want PoE or anything gigabit or above you need to pick 23 AWG. This is considerably cheaper than full copper and it will work fine for the max. rated 100m. Either way, cheap 26 AWG should be able to deliver gigabit and PoE at short distances like 20 meters or so.

Another important thing is to make sure your terminations are properly done and the plugs are good. Meaning, no Cat5e connectors should be used, always use staggered ones:

I’ve a run of around 60 meters of old telephone cables (made out of copper, 4 wires) and I can get 100Mbps on those reliably. I used the old telephone infrastructure on the building to pass network from an apartment to the basement that way.

Not to spec on ethernet on any way, not even twisted pairs but they do work. Unfortunately I can’t replace the run with a proper Cat6 cable because there’s a section that I can’t find where it goes to, it just disappears on a floor and appears 2 floors bellow it inside the main telephone distribution box.

On the distribution box (that is already on the basement of the building) I’m plugging into the LSA connector that goes to the apartment:

The black box you see there is a mikrotik gper that is essentially a PoE switch with only 2 ethernet ports so I can get over the 100m limitation of ethernet. I’m running a cat6 cable from there on metal cable trays for about another 90 meters until it reaches a storage unit 2 floors bellow ground.

Here’s a ping test from a machine sitting on the storage box to the router on the apartment:

The router reports this as a 100M full-duplex connection:

If anyone wants to try a setup like this, or just extend ethernet > 100m, it also worked fine with a cheap 5$ 100M switch from Aliexpress and a PoE injector + splitter.

However I eventually got the mikrotik gper for free so I decided to replace it because it should be more reliable.

Yes but… tests are done in controlled environments and ideal conditions, there are big real world differences with CCA vs fully copper or those solid core options vs stranded ones. They’ll all perform differently depending on distances, noise immunity will vary and will break differently in different ways when tension is applied. You can also get Cat5e on different AWG sizes, all spec compliant but all very different from each other.

The bottom line is: it all comes down to how much you’re willing to spend.