[Veeam] Back-up via file share of VM disk?

[Perphide]

Dag allemaal,

Ik heb een vraag waarvan ik hoop dat een ander hier een goed idee over heeft of misschien zelfs ervaring.
Het gaat om een Windows Server die wat file shares heeft, het betreft een VM.

Deze wil ik via Veeam back-uppen.
Nu heb ik echter twee keuzes:
1. De gehele VM (1 disk voor het OS, 2e disk waarop de file shares zich bevinden)
2. De VM (alleen OS disk) en apart nog de files op de file shares (inhoud 2e disk)

Optie 1 kost slechts 1 Veeam licentie, optie 2 kost minimaal twee licenties. Afhankelijk van hoeveel data de fileshares bevatten kost het per 250GB een licentie extra.

Ik gebruik momenteel methode 1.
Heeft het nut om over te stappen naar methode 2?

Nu stel ik deze vraag omdat recentelijk de 2e disk waarop de file shares staan corrupt is geraakt. Een nieuwe back-up maken van de gehele VM ging toen niet meer, omdat de disk chain corrupt was geraakt.
Ik kon echter nog wel, zonder problemen, een back-up maken van de file shares. Dus de inhoud van die zelfde corrupte disk.
Zo doende begin ik nu te twijfelen of het verstandig is om over te stappen op methode 2, omdat dit nog keurig werkte in dit geval.

Heeft iemand hier wellicht meer kijk op dan ik?

[Equator]

Ik zou het even na moeten kijken, maar als het beide dezelfde server is, dan heb je aan een enkele VUL voldoende.

Dus dan kan optie 2 wel degelijk.

[Hero of Time]

Hmm, ik dacht dat een backup source 1 licentie kost. En daarbij wordt er onderscheid gemaakt tussen een VM en een share, zelfs als die share in de VM zit. Dan zou je dus 2 licenties verbruiken voor effectief dezelfde data.

Is er in de Veeam License FAQ niets te vinden hierover? Anders zou ik zeggen: je hebt een licentie, vraag het aan hun support.

[Equator]

Als je de share als NAS benaderd, dan ben je er licentie kwijt per X GB.

Maar als je de data vanaf de VM backupt, dan meen ik niet, maar het is al weer even geleden helaas

[Linke Loe]

Waarom niet de gehele VM, inclusief alle virtual hard disks, backuppen en een guest file system index er overheen te laten draaien? Dan heb je zowel de mogelijkheid om de gehele VM in een keer te herstellen, als ook losse bestanden op het filesystem.

[Hero of Time]

Linke Loe schreef op woensdag 10 februari 2021 @ 12:58:
Waarom niet de gehele VM, inclusief alle virtual hard disks, backuppen en een guest file system index er overheen te laten draaien? Dan heb je zowel de mogelijkheid om de gehele VM in een keer te herstellen, als ook losse bestanden op het filesystem.

Als je z'n probleemstelling goed leest, leer je dat dat niet werkt, als de virtual disk corrupt raakt. En daarmee is dan ook je backup corrupt. Leuk die index van bestanden intern, maar als je de disk image niet goed kan uitlezen, heb je er niets aan. Immers moet er wel iets te benaderen zijn als je er vanaf wilt kunnen herstellen.

[Perphide]

Wat een fantastische reacties om te lezen, super fijn dat jullie meedenken over dit vraagstuk.

Ik zit inderdaad heel concreet met het probleem dat de gehele VM back-uppen een probleem is in de situatie met een corrupte virtuele disk. Dit heb ik onlangs dus meegemaakt (bug in TrueNAS).

Nu is het back-uppen van de shared data uit die virtuele disk geen enkel probleem, maar dit kost meer licenties. Terwijl het anders onderdeel is van de VM is slecht 1 licentie kost. Maar dat is enkel een kwestie van licenties.

Wat is jullie idee omtrent het verschil tussen de gehele virtuele disk incl. shared data versus enkel de shared data. Ik krijg nu de indruk dat het eigenlijk niet veel uitmaakt welke route ik kies.
Resultaat is denk ik in beide scenario's een flinke restore actie, zie hieronder mijn redenatie:

1. Scenario complete VM incl. virtuele disk
Vanuit de back-up is de gehele virtuele schijf te restoren die corrupt geraakt is, die is dan altijd incl. alle content dus een flink aantal GB's. De data gaat dan terug in de tijd, dus ik raak bestanden en bewerkingen op de bestanden kwijt.

