Volume Shadow Copy Service (VSS) & Exchange
VSS of Volume Shadow Copy Service is een van de meest onderbelichte onderdelen van de laatste Windows besturingssystemen (XP, 2003, Vista, Longhorn). Ikzelf heb er nooit echt aandacht aan besteed, tot de vraag rees wat VSS backups van Exchange voor voordelen heeft.
Om die vraag te kunnen beantwoorden moest ik eerst zien uit te zoeken hoe VSS nou eigenlijk in elkaar steekt.
De Volume Shadow Copy Service is in essentie niet een Windows Service zoals de naam doet vermoeden, maar meer een concept of architectuur. Het bestaat uit een aantal onderdelen zoals in onderstaande screenshot is gevisualiseerd:
De requestor is hetgene wat de backup aanvraagt, zoals bijvoorbeeld een backup tool; de provider is hetgene wat de shadow copy maakt en beheert en de writer is hetgene wat applicatiespecifieke data klaarzet om te laten meenemen in de shadow copy. In het geval van Exchange 2007, zorgen de Exchange VSS writers ervoor dat de laatste logfiles uit het geheugen naar de database geflushed worden, de E00.log (de actieve log file) wordt gesloten, een tijdelijke E00tmp.log wordt aangemaakt, en de database wordt in read only mode gezet. Nu kan het creeeren van de shadow copy beginnen.
Zo op het eerste gezicht lijkt het op een normale backup. In Exchange 2003 gebeurde iets soortgelijks om ervoor te zorgen dat de inhoud van de database niet wijzigt gedurende de backup. Als je wijzigingen toestaat tijdens de backup, krijg je namelijk inconsistentie in de database. Pages waarnaar verwezen wordt in records die al in de backup set zitten, zouden ineens verwijdert kunnen worden en dus niet meenomen worden in de backup. Dat willen we uiteraard niet.
Maar de voorbereiding is ook het enige wat overeenkomt tussen de oude Exchange streaming backup (backuppen via de information store service) en de Shadow Copy.
Een shadow copy kan OF een complete kopie zijn van de data of een snapshot. In Microsoft termen is een kopie een clone of split-mirror, waarbij bij de creatie van een clone een complete kopie gemaakt wordt op het moment dat de requestor een shadow copy aanvraagt, en een split-mirror gaat uit van een bestaande mirror van de data die op het moment dat de backup wordt aangevraagd, wordt losgekoppeld van de data zodat de wijzigingen niet langer gemirrord worden (deze methode vind je meestal alleen terug in hardware VSS oplossingen). Bij een snapshot wordt er door Microsoft gesproken over copy-on-write. Dit is - wat ik niet wist - al een hele oude techniek die terug te vinden is in bijvoorbeeld het EXT3 filesysteem maar ook in Unix implementaties van virtual memory en verschillende Virtualisatie producten. Het werkt als volgt:
Op het moment dat de Exchange VSS writers de data hebben klaargezet voor de Shadow Copy, bevriest Windows de harddisk sectoren waar de Database op staat en creert een shadow storage file waarin de gewijzigde sectoren opgeslagen worden. Elke write naar de orginele dataset vind gewoon plaats, maar voordat de sector overschreven wordt, wordt deze gekopieerd naar de shadow storage file. Een soort filter driver in kernel mode (VOLSNAP.SYS) vangt alle lees en schrijf operaties af en bepaald of een sector gekopieerd moet worden voordat deze overschreven is. Dit werkt dus op harddisk sector niveau. Dit zijn dus geen NTFS clusters; VOLSNAP heeft geen weet van de Master File Table, omdat het op een lager niveau dan het filesystem werkt. Het zit tussen het filesystem en de device drivers in.
Applicaties kunnen op deze manier nog op de normale manier gebruik blijven maken van de data. Wanneer nu een backup gestart wordt van de snapshot, worden alle niet gewijzigde sectoren van de standaard locatie gelezen en alle gewijzigde sectoren van de shadow storage file. VOLSNAP bepaalt waar de sectoren te vinden zijn.
Na de backup wordt de shadow storage meestal weer vrij gegeven. Deze kan echter bewaard blijven, maar zal dan uiteindelijk kunnen groeien tot dezelfde grootte als het orgineel voor de snapshot.
Zie de volgende pagina voor een schematisch overzicht...
Het voordeel van VSS voor Exchange is er in het geval van een clone backup nagenoeg niet. De database blijft read only gedurende de creatie van de shadow copy, net zoals de streaming backup bij Exchange 2003. Als je echter met een snapshot of split-mirror shadow copy werkt, vergt de creatie van de shadow copy slechts enkele seconden (het moet zelfs binnen 70 seconden anders failed de operatie), waarna de database weer vrijgegeven wordt voor schrijfacties. Op zich niet zo heel groot voordeel, maar in grote omgevingen liepen servers vaak tegen het limiet van 1024 uncommited logfiles aan, waarna de server crashte. Bij split-mirror heb je nog het voordeel dat je een backup kan doen op niet-productie LUNs.
Een ander voordeel wat vaak genoemd wordt is het restoren van data. Microsoft schermt met tatements als 'Restore databases in minutes in stead of hours with VSS'
Dream on zeg ik dan. Ja, als je een snapshot online hebt staan kan je heel snel een stap terug in de tijd, maar hier heb je de orginele dataset nog voor nodig.
Als je een volledige dataset kwijt bent, zul je toch ALLE data moeten restoren en dat is vergt gewoon tijd. Het moet immers van een backup medium naar een ander medium.
Het enige verschil wat ik nog zie ten opzichte van 2003 is dat het niet meer via de Information store hoeft, wat zeker een performance boost geeft.
Bronnen:
https://blogs.msdn.com/adioltean/archive/2004/12/11/280052.aspx
Microsoft Windows Internals, 4th edition - Mark E. Russinovich and David A. Solomon