hamsda

No problem, english isn’t my native language either.

In the end, it just boils down to: are you okay with a downtime while reinstalling the hypervisor and restoring from backups? If yes, you don’t need a RAID. If no, a RAID of some kind would probably be the most sensible choice.

You should not be able to restore the whole drive, like you would restore a VM. This is because you would first need to have Proxmox VE already running to restore the drive which runs Proxmox VE.

If your NVME drive dies, you would have to do what I outlined above:

• get new NVME drive, install in server
• install Proxmox VE manually
• install Proxmox BS manually (either lxc container or VM)
• give Proxmox BS access to backups on external HDD
• restore whatever you backed up

Though, to reiterate, I do not know anything about lxc containers.

I did go through the Proxmox VE backup settings on my server, but I could not find a way to backup lxc containers, only VMs. So maybe Proxmox VE does not support backing up lxc containers? Or maybe it just does not show any lxc container backup option because I do not run any lxc containers?

I did find this github about Proxmox VE and LXC containers, but I didn’t test it and it only has 1 star, so I’d be wary.

As a tipp: Even if your motherboard only supports 1 NVME drive, you might still be able to use multiple. You could buy a PCIe card with M.2 NVME slots, if you have any unused PCIe slots on your mainboard. With this, you should still be able to have a RAID setup.

How does it work if my ssd dies, where proxmox boot

If you only have 1 disk on your server (no RAID), you will have to

• buy a disk
• install in server
• reinstall Proxmox VE
• Install Proxmox BS
• have a regular backup on some other disk (e.g. USB HDD) to restore other VMs from

and the lvm for the containers is located on?

Are you talking about containers (lxc, docker) or the VM disks? You need a backup for VM disks anyway (Proxmox BS).

If you’re talking about containers, I do not know how to backup those. I do use docker containers but they’re all inside VMs. I like to seperate things via VMs, as a rogue container taking down it’s VM (or having other negative effects on its host) is less of a headache than a rogue container taking down the whole hypervisor because it’s running directly on the that.

For comparison, this is my disk setup for my server (my old PC):

# lsblk
nvme0n1     259:0    0 465.8G  0 disk
nvme1n1     259:1    0 465.8G  0 disk
sda           8:0    0   3.6T  0 disk
sdb           8:16   0   3.6T  0 disk
sdc           8:32   0   3.6T  0 disk

# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data_raid  10.9T  2.40T  8.51T        -         -    26%    21%  1.00x    ONLINE  -
rpool       460G  7.31G   453G        -         -     8%     1%  1.00x    ONLINE  -

The 2 NVME-disks are used in a ZFS mirror (rpool in zpool list above) and store the Proxmox OS. The 3 SATA SSDs (see sd* in lsblk above) are housing all VM data in a ZFS RAID-Z1 called data_raid. With this hardware- and RAID-setup, one disk of each zpool could die right now and all I’d have to do is pay the currently horrendous hardware-prices and replace it. No data-loss or downtime until at least 2 disks of a single zpool die together.

All hardware dies at some point. Preperation is key.

Interesting. I do not know a lot about Home Assistant devices, but I thought they would just be communicating via standard WIFI + data encryption. I definitely didn’t suspect there to be a whole new standard of wireless communication to that.

I understand the thing about downtime, running pihole myself. My setup is rather simple and centralized on purpose and I don’t really mind the few minutes of “filtered DNS” downtime while pihole and pve are rebooting. As my UniFi Dream Router 7 is the firewall / gateway / DHCP server anyway, I just use pihole as primary DNS and 1.1.1.1 as secondary DNS. It’s not filtering “bad domains” via DNS, sure, but I got adblock origin and other browser extensions dealing with whatever comes along anyway.

But, yeah, for redundancy and always-online-production-setups it’s actually great having a secondary pve as a temporary stop-gap. Plus, it’s a nice and kinda fancy setup, of course. Always appreciated in selfhosted :)

I use 1 host running Proxmox VE (PVE) with a VM for Proxmox BS (PBS). Datastores are located on a USB HDD with passthrough of that specific USB ID to the PBS VM.

It works really well and the only actual downside is that, for a complete-restore (e.g. reinstall PVE or new server or hard drives) you need to set up the PBS VM again before you can use your backups.

For the host-config on PVE, I use a systemd service and timer starting a simple proxmox-backup-client backup of /etc. That is enough to restore the configuration in case of some emergency.

Also: Is there a benefit for splitting your services on 2 hosts? Shouldn’t 1 host with all VMs consume less electricity than the same VMs split on multiple hosts?

I cannot speak to collaborative editing of documents, but I do run my own docker-based nextcloud server for my own data.

I use nextcloud for:

• files
• photos (via memories app)
• contacts
• calendar
• tasks
• notes

I am not using the AIO docker image, I am using the nextcloud:APP_VERSION image, with APP_VERSION being 33 currently, preparing to upgrade to 34. My SSL-certificate is done via nginx-proxy-manager, as it was easy to setup on a different VM and it acts as a gateway to my internal services.

Syncing files, contacts and calendar works very well with my Graphene OS Pixel 9a (via the F-Droid App DAVx5, as well as my EndeavourOS desktop. The only thing I can really complain about is the documentation for selfhosting, as it seems to be missing some info. Or maybe I just didn’t find it.

If you’re interested, I can share my setup consisting of

• docker-compose.yml for local tests
• docker-compose.production.yml for production and staging deploy
• Dockerfile for nextcloud + cron container (though I may replace this with ofelia)
• Starter-Script for local tests
• GitLab CI pipeline for production and staging deploy

It may be a bit over-engineered though.