2. Scenario enkel de shared content op een virtuele disk
Wanneer de disk nu corrupt raakt kan ik simpelweg een nieuwe virtuele disk mounten. Deze vul ik dan met data uit de back-up. Deze data gaat dan net als bij bovenstaand voorbeeld terug in de tijd, bewerkingen en nieuwe bestanden zijn verloren. Ook de hoeveelheid data die teruggeplaatst moet worden is evenredig aan bovenstaand voorbeeld.

Er is echter wel één voordeel, precies wat ik recent ondervonden heb. In scenario 2 kan je in veel gevallen nog steeds een nieuwe back-up maken van de content, ook al is de virtuele disk corrupt. Zodoende kan je na de back-up een nieuwe schijf mounten en die direct vullen met de back-up die daarvoor gemaakt is. Zo is er null verlies aan data en is alles nog actueel.
Deze truc heb ik dus onlangs moeten uithalen om er zeker van te zijn geen data kwijt te raken.

Afgezien van dat deze methode meer Veeam licenties kost, ziet iemand hier problemen in of zie ik iets over het hoofd?

[Dronium]

En dan is er ook nog optie 3 : Een backup maken via de Veeam Agent.

Maar ik zie niet in waarom je de backup zou moeten aanpassen omdat een disk van de VM corrupt is geraakt. Is die defecte vmdk al gerepareerd of moet er nog een extra backup komen om hem te kunnen repareren.
In dat laatste geval kun je alle bestanden gewijzigd na je laatste bruikbare backup bijvoorbeeld met robocopy veiligstellen, de backup terugzetten en de recent gewijzigde bestanden weer terug zetten.

Het lijkt me wel belangrijk om proberen te achterhalen waarom die vmdk corrupt is geraakt. Is dat vanwege een stroomstoring, hardware falen, iets in Windows of een VMware probleem?

[Hero of Time]

Houd je rekening met de ACLs op de verschillende zaken? Een backup maken van de shares neemt niet de onderliggende rechten van de shares mee, terwijl als je de hele VM met disks pakt, dit wel gewaarborgd wordt.

En bedenk ook dat als je een backup van shares gaat maken, de backup user bij alle shares moet kunnen. Als er tevens meerdere mappen op verschillende locaties worden gedeeld, ipv via 1 'hoofd' share, je alsnog meerdere licenties kwijt bent omdat je de shares apart moet opgeven.

[Perphide]

@Dronium De vmdk is corrupt geraakt door een bug in TrueNAS, de storage oplossing waar de vmdk file op gehuisvest was. De disk was hierdoor gesplitst in maarliefst 8 delta disks en weigerde te consolideren.
Clonen ging eveneens niet meer. Met geen enkele oplossing, ook handmatig de disk chain controleren en voorzien van nieuwe descriptor files hielp niet.

De Veeam agent waar je over spreek ken ik enkel van naam, ik moet me hier eerst even in verdiepen denk ik.
Ik meende wel dat tijdens het instellen van file back-ups de veeam agent automatisch geinstalleerd werd in de VM. Maar ik weet het niet meer zeker.

Even terugkomend op het stukje wat je schrijft over waarom de back-up aangepast moet worden:
Ik heb dus nu de ervaring gehad dat alleen een back-up van de gehele VM en dus bijbehorende vmdk files niet altijd de perfecte oplossing is. Zeker niet wanneer de vmdk corrupt is en er nog data op staat die afwijkt van de meest recente back-up.
Als de vmdk dan niet te herstellen is ben ik die data kwijt, dat wens ik te voorkomen.
Wat jij denk ik schrijft over alle data veiligstellen via robocopy heb ik dus gedaan via Veeam met de optie file share back-up. Deze optie werkte nog wel.

Zodoende is nu mijn vraag of het niet een beter idee is om over te stappen naar uberhaupt het maken van file share back-ups in plaats van de volledige VM back-up.

Dit maken van de back-up van de file shares kost echter wel meer licenties. En het verhaal met de file en folder rechten komt dan om de hoek kijken.

@Hero of Time Dat was inderdaad het laatste stukje van mijn vraagstuk, de rechten. Echter hier heb ik niet heel veel ervaring in. Kan jij mij hier wellicht meer over vertellen of verwijzen naar documentatie hierover?

Ik heb al wel een test gedaan omtrent het vervangen van een virtuele disk waarop file shares staan. Als ik dan vanuit de back-up shared folders op een nieuwe lege virtuele disk plaats werken de fileshares na een reboot weer als vanouds.

