Back-upchecklist voor Proxmox-thuisservers voor VM's, LXC en hostconfiguratie

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een geslaagde back-up van een Proxmox-guest is niet compleet als bind mounts, applicatiestatus, hostconfiguratie, sleutels of de repository hetzelfde storingsdomein delen.

Voor een homeserver waarop VM's en LXC-containers draaien, omvat herstel guestschijven, externe gegevens, databases, netwerken, opslagdefinities, firewallstatus, passthrough-toewijzingen, inloggegevens en het proces voor het opnieuw opbouwen van een lege host. Breng die lagen in kaart voordat je back-upmodi kiest, bewaar een kopie buiten de host en bewijs zowel dat een guest kan worden hersteld als dat herstel op hostniveau mogelijk is. Stop pas met het bewaren van oudere herstelpunten wanneer een van beide tests een ongedocumenteerde afhankelijkheid aan het licht brengt.

Breng elke herstellaag en elk storingsdomein in kaart

Noteer elke VM en LXC, virtuele schijven, snapshots, bind mounts, passthrough-apparaten, applicatiedatabases, externe NAS-shares, encryptiesleutels en back-uptaken. Breng vervolgens hostnetwerken, opslagdefinities, cluster- of standalone-status, firewallregels, geplande taken, pakketbronnen en de notities die nodig zijn om hardwaretoewijzingen opnieuw te maken in kaart.

Proxmox VE kan guestback-ups schrijven naar lokale, NFS- of CIFS-doelen, terwijl een speciale back-upserver repositoryfuncties toevoegt. Een onafhankelijke keuze van guest-back-updoelen legt die scheiding uit, maar geen van beide doelen bevat automatisch gegevens die vanuit elders in een guest zijn gemount, of het host-herbouwrecord.

Teken storingsdomeinen uit voordat je retentie kiest. Een repository op dezelfde host, pool, UPS of met dezelfde beheerdersgegevens als productie is een nuttig herstelpunt, maar niet de onafhankelijke kopie die nodig is bij verlies of diefstal van de host, ransomware of het per ongeluk vernietigen van een pool.

Stem de back-upmodus af op elke workload

Classificeer guests als stateless, bestandsserver, transactionele database of gemengde applicatie. Noteer of de back-upmodus een applicatieconsistente of alleen crashconsistente toestand oplevert, welke guest-agent of hook meedoet en welke externe paden buiten het archief blijven.

Gebruik de ZimaSpace-workflow voor het afstemmen van back-upmodi op workloads om per workload te kiezen tussen stoppen, pauzeren of snapshots maken. Een rustige VM-desktop en een database die schrijfbewerkingen accepteert, mogen niet dezelfde aanname krijgen alleen omdat beide taken groen eindigen.

Maak voor LXC-bind mounts en door de host gemounte shares expliciete back-ups van bestanden of applicaties met hetzelfde herstelmoment wanneer consistentie dat vereist. Als de vereiste status niet kan worden gecoördineerd, documenteer dan het gat en gebruik een onderhoudsvenster in plaats van te suggereren dat het guest-archief compleet is.

Bescherm de hostconfiguratie en de repository

Exporteer een leesbaar host-herstelpakket met netwerkinterfaces, opslagconfiguratie, VM- en containerdefinities, firewallregels, relevante clusterbestanden, geplande taken, repository-eindpunten en een inventaris van pakketten en versies. Bewaar geheimen en encryptiesleutels in een beveiligd systeem voor inloggegevens, niet in een openbare herstelnotitie.

Een discussie over back-ups in de Proxmox-community stelt precies de vraag hoe zit het met de systeemconfiguratie nadat VM- en containerarchieven zijn ingesteld. Beschouw die vraag als een waarschuwing over de scope: bescherming van de hostconfiguratie staat los van guest-back-ups en moet worden getest als hulpmiddel voor het opnieuw opbouwen.

Voer repositoryverificatie, een retentievoorbeeld en het kopiëren buiten de host uit volgens planningen die niet kunnen botsen met destructief onderhoud. Waarschuw bij gemiste taken, verificatiefouten, capaciteitsdruk en een ongewijzigde repository terwijl productie nog actief is.

-15% OFF
Single board computer zimaboard2

Herstel een guest en oefen het opnieuw opbouwen van een host

Herstel één VM en één LXC met geïsoleerde ID's en netwerken. Start databases vóór afhankelijke applicaties, koppel gekopieerde bind-mountgegevens en controleer de aanmelding, de servicestatus, recente records, bestandsrechten en een tweede herstart. Verbind testguests niet met productiestorage met schrijfrechten.

Oefen vervolgens herstel op een lege host met reservehardware of een wegwerpbare geneste host: installeer de hypervisor, herstel netwerk- en opslagdefinities bewust, koppel de repository en herstel één kritieke guest. Noteer elke ongedocumenteerde afhankelijkheid en werk het draaiboek bij.

De checklist is geslaagd wanneer er onafhankelijke kopieën bestaan, de verificatie actueel is, guest-herstel werkt en de host kan worden herbouwd zonder de defecte opstartschijf. Escaleer ontbrekende sleutels, inconsistente databases, repositoryfouten of passthrough-toewijzingen die niet opnieuw kunnen worden gemaakt voordat je een ouder herstelpunt verwijdert.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.