Virtuele-machineback-ups beschermen tijdens onderhoud aan de hostopslag

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.

Bescherm back-ups van virtuele machines tijdens onderhoud aan de hostopslag door eerst nieuwe schrijfbewerkingen te stoppen, bestaande herstelpunten te verifiëren en minstens één bruikbare kopie buiten de opslag die wordt onderhouden te bewaren.

Op een thuisserver of kleine NAS vindt onderhoud vaak plaats aan dezelfde schijven, pool, HBA, behuizing of datastore waarin ook VM-back-ups staan. Daarom is de veilige volgorde belangrijker dan de gebruikte tool: bevries back-upactiviteiten, controleer of herstelpunten leesbaar zijn, zorg dat het onderhoud omkeerbaar is en wijzig pas daarna de opslaglaag van de host.

Breng in kaart welke back-ups afhankelijk zijn van de opslag die je wilt aanpassen

Begin met het opsommen van elke VM, container, back-uptaak, repository, snapshotlocatie en replicatiedoel die gegevens lezen van of schrijven naar de opslag die wordt onderhouden. De belangrijkste vraag is niet waar de VM draait, maar of de back-upketen of herstelcatalogus afhankelijk is van het onderdeel dat je offline wilt halen.

Een veelvoorkomende valkuil in thuislabs is dat de VM-schijven en de back-uprepository op verschillende datasets staan, maar wel op dezelfde pool, USB-behuizing, controller of enkele machine. Dat verbetert de organisatie, maar beschermt de back-up niet als het risico de hele pool, controller of host betreft.

Als een herstelpad afhankelijk is van dezelfde opslag, markeer die back-up dan als niet beschikbaar tijdens het onderhoudsvenster. Ga pas verder nadat je een tweede kopie, een externe kopie of een geteste export hebt die het apparaat dat wordt onderhouden niet nodig heeft.

Zet het back-updoel in een status waarin geen nieuwe schrijfbewerkingen zijn toegestaan

Het veiligste onderhoudsvenster begint met het voorkomen dat nieuwe back-ups, opschoningsbewerkingen, verdichting, replicatie en garbagecollection starten terwijl de opslaglaag wordt gewijzigd. Een rustige repository is eenvoudiger te beoordelen dan een repository die op de achtergrond indexen of chunks herschrijft.

Proxmox Backup Server ondersteunt alleen-lezen- en offline-onderhoudsmodi voor datastores, waarbij conflicterende bewerkingen eerst mogen worden voltooid voordat de modus actief wordt. Dat onderscheid is belangrijk, omdat alleen-lezen mogelijk nog herstelbewerkingen toestaat, terwijl offline zowel lezen als schrijven blokkeert.

Gebruik de minst ingrijpende modus die de taak beschermt. Voor firmware, bekabeling, het importeren van een pool, het vervangen van schijven of bestandssysteemreparaties is offline meestal veiliger; voor controles aan de repository waarvoor alleen nieuwe schrijfbewerkingen moeten worden gestopt, kan alleen-lezen voldoende zijn. Vertrouw niet op je geheugen: leg de modus en de uitgeschakelde taken vast.

Verifieer herstelpunten voordat je opslag verplaatst of repareert

Een back-up die niet is geverifieerd, is slechts een mogelijk herstelpunt. Voer vóór het onderhoud de verificatie van de tool uit of herstel op zijn minst een kleine, geïsoleerde omgeving vanaf het nieuwste en oudste herstelpunt dat je wilt bewaren.

Proxmox Backup Server biedt geplande verificatietaken, zodat back-upgegevens periodiek kunnen worden gecontroleerd in plaats van pas tijdens een herstel te worden vertrouwd. Voor onderhoud is een recent verificatieresultaat nuttiger dan een melding van een geslaagde back-up van weken geleden.

Als de verificatie mislukt, stop dan met het onderhoudsplan en repareer eerst de back-upset. Als slechts één herstelpunt de verificatie doorstaat, houd het dan geïsoleerd en snoei of verdicht niets totdat er een tweede goed herstelpad beschikbaar is.

-15% OFF
Single board computer zimaboard2

Bewaar één herstelkopie buiten de impactzone van het onderhoud

Voordat je schijven, pools, controllers, koppelopties of de indeling van de repository wijzigt, verplaats je minstens één herstelkopie buiten de impactzone. Dat kan een verwijderbare schijf, een andere NAS, een externe Proxmox Backup Server, cloudobjectopslag of een tijdelijke export van de belangrijkste VM’s zijn.

De documentatie van Veeam over schaalbare repositories behandelt repositoryonderhoud als een toestandgebonden bewerking en legt uit dat een extent in Maintenance mode kan worden geplaatst voor werkzaamheden zoals het patchen of upgraden van een extent. De onderliggende les is breed toepasbaar: onderhoud moet worden afgestemd op de toestand van de repository en niet worden uitgevoerd als een blinde opslagbewerking.

Kies voor een thuisserver de kopie die aansluit op je werkelijke herstelbehoefte. Een opstartbare export kan beter zijn voor één kritieke VM, terwijl deduplicerende back-upreplicatie beter kan zijn voor veel VM’s. De kopie is pas bruikbaar als je weet waar die zich bevindt, hoe je deze ontgrendelt en hoe je ervan herstelt zonder de opslag van de host die wordt onderhouden.

Schakel taken pas weer in na een controle van het herstelpad

Schakel na het onderhoud niet onmiddellijk alle geplande taken weer in. Koppel de opslag eerst opnieuw aan of importeer deze op een correcte manier, controleer het eigendom van de repository en de beschikbare ruimte en voer vervolgens een leestest uit op bestaande back-ups voordat je nieuwe schrijfbewerkingen toestaat.

Onderhoudstaken voor back-ups kunnen veel I/O-belasting veroorzaken. De best practices van Veeam beschrijven onderhoud van volledige back-upbestanden als een proces dat een nieuw volledig back-upbestand samenstelt en het oorspronkelijke bestand daarna verwijdert. Dit soort bewerkingen moet je niet gelijktijdig met opslagreparaties of instabiele schijven uitvoeren.

Breng services in deze volgorde weer online: opslagstatus, leestoegang tot de repository, lijst met herstelpunten, een kleine hersteltest en daarna geplande schrijfbewerkingen. Als een stap traag, ontbrekend of inconsistent is, houd je de taken uitgeschakeld en onderzoek je het probleem voordat een nieuwe back-upketen het probleem verbergt.

Veelgestelde vragen

Kan ik VM-back-ups laten doorlopen terwijl ik een schijf in de host vervang?

Alleen als de back-uprepository en het herstelpad duidelijk buiten de opslag vallen die wordt onderhouden. Als het back-updoel dezelfde pool, controller, behuizing of hostafhankelijkheid gebruikt, stop dan eerst nieuwe schrijfbewerkingen.

Is een VM-snapshot voldoende bescherming vóór opslagonderhoud?

Nee. Een snapshot op dezelfde opslag kan helpen bij snel terugdraaien, maar beschermt niet tegen een defect aan de pool, controller, behuizing of host. Bewaar een onafhankelijke back-upkopie.

Als je onderhoud ook ZFS-replicatie omvat, controleer dan vóór het onderhoudsvenster het retentie- en gedrag bij beperkte vrije ruimte. Een volle bestemmingspool kan een eenvoudige onderhoudstaak veranderen in hetzelfde foutpatroon dat wordt beschreven in de ZimaSpace-gids voor het voorkomen dat snapshotreplicatie een bestemmingspool vult.

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.