Wat je schrijft over de licenties heb ik momenteel anders ondervonden en geinterpreteerd vanuit de Veeam documentatie. Wat ik nu zie gebeuren is dat elke share tot 250GB zonder licentie te back-uppen is, boven de 250GB komt er 1 licentie per 250GB aan te pas. Dus een share van 700GB kost 1,8 (~2) licenties. Vanaf 750 GB tot en met 999 GB kost het 3 licenties. Dus dan kan het juist voordeliger zijn om heel veel kleine shares van minder dan 250 GB te hebben, omdat er dan geen licentie nodig is. Maar dit is allemaal een kwestie van licenties (geld) en daar is het mij niet zo zeer om te doen.

Ik wil graag weten wat jullie visie en gedachten zijn omtrent overstappen naar een file back-up versus de complete VM back-up. En ik denk dat het onderwerp file/folder rechten daarin wel eens doorslaggevend kan zijn. Maar nu weet ik juist over dit onderwerp het minst, ik weet niet exact hoe en waar die rechten "opgeslagen" zijn, het is dus geen file property die mee komt bij de back-up begrijp ik uit jouw verhaal.

[Hero of Time]

Hmm, even gezocht en bij https://helpcenter.veeam....advanced_acl.html?ver=100 staat het een en ander beschreven wat Veeam doet voor shares. Blijkbaar toch de ACL opnemen in de backup. I stand corrected.

[Perphide]

Hero of Time schreef op donderdag 11 februari 2021 @ 08:19:
Hmm, even gezocht en bij https://helpcenter.veeam....advanced_acl.html?ver=100 staat het een en ander beschreven wat Veeam doet voor shares. Blijkbaar toch de ACL opnemen in de backup. I stand corrected.

Dat is goede info om te hebben, dank.

[Question Mark]

Ik zou twee zaken inregelen:

1. De hele VM backuppen via VEEAM voor disaster recovery doeleinden. Complete VM of disk-corruptie handel je dan via een restore vanuit VEEAM af.
2. Previous Versions enablen op de fileshares. Individuele files zijn van via deze manier te restoren. Voordeel is dat je users dit dan ook zelf kunnen

Wat is er eigenlijk exact gebeurd? Je hebt het over een diskchain die corrupt geraakt is? Toevallig veel snapshots op je disk?

[Perphide]

Question Mark schreef op donderdag 11 februari 2021 @ 15:27:
Ik zou twee zaken inregelen:

1. De hele VM backuppen via VEEAM voor disaster recovery doeleinden. Complete VM of disk-corruptie handel je dan via een restore vanuit VEEAM af.
2. Previous Versions enablen op de fileshares. Individuele files zijn van via deze manier te restoren. Voordeel is dat je users dit dan ook zelf kunnen

Wat is er eigenlijk exact gebeurd? Je hebt het over een diskchain die corrupt geraakt is? Toevallig veel snapshots op je disk?

Beide heb ik, de complete VM back-up en de shadow volume copies optie (die bedoel je toch, of begrijp ik je verkeerd?)

Wat er gebeurd is: door een bug in TrueNAS is op een bepaald moment de vmdk corrupt geraakt. Daarna is 's nachts Veeam een backup gaan maken en bij afloop kon Veeam de tijdelijke snapshot niet meer consolideren omdat de vmdk corrupt was. Daarna heeft Veeam nog 2 retries gedaan, waarbij er nog eens 2 extra snapshots ontstonden.
In de ochtend kwam dit aan het licht via melding vanuit Veeam dat de back-up niet geslaagd was.
Hierop heb ik eerst Veeam nog eens een back-up laten maken om te kijken wat er mis ging.
Nu crashte de gehele Veeam VM (plotseling powered off) waardoor de disks uit de machine die een back-up moest krijgen nog gemount waren op de Veeam VM.
Op dat moment was de ellende compleet: de fileserver had dus een corrupte vmdk met al minstens 5 snapshots en de diskchain was nog gemount op de Veeam VM.
De Veeam VM kon wel opnieuw gestart worden, maar wilde de diskchain niet vrijgeven zolang er niet geconsolideerd kon worden. Hierop is handmatig de disk uit de Veeam VM verwijderd.
Nu kon de fileserver met corrupte disk handmatig geconsolideerd worden. Maar dit ging natuurlijk niet, omdat de vmdk corrupt was.
Vele pogingen later heb ik besloten een back-up van de corrupte disk terug te zetten omdat de corrupte disk en snapshots niet meer te redden waren (de uitgebreide variant van deze handeling is al beschreven).