Bedankt FJ, ik ga dit ook opzetten.FREAKJAM schreef op maandag 06 oktober 2014 @ 22:50:
A1AD, as promised een screenshot van Nakivo. Zoals je ziet doet hij er ~2min over om 7 VM's te backuppen die bij elkaar 115GB zijn.
[afbeelding]
Mijn eerste idee was (zoals jij?) om mijn backups te plaatsten op de ISCSI ZFS storage die ik terug geef aan ESX maar deze is niet beschikbaar wanneer je de ESX config file nodig hebt.
Mijn VM's zijn verdeeld over een lokale 2.5inch 500GB disk en lokale ISCSI/ZFS storage.
Opties voor een backup datastore (ESX data, geen NAS data):
Op de ZFS disks plaatsen:
- voordeel: ZFS, en al reeds aanwezig
- nadeel: deze storage is niet altijd beschikbaar, afhankelijk van je NAS VM. Een backup nemen van je VM's op de ISCSI datastore en deze terug plaatsen op dezelfde pool = niet zo nuttig.
- voordeel: onmiddellijk beschikbaar na reinstall ESX, geen afhankelijkheid
- nadeel extra disk, en?
- voordeel: onmiddellijk beschikbaar, 2de nas ook bruikbaar voor NAS data
- nadeel: kost, verbruik, complexiteit++
- voordeel: onafhankelijk van je ISCI/ZFS storage waar de VM's op draaien, geïntegreerd in je NAS software.
- nadeel: afhankelijk van je NAS VM
Nu ben ik is aan het denken wat er allemaal kan mis gaan met een ESX-ZFS-AOI server en hoe dit op te vangen.
USB boot stick defect:
Elke nacht een backup van de esx config maken.
Probleem met NAS VM (of de datastore waar de VM op staat):
Deze kunnen we niet backuppen (vt-d) dus ook elke nacht backup van config maken, als de nas problemen heeft kunnen we wederom niet aan de zfs storage dus die config mag uiteraard ook niet op de ZFS pool.
Probleem met de lokale datastore:
De VM's worden gebackuped via Nakivo op de backup datastore behalve de backup van de Nakivo VM zelf, die sturen we naar de ZFS storage (of de SSD).
> Schijf vervangen, backups terug zetten.
Probleem met de lokale backup datastore
> Schijf vervangen, hoe Nakivo recoveren? Via een config file of een tijdelijke Nakivo opzetten om de originele te recoveren van de ZFS storage (of de SSD)?
Probleem met de ZFS data incl. ISCSI datastore (lees: RaidZ1 corrupt):
> backup van data recoveren via crashplan (nog niet getest)
> backup van de ZFS VM's en config file terug plaatsen via Nakivo
Stroom probleem/overspanning/corrupte voeding > alle lokale disken defect
> Tja, belangrijke data wordt via crashplan offsite gehouden. De config files zouden ook naar de offsite backup moeten gestuurd worden. Maar het is teveel data om al de VM's offsite te backuppen.
Hoe vangen jullie dit op?
En ik ben zeker nog iets vergeten...
- Deze advertentie is geblokkeerd door Pi-Hole -