Het Unraid topic

[i-chat]

parity is een eerstelijns 'recovery' tool als je parity goed hebt lopen is het vaak de makkelijkste en meest recente backup die je kunt hebben, snapshotted parity zoals unraid dat doet is wat dat betreft weer wat minder goed, maar altijd sneller dan incremental backups.

maar als je stelt dat parity geen backup is dan zeg ik, je hele schijf kopiëren naar een USB-schijf is ook geen backup (er kunnen immers copy-errors hebben opgetreden en een file-check over usb kost je onmogelijk veel tijd dus dat doe je liever ook niet al te vaak.

dan kom je eigenlijk al weer bij deze gemeenheid: 1 back up is geen backup 2 backups is een halve backup 3 backup is pas e(e)n echte backup (pun intended)

[Asterion]

Nu sla ik toch wel even steil achterover.

Ik heb de voorbije dagen redelijk wat Docker containers aangemaakt.
Toen ik wou inloggen via ssh en geen connectie kreeg heb ik de server herstart.

Nu zijn al deze containers verdwenen tussen 2 weken en nu.

Ik heb wel nog alle datamappen staan in de appdata folder maar ze staan niet in het overzicht?

Heeft iemand een idee waar ik moet beginnen zoeken naar de oorzaak?
Nu is er wel immens veel werk verloren.

[kevi-n1]

Asterion schreef op vrijdag 11 juli 2025 @ 15:30:
Nu sla ik toch wel even steil achterover.

Ik heb de voorbije dagen redelijk wat Docker containers aangemaakt.
Toen ik wou inloggen via ssh en geen connectie kreeg heb ik de server herstart.

Nu zijn al deze containers verdwenen tussen 2 weken en nu.

Ik heb wel nog alle datamappen staan in de appdata folder maar ze staan niet in het overzicht?

Heeft iemand een idee waar ik moet beginnen zoeken naar de oorzaak?
Nu is er wel immens veel werk verloren.

Adem in, adem uit

Als je een nieuwe container wilt maken, kan je uit de template lijst verschillende dockers selecteren.
Wanneer je deze aanklikt dan komen alle oude instellingen terug en hoef je enkel nog op "apply" te klikken.

De waarom vraag kan ik niet beantwoorden maar je bent binnen no-time weer "online".

[Asterion]

kevi-n1 schreef op vrijdag 11 juli 2025 @ 19:57:
[...]


Adem in, adem uit

Als je een nieuwe container wilt maken, kan je uit de template lijst verschillende dockers selecteren.
Wanneer je deze aanklikt dan komen alle oude instellingen terug en hoef je enkel nog op "apply" te klikken.

De waarom vraag kan ik niet beantwoorden maar je bent binnen no-time weer "online".

Bedankt voor de tip.
Ik zie echter wel dat instellingen die ik gemaakt heb ongedaan zijn gemaakt.
Er zijn zelfs containers terug gekomen die ik verwijderd had.
Het is alsof er een snapshot genomen is waar hij na de reboot terug is gegaan.

Edit:
Met behulp van Chatgpt even in de logs gedoken. Daaruit blijkt dat alle wijzigingen sinds vorige maand niet naar de flashdrive zijn weggeschreven en dus alles verloren is gegaan na de reboot.
Worden normaal alle wijzigingen weggeschreven naar de flashdrive wanneer men afsluit of herstart of gebeurd dit tussentijds ook?

[ Voor 19% gewijzigd door Asterion op 11-07-2025 20:46 ]

[kevi-n1]

Asterion schreef op vrijdag 11 juli 2025 @ 20:32:
[...]


Bedankt voor de tip.
Ik zie echter wel dat instellingen die ik gemaakt heb ongedaan zijn gemaakt.
Er zijn zelfs containers terug gekomen die ik verwijderd had.
Het is alsof er een snapshot genomen is waar hij na de reboot terug is gegaan.

Edit:
Met behulp van Chatgpt even in de logs gedoken. Daaruit blijkt dat alle wijzigingen sinds vorige maand niet naar de flashdrive zijn weggeschreven en dus alles verloren is gegaan na de reboot.
Worden normaal alle wijzigingen weggeschreven naar de flashdrive wanneer men afsluit of herstart of gebeurd dit tussentijds ook?

De flash drive wordt enkel beschreven wanneer er wijzigingen zijn en dat moet wel standaard gebeuren.
Voor de rest draait alles in het RAM geheugen.

[Asterion]

Dan wordt het een nieuwe usb stick.
Dat risico wil ik niet meer opnieuw dat het de volgende reboot weer mis gaat.

[Flans]

Asterion schreef op vrijdag 11 juli 2025 @ 22:02:
Dan wordt het een nieuwe usb stick.
Dat risico wil ik niet meer opnieuw dat het de volgende reboot weer mis gaat.

En (als je dit nog niet hebt) de plugins: 'appdata backup' & 'appdata cleanup' installeren.

De eerste om een backup te maken van je appdata map en usb stick. De tweede om (als je een container verwijderd) ook daadwerkelijke de volledige bijbehorende appdata map op te ruimen.

[alex3305]

Ik vind de Appdata backup echt de meest onzinnige plugin die er bestaat. Welke aardappel verzint het om de Docker service daarvoor te stoppen ? Ik snap best dat dat het veiligste is, maar regel dan als je bezig bent je backups gewoon correct in.

Ik gebruik nu al enkele jaren Kopia voor mijn backups. Dat is een deduplicerende backup tool. Ook als container te installeren via de apps store. De initiële opzet is niet bijster complex, maar wel even iets waar je op moet letten. Daarna heb je eigenlijk geen omkijken meer naar.

Mijn appdata en flash drive worden elke 4 / 6 uur gebackupt naar een externe disk:



Deze backup schrijf ik daarna ook weg naar twee remote locaties.

Met mijn retentie policy heb ik eveneens genoeg mogelijkheden om bij problemen nog zaken te restoren:


En de backup is via de webinterface benaderbaar en browsebaar:



Omdat Kopia comprimerend én deduplicerend werkt is mijn backup 'maar' 440GB. Terwijl 1 snapshot al 530GB zou moeten zijn.

Bovenstaand heeft natuurlijk geen zin als de configuratie niet wordt weggeschreven .

@Asterion Veel werk verloren valt ook wel weer mee. Daarnaast, als het zo belangrijk was, had je wellicht ook de tijd moeten nemen om het te documenteren .

[alex3305]

Sinds Unraid 7 heb ik eigenlijk een beetje een gek probleem. Ik ben niet 100% zeker of het door Unraid 7 komt, maar het is wel toevallig dat het sinds toen is gaan spelen. Af en toe is mijn server niet meer bereikbaar. Of eigenlijk heel traag. Het komt vast door een proces die helemaal uit de klauwen loopt, maar als ik mijn Beszel monitoring ga bekijken zie ik niets geks:



Wat ik wel zie op zo'n moment is dat kswapd0 en kcompactd0 nagenoeg alle CPU cycles opsnoepen. Als ik een of meerdere containers stop (bijv. Plex of Paperless-ngx) dan normaliseert het weer. Een reboot lost het sowieso op.

Ik heb geen swap ingesteld en volgens free of top heb ik op zo'n moment ook voldoende geheugen:

root@LeeTower:~# free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        17Gi       2.6Gi       4.1Gi        15Gi        13Gi
Swap:             0B          0B          0B

Als ik echter een stress test draai dan gaat dit ook goed:

root@LeeTower:~# docker run -ti --rm polinux/stress stress --cpu 1 --io 1 --vm 4 --vm-bytes 4G --timeout 10s
stress: info: [1] dispatching hogs: 1 cpu, 1 io, 4 vm, 0 hdd
stress: info: [1] successful run completed in 10s

En doe ik hetzelfde met 'teveel' geheugen krijg ik ook netjes een fail:

root@LeeTower:~# docker run -ti --rm polinux/stress stress --cpu 1 --io 1 --vm 8 --vm-bytes 4G --
timeout 10s
stress: info: [1] dispatching hogs: 1 cpu, 1 io, 8 vm, 0 hdd
stress: FAIL: [1] (415) <-- worker 11 got signal 9
stress: WARN: [1] (417) now reaping child worker processes
stress: FAIL: [1] (451) failed run completed in 3s

Gek genoeg is daarna de buff/cache wel een heel stuk leger, maar volgens mij betekend dat niets.

root@LeeTower:~# free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        14Gi        15Gi       4.1Gi       5.6Gi        16Gi
Swap:             0B          0B          0B

Het enige echte aanknopingspunt of iets wat echt heel vreemd is, is dat mijn Caddy setup met caddy-docker-proxy compleet stopt met werken. Het is dus net of Docker API / Socket niet meer bereikbaar is . Maar ik zie daar verder niets geks terug. Ook niet in de Unraid logging.

Vergelijkbare problemen heb ik ook gevonden op het Unraid forum, maar zonder resultaat. Ik vind het wel jammer want Unraid 6 was enorm stabiel.

[canonball]

alex3305 schreef op donderdag 17 juli 2025 @ 12:18:
Sinds Unraid 7 heb ik eigenlijk een beetje een gek probleem. Ik ben niet 100% zeker of het door Unraid 7 komt, maar het is wel toevallig dat het sinds toen is gaan spelen. Af en toe is mijn server niet meer bereikbaar. Of eigenlijk heel traag.

Ik had er ook last van, de echte oorzaak weet ik niet maar het gaat hier weer een tijdje goed.

Mijn vermoeden was krusader, die heb ik nu gestopt en er sinsdien geen last meer van. Het is bij mij begonnen een paar weken geleden, lang nadat ik na versie 7 ben gegaan, en krusader is zover ik zie afgelopen tijd niet update. Het blijft voor mij dus een vermoeden, maar mocht je ook krusader gebruiken, probeer die dan eens een tijdje te stoppen.

[alex3305]

@canonball Ik moest googlen wat Krusader is . Dus nee, die gebruik ik niet .

Ik gebruikte eerder ook veelvuldig /dev/shm maar daar ben ik ook maar mee gestopt om dit probleem te tacklen. Dat hielp overigens wel, maar uiteindelijk komt het toch terug.

Ik heb het vermoeden dat er iets misgaat in de berekening van het beschikbare geheugen. Het swappen gebeurt als ik circa 50% van het beschikbare geheugen daadwerkelijk in gebruik heb. Als ik de Beszel stats mag geloven ligt het ook niet aan de Docker containers, want daar veranderd niets, of weinig.



Wat ik voornamelijk zo gek vind is dat de OOM killer niet getriggerd wordt, maar dat het systeem wel als een malloot gaat swappen. Bij Debian / Ubuntu systemen gaat dat in mijn ervaring toch aardig hand in hand.

Overigens post een user hier ongeveer hetzelfde en als ik dus de sysctl commando's overneem, kalmeert het systeem direct. Super vaag

[ErikRedbeard]

alex3305 schreef op donderdag 17 juli 2025 @ 12:18:
...
Vergelijkbare problemen heb ik ook gevonden op het Unraid forum, maar zonder resultaat. Ik vind het wel jammer want Unraid 6 was enorm stabiel.

WebUI niet beschikbaar is in veel gevallen dat de eerste cpu core (core 0) vol benut wordt door bijv een docker. Het % van totaal cpu gebruik heb je dan niet zoveel aan, want 100% van 1 core als je er bijv 16 hebt is niet veel, iets van 6%.

Veel van Unraid en daarbij het WebUI draait vrijwel exclusief op die core 0 en soms core 1.

Sinds ik dit heb ontdekt ben ik ook standaard zwaardere en onvertrouwde dockers/vms gaan excluden van het gebruik van core 0 en core 1, aangezien deze geprefereerd worden door Unraid. Sindsdien heb ik geen problemen meer gehad met een onbereikbare WebUI.

Dit probleem kwam dan ook wel voor in vorige Unraid versies.


Het zou tevens ook nog door teveel IOps kunnen zijn van iets. Deze zijn ook vrij singlethreaded en kunnen dan ook die WebUI op core 0 in de weg gaan zitten.


Waarom Limetech de WebUI niet een hogere prioriteit geeft snap ik niet helemaal verder, maar dat terzijde.

[ Voor 19% gewijzigd door ErikRedbeard op 21-07-2025 22:43 ]

[alex3305]

@ErikRedbeard Goede gedachte, maar die vlieger gaat bij mij niet op. Ik heb door middel van taskset de Unraid processen op andere (E-)cores draaien . Tegelijkertijd is het ook niet één core die belast wordt. Ik kijk uiteraard niet alleen in Beszel, maar dat snap jij natuurlijk wel. kswapd0 en kcompactd0 pakken ergens tussen de 4 en 8 cores met een belasting van rond de 80-120 . Dat heurt niet zo. De Unraid processen komen niet eens voor in de top (pun intended).

De hoge IOPS gedachte is eveneens een goede poging die snel strandt. De meeste van mijn processen draaien langs shfs heen omdat deze inderdaad niet erg geoptimaliseerd is. Ook niet verwonderlijk aangezien het volgens mij door middel van FUSE gaat.

Het systeem vermoed ergens uit geheugen te zijn of de behoefte krijgen om geheugen te compacten. Maar dat raakt kant noch wal omdat ik - bijvoorbeeld vorige week - nog zo'n 30-50% geheugen vrij heb, al dan niet in shared/buffers. De kernel is het hier blijkbaar ook mee eens aangezien er eveneens geen oom-killer getriggerd wordt. Dan moet er iets gaar zijn. Of dat dan een Unraid proces is, een configuratie of mijn hardware, dat weet ik niet. Maar het klopt niet.

Sinds ik vorige week het compacten en swappiness heb uitgezet met ...

sysctl -w vm.swappiness=0
sysctl -w vm.compaction_proactiveness=0
sysctl -w vm.extfrag_threshold=1000

... draait het systeem alweer een week (zonder reboot) als een zonnetje.



Toen ik echter als test de bovenstaande sysctl instellingen terugzette op de oorspronkelijke waardes ging het weer mis. Maar in ieder geval werkt het nu.

[ErikRedbeard]

alex3305 schreef op dinsdag 22 juli 2025 @ 10:50:
...

Ik ging er inderdaad vanuit dat je een vrij standaard setup draaide, maar misschien dat het iemand anders helpt verder.

De shares draaien inderdaad via FUSE wat nogal een hog kan zijn. Inderdaad gewoon vermijden met container folders en dergelijke zolang je niet de functies van de share nodig hebt voor iets.

[ Voor 6% gewijzigd door ErikRedbeard op 22-07-2025 15:17 ]

[alex3305]

ErikRedbeard schreef op dinsdag 22 juli 2025 @ 15:17:
Ik ging er inderdaad vanuit dat je een vrij standaard setup draaide, maar misschien dat het iemand anders helpt verder.

Geen probleem . Dat overkomt me wel vaker .

De shares draaien inderdaad via FUSE wat nogal een hog kan zijn. Inderdaad gewoon vermijden met container folders en dergelijke zolang je niet de functies van de share nodig hebt voor iets.

Voor read-only taken of grote bulk acties gebruik ik het wel, maar daar is het ook voor bedoeld. Alle Docker (app)data staat op SSD en wordt direct benaderd ipv shfs. Behalve als het echt niet anders kan.

Er gebeurt wel iets vreemds overigens met loads met hoge iops. Wanneer het systeem dus problemen heeft met swap/compact en ik een load start met veel iops wordt het systeem eveneens onmogelijk traag. Bijvoorbeeld ncdu. Ook wanneer dit via een directe mount gaat (bijv. /mnt/system). Vooralsnog heb ik dit eveneens onder geheugen tekort geschaard, maar misschien is dat ook niet de gehele waarheid. Dit is wederom niet meer voorgekomen.

[rsvmark]

Hoi allen,

Voor het vervangen van mijn oude synology 412+ heb ik onlangs een Aoostar WTR PRO (amd) aangeschaft.
Ik ben nog redelijk nieuw in het server OS gebeuren en na een redelijk geslaagde poging met Truenas viel mijn oog op Unraid (met zijn vele apps) en heb ik inmiddels een trial versie draaien.

Specs:
AMD Ryzen 7 5825U
32gb ram
2x nvme 2Tb als cache drives in mirror voor apps/containers/vm's.
2x 12 Tb Seagate Ironwolfs Pro (1 parity en 1 data)

Nas zal voornamelijk gebruikt worden als media server (ARR stacks), foto opslag ipv iCloud en documenten.

Nu heb ik een 3e 12Tb schijf klaarliggen maar vind het eigenlijk onnodig deze in de 'beveiligde' array te hangen omdat bijvoorbeeld muziek en film makkelijk opnieuw te vinden is (origineel staat in de kast natuurlijk).

Hoe pakken jullie dit aan? Als ik de drive toe wil voegen zie ik alleen de keuze cache of toevoegen aan de array.

[D4NG3R]

Je hebt op unRAID een enkele array, maar kan sinds 6.9 meerdere pools aanmaken. Die hoeven niet per se als cache te dienen.

Ik heb zelf bijvoorbeeld een 2e pool met een wat oudere/tragere SSD (voorheen een HDD) om downloads naar toe te schrijven. Daarvoor wil ik m'n array niet laten draaien, en m'n snelle cache SSD niet mee belasten.

[rsvmark]

D4NG3R schreef op donderdag 31 juli 2025 @ 13:20:
Je hebt op unRAID een enkele array, maar kan sinds 6.9 meerdere pools aanmaken. Die hoeven niet per se als cache te dienen.

Ik heb zelf bijvoorbeeld een 2e pool met een wat oudere/tragere SSD (voorheen een HDD) om downloads naar toe te schrijven. Daarvoor wil ik m'n array niet laten draaien, en m'n snelle cache SSD niet mee belasten.

Ik download nu ook op de cache pool (nvme's) en laat het dan via mover verplaatsen naar de array. Die laatste kan ik dus vervangen door een 2e data pool.
Ga ik proberen, thanks!

[D4NG3R]

rsvmark schreef op donderdag 31 juli 2025 @ 13:26:
[...]


Ik download nu ook op de cache pool (nvme's) en laat het dan via mover verplaatsen naar de array.

Toen ik net met unRAID begon werden SSD's nog iets minder stevig gebakken en was ik binnen een jaar door 70% van de durability van m'n cache SSD heen gevreten grotendeels door downloads.

Maar goed, dat is inmiddels ook alweer een jaar of 7-8 geleden met een vrij kleine SSD. Op moderne SSD's is het wat minder relevant. Desalniettemin probeer ik dat soort intensieve schrijfacties op m'n cache te voorkomen.

Die laatste kan ik dus vervangen door een 2e data pool.
Ga ik proberen, thanks!

Yes, je kan de 3e schijf toevoegen als 2e pool, en 'gewoon' de mover zaken tussen de array/pool1/pool2 laten schuiven.

[ Voor 6% gewijzigd door D4NG3R op 31-07-2025 13:38 ]

[StefaanDG]

D4NG3R schreef op donderdag 31 juli 2025 @ 13:33:
[...]

Toen ik net met unRAID begon werden SSD's nog iets minder stevig gebakken en was ik binnen een jaar door 70% van de durability van m'n cache SSD heen gevreten grotendeels door downloads.
[...]

Was dit niet door een bug in Unraid als er btrfs werd gebruikt voor de cache? Kan het verkeerd voorhebben. Nu mijn cache gebruikt reeds een tijd zfs.

Ben zelf ook reeds een tijd aan het denken om een nieuwe Unraid server op te zetten, niet dat de originele niet meer voldoet maar de HDD's koel houden in de Node 804 case is toch een dingetje.
Zit zelf te tobben om of wel een rack mount server te bouwen en in de berging te plaatsen daar heeft die ademruimte genoeg en dan heb 'k ook geen last van het eventuele geluid. Of een off-shelf NAS zoals de Aoostar WTR MAX of de Ugreen NASync DXP8800 Plus. Wel flink aan de prijs die laatste, voor wat meer kan ik zeker de zelfbouw route nemen.

Mijn droom case momenteel is de 45HomeLab HL15 2.0 maar ja die kost ook een aardige duit om maar niet te spreken over shipping en invoerrechten.

[D4NG3R]

StefaanDG schreef op donderdag 31 juli 2025 @ 14:02:
[...]

Was dit niet door een bug in Unraid als er btrfs werd gebruikt voor de cache? Kan het verkeerd voorhebben. Nu mijn cache gebruikt reeds een tijd zfs.

Ik heb oprecht geen idee, destijds (2017-18) had ik een oude 128GB MX100 als cache in m'n servertje zitten, beestje was in een kleine 13 maanden van 7% lifetime used naar 71% gevlogen.

Zal op een moderne (en vooral; grotere) SSD absoluut niet zo hard gaan, desalniettemin slinger ik downloads nog altijd eerst lekker naar een losse SSD waar ik weinig om geef voordat ze elders in hun geheel worden weggeschreven.

[alex3305]

Mijn primaire 1TB Samsung SSD heb ik volgens mij met de bouw van mijn Unraid machine in de zomer van 2023 in gebruik genomen. Daarvan zegt SMART nu dat deze 20% verbruikt is met 133TB geschreven. Maar ik doe 'alles' met deze disk. Alle appdata, Docker containers, Linux ISO's downloaden, etc. Met een lineaire aftakeling (en dat is niet zo) zou deze disk dus nog bijna 8 jaar mee moeten kunnen. Ik geloof dat wel, maar vind het zeker niet onredelijk.

De 1TB Crucial P1 die ernaast zit is een jaartje ouder, maar heeft 'maar' 30TB bytes written en daardoor nog 98% levensduur. Die zal ik dus sowieso niet snel verslijten.

Opslag blijft voor mij een gebruiksproduct. Heb ik ook een mooi excuus om te upgraden .

[SaN]

Hoe regelen jullie docker container updates in Unraid? Als ik een beetje google zijn veel mensen nogal panisch over automatische updates, wat ik in principe wel begrijp. Nu heb ik mijn nieuwe unraid server met 16 docker containers ongeveer 6 weken lopen en voor 14 van de 16 containers zijn updates beschikbaar. Ik ben dus toch maar, handmatig, begonnen met updaten maar ik ben niet van plan om dat op deze manier te blijven doen aangezien het nogal wat tijd kost.

Chatgpt adviseert om handmatig te updaten en evt van tevoren de change logs te bekijken en achteraf te testen.

Hoe doen jullie dit? Ik zag dat CA Backup de mogelijkheid biedt om automatisch updates uit te laten voeren na een succesvolle backup, dat lijkt mij bijvoorbeeld wel prettig.

[D4NG3R]

Ik trek zelf wekelijks een backup van m'n containers, dus in het ergste geval kan ik de boel wel reverten. Maar heel eerlijk is dat nog nooit nodig geweest, er zijn wel een aantal containers welke ik handmatig even een versie terug heb gezet. (en een enkele container blijft daar ook op)

Ik klik af en toe op update all containers, wil wel graag weten wanneer het nu precies fout is gegaan i.p.v. eerst te moeten zoeken of er niet toevallig een update is geweest.

[Stefuit]

Bij mij staat alles op automatisch. Daar heb ik nog geen problemen mee gehad voorlopig.

[WCA]

Elke nacht een appdata backup
Elke nacht automatisch update van sommige containers, andere doe ik handmatig.

Kapot? Gewoon restoren. Ik draai niks bedrijfskritisch

[SaN]

D4NG3R schreef op maandag 4 augustus 2025 @ 12:23:
Ik trek zelf wekelijks een backup van m'n containers, dus in het ergste geval kan ik de boel wel reverten. Maar heel eerlijk is dat nog nooit nodig geweest, er zijn wel een aantal containers welke ik handmatig even een versie terug heb gezet. (en een enkele container blijft daar ook op)

Ik klik af en toe op update all containers, wil wel graag weten wanneer het nu precies fout is gegaan i.p.v. eerst te moeten zoeken of er niet toevallig een update is geweest.

Dat laatste lijkt mij ook het grootste struikelblok. Ik laat elke nacht een appdata backup maken en er worden er slechts 3 bewaard. In het slechtste geval kom je er later achter dat een container kapot is gegaan en heb je geen goede backup meer. Ik denk dat jouw oplossing een goede is.

WCA schreef op maandag 4 augustus 2025 @ 12:32:
Elke nacht een appdata backup
Elke nacht automatisch update van sommige containers, andere doe ik handmatig.

Kapot? Gewoon restoren. Ik draai niks bedrijfskritisch

Dat is ook een beetje mijn gedachte. Het is heel prettig als alles gewoon blijft werken, maar het blijft hobby. Hoe lang bewaar je jouw backups? Wat is jouw instelling?

Stefuit schreef op maandag 4 augustus 2025 @ 12:32:
Bij mij staat alles op automatisch. Daar heb ik nog geen problemen mee gehad voorlopig.

Goed om te horen. Ik neig er toch ook sterk naar om het maar gewoon te proberen met een goede backupstrategie. Het probleem is dat ik niet alle containers dagelijks gebruik, dus als er 1 kapot gaat kan het zijn dat ik daar pas veel later achter kom.

[WCA]

SaN schreef op maandag 4 augustus 2025 @ 12:53:

[...]

Dat is ook een beetje mijn gedachte. Het is heel prettig als alles gewoon blijft werken, maar het blijft hobby. Hoe lang bewaar je jouw backups? Wat is jouw instelling?

7 dagen bewaren, en ik cross-sync mijn backups via Syncthing nog naar een maat van me toe.

Is wellicht wat overkill maar ik heb zat ruimte, maat van me ook.

[SaN]

WCA schreef op maandag 4 augustus 2025 @ 13:44:
[...]


7 dagen bewaren, en ik cross-sync mijn backups via Syncthing nog naar een maat van me toe.

Is wellicht wat overkill maar ik heb zat ruimte, maat van me ook.

Helder. Ik laat ze naar een aparte schijf buiten de array schrijven. Wellicht kijk ik nog eens naar een offsite backup optie voor eens in de week bijvoorbeeld voor het geval er iets met de kast gebeurt.

Grootste angst is voor mij dat het misschien eens voorkomt dat het langer duurt voordat ik het door heb dat er een container kapot is gegaan. Vandaar dat ik de backups nu 28 dagen laat bewaren maar met 18gb per backup is dat straks 500gb aan backupruimte. Opzich niet zo erg op een 3tb schijf die eigenlijk nergens anders voor wordt gebruikt, maar het kan netter.

Ik zou het liefst hebben dat backups van de laatste week allemaal worden bewaard en dan vervolgens 5 backups van de 5 weken daarvoor. Misschien eens een scriptje maken of een meer geavanceerd backupprogramma proberen.

[alex3305]

Ik beheer mijn Docker containers buiten Unraid om met Docker Compose. Updates doe ik met automatisch met Renovate en Forgejo Actions. Daar heb ik een hele tijd geleden alweer iets over geschreven in het Docker topic.

Dit zorgt ervoor dat ik precies kan zien wat wanneer gewijzigd is, en dus eventueel ook kan ingrijpen. Deze automatische updates gebeuren alleen overdag. Eveneens heb ik sommige updates zo ingesteld dat deze goedkeuring vereisen. Bijvoorbeeld bij Home Assistant en Zigbee2MQTT. Ik heb namelijk geen zin in onverwachte verrassingen.

Docker Compose (en Docker Swarm) installeer en configureer ik overigens met Ansible in plaats van de kant-en-klare Docker Compose uit de Apps store. Dit is niets meer dan de GitHub release uitpakken in /usr/local/lib/docker/cli-plugins/ en de juiste 0755 permissie meegeven. Deze houdt ik eveneens up to date met Renovate.

Backups maak ik met een Kopia container. Na de opzet heb ik hier geen omkijken meer naar en mijn appdata backups blijven tot één jaar bewaard. Door de deduplication neemt dit ook niet bijster veel ruimte in. Database snapshots maak ik live met de Postgres of MariaDB/MySQL tooling. Dit is ook niets meer dan een oneliner:

# PostgreSQL
docker exec -i immich-database /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /mnt/applications/appdata/immich/database.sql

# MariaDB / MySQL
docker exec -i home-assistant-database sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'

De database data / WALs houdt ik buiten de backup omdat deze waarschijnlijk toch niet (correct) te restoren zijn.

Denk er overigens aan dat backups alleen nuttig zijn als je ook regelmatig de restore test . Een backup zonder restore (test) is geen backup, maar waardeloze bytes.

[SaN]

alex3305 schreef op maandag 4 augustus 2025 @ 13:57:
Ik beheer mijn Docker containers buiten Unraid om met Docker Compose. Updates doe ik met automatisch met Renovate en Forgejo Actions. Daar heb ik een hele tijd geleden alweer iets over geschreven in het Docker topic.

Dit zorgt ervoor dat ik precies kan zien wat wanneer gewijzigd is, en dus eventueel ook kan ingrijpen. Deze automatische updates gebeuren alleen overdag. Eveneens heb ik sommige updates zo ingesteld dat deze goedkeuring vereisen. Bijvoorbeeld bij Home Assistant en Zigbee2MQTT. Ik heb namelijk geen zin in onverwachte verrassingen.

Docker Compose (en Docker Swarm) installeer en configureer ik overigens met Ansible in plaats van de kant-en-klare Docker Compose uit de Apps store. Dit is niets meer dan de GitHub release uitpakken in /usr/local/lib/docker/cli-plugins/ en de juiste 0755 permissie meegeven. Deze houdt ik eveneens up to date met Renovate.

Backups maak ik met een Kopia container. Na de opzet heb ik hier geen omkijken meer naar en mijn appdata backups blijven tot één jaar bewaard. Door de deduplication neemt dit ook niet bijster veel ruimte in. Database snapshots maak ik live met de Postgres of MariaDB/MySQL tooling. Dit is ook niets meer dan een oneliner:

# PostgreSQL
docker exec -i immich-database /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /mnt/applications/appdata/immich/database.sql

# MariaDB / MySQL
docker exec -i home-assistant-database sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'

De database data / WALs houdt ik buiten de backup omdat deze waarschijnlijk toch niet (correct) te restoren zijn.

Denk er overigens aan dat backups alleen nuttig zijn als je ook regelmatig de restore test . Een backup zonder restore (test) is geen backup, maar waardeloze bytes.

Wow.. Haha bedankt! Gemini had het ook al over het nut van een restore test. Ik ga ernaar kijken.

[WCA]

SaN schreef op maandag 4 augustus 2025 @ 14:02:
[...]

Wow.. Haha bedankt! Gemini had het ook al over het nut van een restore test. Ik ga ernaar kijken.

Ondanks dat ik beter weet, moet ik zeggen dat ik eigenlijk nooit echt geplande restore tests doen. Wel ongeplande, als ik iets kapot gemaakt heb

[alex3305]

Nadat ik relatief recent naar Unifi ben overgestapt heb ik vandaag eindelijk de moeite genomen om ook VLANs in te regelen op mijn Unraid machine. Ik zag hier een beetje tegen op door de enorm moeizame ervaring van een kennis van me, maar die zorgen waren uiteindelijk onterecht.

In Unifi heb ik allereerst een VLAN aangemaakt met ID 40:


Ik heb daarna dat VLAN toegevoegd met dezelfde instellingen in Unraid's Network Settings:


EDIT Ik had hier eerder staan dat IPv4 Address Assignment op None moest staan, maar dat klopt niet. Dit moet Automatic zijn. De None optie werkt maar maakt geen bridge of shims aan waardoor container <> container communicatie niet werkt. De Static optie is ook mogelijk, maar ik houd het liever dynamisch.

En vervolgens ook toegewezen in Docker Settings:


Dat was het eigenlijk .

Na het aanpassen van het netwerk in de Compose definitie, werkte dit out of the box.

[ Voor 14% gewijzigd door alex3305 op 04-08-2025 16:24 ]

[SaN]

WCA schreef op maandag 4 augustus 2025 @ 14:05:
[...]


Ondanks dat ik beter weet, moet ik zeggen dat ik eigenlijk nooit echt geplande restore tests doen. Wel ongeplande, als ik iets kapot gemaakt heb

En dat ging goed?

[WCA]

SaN schreef op maandag 4 augustus 2025 @ 17:01:
[...]

En dat ging goed?

Altijd goed gegaan.

[Stefuit]

Ik heb sinds kort ZFS geïnstalleerd voor mijn cache waar mijn dockers en vm's op staan. Moet alleen nog eens kijken om automatische snapshots te nemen en deze in de array te plaatsen. Moet het nu manueel doen

Als je dat moest doen kan je zeer snel herbeginnen moest er toch iets mis gaan.
Spaceinvaderone heeft hiervoor een video gemaakt hoe je dit moet doen. Alleen voor automatische snapshots gebruikt hij een ZFS schijf in de array. Dus weet ik niet of dit zal werken als je geen ZFS schijf hebt.

[masauri]

Heb iets geks aan de hand, kan plots niet meer via mijn gebruikersnaam en wachtwoord inloggen.
Via tailscale wel zonder problemen.
2 dockers doen ook ineens raar..
Die van sabnzb geeft me dit:
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2025-08-12 21:16:10.492360 [info] Host is running unRAID
2025-08-12 21:16:10.521416 [info] System information: Linux 7d0e52c9c61a 6.12.24-Unraid #1 SMP PREEMPT_DYNAMIC Sat May 3 00:12:52 PDT 2025 x86_64 GNU/Linux
2025-08-12 21:16:10.551453 [info] Application name: 'sabnzbdvpn'
2025-08-12 21:16:10.582937 [info] Base image release tag: '2025072801'
2025-08-12 21:16:10.621702 [info] Output image release tag: '4.5.2-1-03'
2025-08-12 21:16:10.679685 [info] PUID defined as '99'
2025-08-12 21:16:10.728942 [info] PGID defined as '100'
2025-08-12 21:16:10.788370 [info] UMASK defined as '000'
2025-08-12 21:16:10.827723 [info] Permissions already set for '/config'
2025-08-12 21:16:10.867236 [info] Deleting files in /tmp (non recursive)...
2025-08-12 21:16:10.917944 [info] VPN_ENABLED defined as 'no'
2025-08-12 21:16:10.947912 [warn] !!IMPORTANT!! VPN IS SET TO DISABLED', YOU WILL NOT BE SECURE
2025-08-12 21:16:11.007530 [warn] ENABLE_SOCKS not defined (via -e ENABLE_SOCKS), defaulting to 'no'
2025-08-12 21:16:11.106799 [info] ENABLE_PRIVOXY defined as 'yes'
2025-08-12 21:16:11.198085 [info] Starting Supervisor...
2025-08-12 21:16:11,488 INFO Included extra file "/etc/supervisor/conf.d/sabnzbdvpn.conf" during parsing
2025-08-12 21:16:11,488 INFO Set uid to user 0 succeeded
2025-08-12 21:16:11,500 INFO RPC interface 'supervisor' initialized
2025-08-12 21:16:11,501 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2025-08-12 21:16:11,502 INFO supervisord started with pid 7
2025-08-12 21:16:12,504 INFO spawned: 'start-script' with pid 75
2025-08-12 21:16:12,506 INFO spawned: 'watchdog-script' with pid 76
2025-08-12 21:16:12,509 DEBG 'start-script' stdout output:
[info] VPN not enabled, skipping configuration of VPN

2025-08-12 21:16:12,510 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2025-08-12 21:16:12,510 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2025-08-12 21:16:12,510 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 23119098092176 for <Subprocess at 23119097297760 with name start-script in state RUNNING> (stdout)>
2025-08-12 21:16:12,510 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 23119097733008 for <Subprocess at 23119097297760 with name start-script in state RUNNING> (stderr)>
2025-08-12 21:16:12,511 INFO exited: start-script (exit status 0; expected)
2025-08-12 21:16:12,511 DEBG received SIGCHLD indicating a child quit
2025-08-12 21:16:12,515 DEBG 'watchdog-script' stdout output:
[info] SABnzbd not running

2025-08-12 21:16:12,515 DEBG 'watchdog-script' stdout output:
[info] Attempting to start SABnzbd...

2025-08-12 21:16:13,148 DEBG 'watchdog-script' stdout output:
[info] SABnzbd process started
[info] Waiting for SABnzbd process to start listening on port 8080...

2025-08-12 21:16:13,155 DEBG 'watchdog-script' stdout output:
[info] SABnzbd process is listening on port 8080

2025-08-12 21:16:13,159 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2025-08-12 21:16:13,162 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2025-08-12 21:16:14,170 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2025-08-12 21:16:14,174 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

Maar wil dus geen webgui geven of verder starten.

Nextcloud geeft me dit:
curl: (6) Could not resolve host: ghcr.io
Trying to fix docker.sock permissions internally...
Creating docker group internally with id 281
The environmental variable TZ has been set which is not supported by AIO since it only supports running in the default Etc/UTC timezone!
The correct timezone can be set in the AIO interface later on!
Initial startup of Nextcloud All-in-One complete!
You should be able to open the Nextcloud AIO Interface now on port 8080 of this server!
E.g. https://internal.ip.of.this.server:8080
⚠️ Important: do always use an ip-address if you access this port and not a domain as HSTS might block access to it later!

If your server has port 80 and 8443 open and you point a domain to your server, you can get a valid certificate automatically by opening the Nextcloud AIO Interface via:
https://your-domain-that-points-to-this-server.tld:8443
Total reclaimed space: 0B
Could not reach https://ghcr.io.
Most likely is something blocking access to it.
You should be able to fix this by following https://dockerlabs.collab...king/Configuring_DNS.html
Another solution is using https://github.com/nextcl.../tree/main/manual-install
See https://github.com/nextcl...manual-install/latest.yml

Ik weet niet waar ik het moet gaan zoeken???

[alex3305]

@masauri Alle containers en VM's afsluiten, eventueel Docker en array stoppen en kijken of het dan wel werkt. Eventueel rebooten en vanaf daar weer terug op gaan bouwen.

Ik ben geen kennis van Tailscale of andere VPN setups, maar als je niet meer kunt inloggen zal er vast iets mis zijn met (dubbele) poort mappings waardoor het niet meer werkt.

Daarom vind ik ook dat bridge en host networking standaard niet gebruikt moet worden.

[D4NG3R]

@masauri Zo uit het niets, of na gewijzigde instellingen of iets van een update?

( Waarom trouwens een van Binhexes z'n VPN containers draaien met Privoxy, zonder dat het VPN aspect actief is? )

[masauri]

D4NG3R schreef op woensdag 13 augustus 2025 @ 11:48:
@masauri Zo uit het niets, of na gewijzigde instellingen of iets van een update?

( Waarom trouwens een van Binhexes z'n VPN containers draaien met Privoxy, zonder dat het VPN aspect actief is? )

zo uit t niets idd...
ik heb indertijd de migratie door ed van spaceinvaders laten uitvoeren dus het heeft allemaal perfect gewerkt... tot nu dus...

[Flans]

Automatische update van 1 van de docker containers gehad wellicht?

[ Voor 35% gewijzigd door Flans op 13-08-2025 15:52 ]

[masauri]

Flans schreef op woensdag 13 augustus 2025 @ 15:51:
Automatische update van 1 van de docker containers gehad wellicht?

dit kan idd wel iets zijn , al vind ik het raar dat ik daardoor niet meer zou kunnen inloggen op men server...

[Flans]

masauri schreef op woensdag 13 augustus 2025 @ 16:54:
[...]

dit kan idd wel iets zijn , al vind ik het raar dat ik daardoor niet meer zou kunnen inloggen op men server...

Het zou inderdaad niet mogen... Maar als je Sabnzbd en Nextcloud en je eigen server bij default op 8080 worden gezet. Los daarvan draaien er (als ik het goed begrijp) twee VPN'en waarvan je er 1 gebruikt. Dan zijn er wel wat mogelijkheden te bedenken.

[tomdh76]

Ik heb sinds dit weekend een unRAID server en ben enthousiast over de webui en shares aanmaken. Heb er een jellyfin container opgezet die ook prima werkt. Het enige wat me opviel was dat er gelijk ongeveer 150 Gb ruimte bezet was? Ik heb 3 schijven erin (8TB) waarvan 1 parity. Maar dus bij deze nieuwe geformatteerde schijven direct 150 gb gebruik. Is dit normaal? Het OS staat toch op de USB?

[Flans]

SaN schreef op maandag 4 augustus 2025 @ 12:17:
Hoe regelen jullie docker container updates in Unraid? Als ik een beetje google zijn veel mensen nogal panisch over automatische updates, wat ik in principe wel begrijp. Nu heb ik mijn nieuwe unraid server met 16 docker containers ongeveer 6 weken lopen en voor 14 van de 16 containers zijn updates beschikbaar. Ik ben dus toch maar, handmatig, begonnen met updaten maar ik ben niet van plan om dat op deze manier te blijven doen aangezien het nogal wat tijd kost.

Chatgpt adviseert om handmatig te updaten en evt van tevoren de change logs te bekijken en achteraf te testen.

Hoe doen jullie dit? Ik zag dat CA Backup de mogelijkheid biedt om automatisch updates uit te laten voeren na een succesvolle backup, dat lijkt mij bijvoorbeeld wel prettig.

Het meeste is ondertussen wel gezegd. Ik doe het updaten zoveel mogelijk automatisch ik heb alleen een 'vertraging' van een paar dagen toegevoegd. Daarvoor gebruik ik de plugin 'Auto Update Applications' dit werkt zowel voor plugins als voor docker. Hij wacht nu alleen (in mijn geval) 3 dagen voordat de nieuwe versie geupdate wordt. Dus als er iets mis is met een nieuwe release dan is er tegen de tijd dat het bij mij fout gaat (hopelijk) een nieuwe versie

[alex3305]

@tomdh76 Schijven hebben altijd wat overhead afhankelijk van het bestandssysteem. Dit is altijd al zo geweest . Alleen lijkt dit met de grote disks ineens enorm veel.

[Asterion]

Ik ben de laatste dagen bezig geweest om een nieuwe usb stick te maken omdat de vorige kuren begon te tonen.
Wat ben ik daar lang met bezig geweest!

De Unraid Creator Tool werkte niet omdat er geen GUID was gevonden op de stick (Sandisk probleem blijkbaar)
De manuele methode werkte ook voor geen meter ondanks dat ik wel alle stappen kan volgen.
Een live usb van Linux Mint werkt wel gewoon. Aan de usb stick ligt het dus niet.

Mijn moederbord (Kontron D3644-B1) meerdere malen default settings.
Secure boot aan of uit
TPM aan of uit. Proberen resetten.
CMOS reset
EFI folder 'aan of uit' gezet
Moederbord ondersteund UEFI dus daar verwachtte ik geen probleem omdat Unraid dat ook gewoon ondersteund.
Moederbord heeft ook de laatste BIOS update gehad.

Uiteindelijk kwam ik erachter dat de usb ingesteld stond als GPT. Wat goed is voor UEFI dacht ik dan.
Als laatste poging heb ik dit omgezet naar MBR en je verwacht het niet maar Unraid start dus gewoon op.

Kan iemand me uitleggen waarom het met MBR wel lukt maar niet met GPT?
Het moederbord ondersteunt gewoon UEFI.
De Linux Mint Live CD werkte wel gewoon onder UEFI. Waarom Unraid dan niet?

[Flans]

Asterion schreef op donderdag 4 september 2025 @ 10:45:

Kan iemand me uitleggen waarom het met MBR wel lukt maar niet met GPT?
Het moederbord ondersteunt gewoon UEFI.

Hoewel je moederbord UEFI ondersteunt, maakt dat niet zoveel uit omdat Unraid expliciet een MBR-geformatteerde USB verwacht. Heeft niks met je hardware te maken maar hoe Unraid is ontworpen.

• Unraid gebruikt een hybride bootmethode waarbij de USB-stick bootable moet zijn via syslinux, die werrkt met de BIOS en MBR.
• Ook als je in UEFI-mode opstart, verwacht Unraid nog steeds dat de stick een MBR-partitietabel met een FAT32-partitie bevat en dat de EFI-bootbestanden op de juiste plek staan.
• Als de stick GPT-geformatteerd is, dan herkent de Unraid bootloader de stick meestal niet als geldig opstartmedium, zelfs als de EFI-structuur technisch gezien correct is.

Asterion schreef op donderdag 4 september 2025 @ 10:45:
De Linux Mint Live CD werkte wel gewoon onder UEFI. Waarom Unraid dan niet?

Linux Mint (en vrijwel alle moderne Linux-distributies):

• Gebruiken GRUB of systemd-boot, die goed werken met GPT en UEFI.
• Hebben een volledig uitgewerkte UEFI-bootstructuur, inclusief een geconfigureerde EFI-partitie met bootloaders.
• Zijn ontworpen om op allerlei soorten systemen en BIOS/UEFI-configuraties te werken, inclusief secure boot (soms met handmatige ondertekening).

Unraid daarentegen:

• Is gebaseerd op Slackware en gebruikt nog syslinux in plaats van GRUB.
• Heeft beperkte UEFI-ondersteuning en verwacht een traditionele BIOS/MBR-structuur, ook als UEFI wordt gebruikt.
• Is minder flexibel dan moderne Linux distro’s wat betreft het detecteren van GPT-partities of niet-standaard bootmethodes.

Asterion schreef op donderdag 4 september 2025 @ 10:45:

Hoe kan het dat de USB geen GUID had volgens de Unraid USB Creator Tool, maar toch werkte via de handmatige methode?

Dit is een bekend probleem met Sandisk USB-sticks en goed om even te checken voordat je begint. Voor sommige modellen geldt: Dat ze geen geen unieke GUID of serienummer rapporteren aan het systeem, waardoor de Unraid USB Creator Tool denkt dat het geen geldige stick is.
Bij de handmatige installatie kun je die check omzeilen, maar je kunt dan later tegen problemen aanlopen bij het activeren van je licentie.

[Flans]

Ik ben zelf bezig met het toevoegen van twee nieuwe servers. 1 voor interne backup en 1 voor het high available maken van Pi-Hole en Home Assistant (vooral om ervoor te zorgen dat 'het huis het blijft doen' ). Ik wil ze eigenlijk beide truenas laten draaien om op die manier ook dat wat te leren kennen.

• De backup server is/wordt redelijk straight forward. Elke nacht wordt die door WoL aangezet om vervolgens intern een backup te draaien en deze backup ook meteen naar de cloud door te zetten. Deze server wordt dus mijn 2 en 1 van de 3, 2, 1 methode.
• De HA server heb ik nog niet helemaal helder, hoe ik dat voor elkaar moet krijgen. Hoe ga ik de twee instances van Pi-Hole en Home Assistant in sync houden? Hoe kun je het best de failover regelen? Doorgeven van de zigbee controller aan twee systemen?

Het lijkt erop alsof hetgeen ik wil niet kan en ik zou eigenlijk over moeten stappen op iets als proxmox. Zijn er mensen hier die dit al werkend hebben en wat insight kunnen delen?

[Asterion]

Wauw, bedankt voor de heldere uitleg! :-)

[DennusB]

Flans schreef op vrijdag 5 september 2025 @ 07:13:
Ik ben zelf bezig met het toevoegen van twee nieuwe servers. 1 voor interne backup en 1 voor het high available maken van Pi-Hole en Home Assistant (vooral om ervoor te zorgen dat 'het huis het blijft doen' ). Ik wil ze eigenlijk beide truenas laten draaien om op die manier ook dat wat te leren kennen.

• De backup server is/wordt redelijk straight forward. Elke nacht wordt die door WoL aangezet om vervolgens intern een backup te draaien en deze backup ook meteen naar de cloud door te zetten. Deze server wordt dus mijn 2 en 1 van de 3, 2, 1 methode.
• De HA server heb ik nog niet helemaal helder, hoe ik dat voor elkaar moet krijgen. Hoe ga ik de twee instances van Pi-Hole en Home Assistant in sync houden? Hoe kun je het best de failover regelen? Doorgeven van de zigbee controller aan twee systemen?

Het lijkt erop alsof hetgeen ik wil niet kan en ik zou eigenlijk over moeten stappen op iets als proxmox. Zijn er mensen hier die dit al werkend hebben en wat insight kunnen delen?

Je kan voor Home Assistant in ieder geval een MySQL backend gebruiken, die kan je prima laten repliceren. Maar met Home Assistant is er veel meer ellende als je met dingen als Zigbee & ZWave aan de gang wilt. Ik zou het vooral als VM draaien en die laten repliceren zodat je die snel kan booten als t echt mis is ..

[StefaanDG]

@Flans , benieuwd welke hardware je gebruik voor die nieuwe servers. Voor Pi-hole kan je eventueel gebruik maken van keepalived maar idealiter hebben je dan best 3 pi-hole instances nodig. Geen idee of dat ook lukt met HA, vermoed van wel. Zelf nog geen ervaring mee.

Doe je je back-up van de ene server naar de andere, via rsync of iets anders?

---

Zelf een door mijn broer geschonken Lenovo M70S in gebruik genomen als een altijd-aan Unraid server zodat zijn grote broer meer idle of in slaap kan staan en ook alleen nog media Docker containers zal draaien. Pi-hole, Nextcloud, Bitwarden, Speedtesttracker, NPM, ... verhuizen allemaal naar deze Lenovo.

Er zit nu een NVME van 1TB in die Lenovo (zat er reeds in, dus ook gratis, dank u wel broer 🙂) en ook een SATA SSD, wou er nog een andere SATA SSD in stoppen, maar natuurlijk weer een typische eigen Lenovo SATA power oplossing die ik nodig heb met 4 pinnen op het moederbord, en daar vragen ze snel $40 voor. Zal dus een extra NVME worden op een PCI insteekkaart.